10 Claude Code Features for Daily Work

Claude Code starts brilliant. Then twenty minutes in, it forgets your conventions, edits the one package you explicitly told it to leave alone, and confidently ships the wrong thing.

You’ve felt this. And the natural conclusion is “the model got worse.” It didn’t. Your context got messy. Almost every Claude Code feature worth knowing exists to fix exactly that one problem and once you see them through that lens, they stop being a random list of commands and start being a single discipline.

Everything below is demoed on one project: a small Spring Boot project task-api (controllers, services, repositories, a shared exception handler, JUnit tests).

🍥Feature 1 : CLAUDE.md - stop re-explaining your project

The number-one reason Claude feels inconsistent isn’t that it’s dumb. It’s that every new session starts from zero knowledge of your project. So it makes perfectly reasonable choices that just aren’t your choices.

CLAUDE.md fixes that. It's a markdown file in your repo root that Claude Code auto-loads at the start of every conversation your stack, your conventions, your "never touch this" rules so you stop re-explaining yourself.

Here’s the difference, with one prompt run twice: “Add a DELETE /tasks/{id} endpoint.”

Without CLAUDE.md , Claude adds the controller mapping correctly and writes a service method — but it invents its own exception handling, throwing a generic “resource not found” when the task is missing. The repo already has a shared getOrThrow + ApiError pattern for exactly this. It did not wrote any test case or is inconsistent in use of of the best practices we used in this repo because it had no way to know it existed. The code isn't wrong. It's generic.

That’s the real value. CLAUDE.md turns “technically correct” into “the way we do it here,” every session, without you typing it again.

Best practices for claude.md:

Create it once with /init , which scans the repo and scaffolds a starter file. A common question is "how often do I run /init ?" The answer is once it's a bootstrap, not a ritual. Not per feature, not per story. After that you maintain the file by hand, and only re-run /init after a big architectural overhaul.
Edit it with /memory (it opens the file for you), or just open it in your editor and type.
What goes in it: things true almost every turn build command, test framework, architecture rules. If something only matters sometimes, it doesn’t belong here.
Phrase rules positively. “Prefer X over Y” sticks better than “Don’t do Y” language models handle positive framing better than negation.

Here is my generated claude.md and I added few best practices which should be used when adding any code in this project

With CLAUDE.md , same prompt: now it routes through the shared getOrThrow method, returns the standard ApiError, keeps the controller thin, and writes the test in the project's style first try, no nudging.

🍥Feature 2 : /context - see what’s actually filling the window

So how do you see your context? Type /context.

It’s the dashboard most people never open. It shows exactly what’s filling your window right now system prompt, tools, your CLAUDE.md, loaded skills, MCP servers, and your message history broken down by token count and percentage. When Claude starts drifting, this tells you why, and it flags when tools or history are eating too much.

One thing worth understanding: the context window is the whole container. Message history every prompt, reply, and tool result so far is just one slice of it, and it’s the slice that balloons over a long session and crowds everything else out.

Want the full breakdown? /context all expands the view.

🍥Feature 3 : Subagents - the biggest context win

A subagent is a separate Claude inst ance with its own context window. When you need it to read forty files to find something, you don’t want forty files dumped into your main conversation that’s pure pollution. The subagent does the digging in its own window and hands back only the answer.

Start with /agents. The library shows the built-in subagents that ship with Claude Code, and you can create custom ones.
I made a project-scoped “codebase investigator” gave its description.
Gave it read-only tools (it’s an investigator; it should never edit).
Picked Sonnet as the model, and confirmed.
It now lives at .claude/agents/ in the repo.

To run it, mention it with @ :

Build a few an explorer, a test-runner, a security-auditor and each one keeps its mess out of your main thread. It’s the difference between researching in your main document versus opening a scratch tab. Same brain, protected workspace.

🍥Feature 4 : /compact - compress on purpose, not blindly

When a session gets long, Claude auto-compacts: it summarizes history to free up space. The upgrade is to not wait for it, and not let it summarize blind.

Picture a session with a useful chunk of work plus a messy debugging detour you no longer care about. Passive auto-compaction summarizes everything equally including the dead ends. Manual compaction lets you steer it.

Check the expanded view first with /context all to see what you're working with. Then compact with intent:

Run /context all again and you'll see usage drop sharply — but the decisions survived and the exhaust is gone. Compact on purpose and a session stays sharp for hours instead of slowly turning to mush.

🍥Feature 5: Plan Mode - think before you do

The fastest way to waste tokens is letting Claude edit before it understands. Plan Mode flips that: it researches and writes a plan no file changes and you approve before a single line is written.

Two ways in: cycle modes with Shift+Tab , or type /plan.

Give it a task
It produces a structured plan of steps and the files it intends to touch.
You review, then approve execution.

Two wins here. One, you catch a wrong approach before it’s written, not after you’re staring at a bad diff. Two, all that planning research happens without dumping every file it peeked at into your main context.

Anything more complex than a one-liner, plan first. It feels slower. It’s dramatically faster.

🍥Feature 6: Skills - on-demand context

Remember I said some rules don’t belong in CLAUDE.md? Skills are where they go. A Skill is on-demand context a packaged capability Claude loads only when the task calls for it.

Create a folder named for the skill with a SKILL.md inside, under .claude/skills/ for a project-level skill
The file holds the skill’s name, a description of when to use it, and the details.
I built a code-review skill tuned to the project's conventions. /skills lists it.

Invoke it using / ( /code-review ) pulls the checklist into context and runs it against recent changes

Here’s the mental model : CLAUDE.md is what Claude always knows. Skills are what it can go get. Your PR checklist, your changelog format, your deploy runbook none of that needs to be in context for every “ fix a typo ” request. Make it a Skill.

The more you move out of CLAUDE.md into Skills, the less context you burn every single turn.

🍥Feature 7 : MCP — reach outside your repo

Everything so far lives inside your repo. MCP the Model Context Protocol connects Claude Code to the outside: GitHub, your database, a browser, your issue tracker. Instead of pasting a stack trace or a schema into chat, Claude pulls it live.

To wire up MCP for a project, add an mcp.json with the connection details for your server

Enable MCP in your project-level settings.json

For the demo I planted a bug removed the shared exception handling and did a direct findById(...).get(), so a missing task returns a 500 instead of a clean 404.

I filed a real GitHub issue describing it

/mcp shows my connected servers, including the GitHub issues server

Now I will just tell it to fix the issue which I filled It calls the MCP server, reads the live issue,

Opens the relevant files, and fixes it properly back through the shared getOrThrow method, returning a 404 with the standard ApiError.

This is the jump from “Claude that edits files” to “Claude that operates your whole dev environment.”

The context it needs, it fetches itself through a real tool not a copy-paste you’ll forget to refresh. The issue, the schema, the running UI all live.

🍥Feature 8: Hooks - deterministic automation

Some things shouldn’t depend on Claude remembering to do them. Hooks are deterministic automation shell commands that fire on events. After every edit, run the linter. After a file changes, run its tests.

I added a hook in my project’s .claude/settings.jsonthat runs on PostToolUse, matching Edit, Write, and MultiEdit, and runs the Maven tests:

/hooks lets you view it (under PostToolUse, project scope)

To show it working, I had Claude change a controller’s POST response status

I asked it to set it back to 201 Created and the moment the edit landed the hook fired the tests on its own, repeatedly, surfacing the failures with no prompt from me.

The underrated part: hooks cost zero context. You’re not burning tokens asking Claude “ please remember to run the tests ” and hoping it complies you’re guaranteeing it, every time, for free. Lint on save, test on change, format on write. Deterministic beats hopeful.

🍥Feature 9: Rewind - undo a bad path in two keystrokes

So you went down a bad path. Three failed refactor attempts are now sitting in your context, poisoning everything after.

I did git status shows nothing to commit.

Then a deliberately gave a bad prompt to show rewind

A few files in, you decide it’s the wrong call. git status now shows untracked files and a tangled change.

Instead of manually reverting everything, press Esc Esc to open the rewind menu (it lists your prompts as a timeline)
select the point before the refactor, and choose Restore code and conversation

Run git status again clean. The whole tangent, gone in two keystrokes.

You can roll back code only, conversation only, or both perfect for trial-and-error refactoring. And a related option, Summarize up to here , keeps the decisions and drops the exhaust by compressing the earlier history into a clean summary while leaving recent messages intact.

The distinction matters: rewind undoes state; summarize compresses context. Every turn is a branching point.

The pros aren’t smarter they just refuse to drag dead context forward.

🍥Feature 10: /goal + Auto Mode - let it run

/goal keeps Claude working across turns until a completion condition holds — not "do one thing and stop," but "keep going until this is actually done."

Pair it with Auto Mode : a safety classifier handles your permission prompts, so safe actions just run and risky ones still get blocked.

Switch to automode with Shift+Tab

Set a concrete, checkable goal

Claude edits, runs the tests, hits a failure, fixes it, re-runs — looping autonomously until the suite is green and the goal is met.

This is the closest Claude Code gets to “ go build it while I grab a coffee. ”

The guardrail is the classifier the sane middle between approving every single step and the fully-yolo skip-permissions flag. Set a clear, checkable goal, let it cook, and come back to working code. (Auto Mode runs on the Pro plan, too.)