Claude Code features you didn't know about

Claude Code can do more than accept a prompt and return a pull request. Five features let you plan before it edits, share context across sessions, and end work deliberately instead of letting runs sprawl.

Plan before the agent edits a file or module you care about.

Start a session by naming the task, listing the files and modules the agent will touch, and surfacing any potential overlaps with other work. This is not a ticket. It is committing your intent in a form the agent and any reviewer can see immediately when the session starts.

Without this, the agent begins with only the prompt. You retype the same project constraints in every session and surprises appear late in review. With it, the agent begins with a shared understanding of scope and overlaps, so it can surface risks before it writes code.

The plan is a living artifact. Revisit it whenever the task drifts or new overlaps appear. If the agent discovers a dependency you did not list, stop and add it. The plan keeps the session focused and reduces the chance the agent will touch the wrong file.

This feature shines when you work in a large repository with many moving parts. A prompt alone cannot capture the nuances of a shared library or a configuration module. Naming them up front keeps the session focused and reduces the chance the agent will touch the wrong file.

When this is not the right fit

If the task is a quick one-liner fix, the overhead of planning outweighs the benefit. Reserve this feature for tasks that touch multiple files or modules, or when you expect the agent to run for more than a few minutes.

Commit project instructions so you stop retyping them across sessions.

Some instructions are project-specific: lint rules, test patterns, deployment constraints, or team conventions. Instead of pasting them into every prompt, capture them once in a shared file or a dedicated section the agent can read on demand. The agent can then reference them without you retyping them.

This is not a long README. It is naming the conventions the agent must follow and surfacing them when the agent asks for context. When the agent queries the shared instructions, it receives the same constraints regardless of who started the session or when it started.

Keep these instructions close to the code they constrain and make them specific enough that the agent can apply them directly. If the instructions are scattered, the agent will miss them and you will retype them anyway.

This feature is most useful in teams where multiple agents work on the same repository. Each agent starts with the same shared instructions, so the output is consistent even when different people run the sessions.

When this is not the right fit

If your project has no reusable conventions or if each session requires unique setup, this feature adds no value. It is also unnecessary for single-file edits where the prompt already contains all the context the agent needs.

Point the agent at a diff instead of a whole repository.

Claude Code can accept a full repository as context, but that context often dwarfs the actual change. Instead, point it at a diff that captures only the files and lines that changed since the last session. The agent works with a tight slice of the codebase, so it finishes faster and with fewer irrelevant suggestions.

This is not using git diff directly. Feed the agent only the relevant changes so it can reason about the delta, not the entire history. When the agent has less context, it makes fewer assumptions and produces more accurate edits.

Keep the diff focused on the task at hand, even if that means creating a new branch or cherry-picking a smaller set of changes. If the diff spans hundreds of files or thousands of lines, the agent still struggles with noise.

This feature is ideal when you are iterating on a feature branch or fixing a bug introduced in a recent commit. The agent sees only the relevant code, so it can reason about the impact of the change without being distracted by unrelated files.

When this is not the right fit

If the task requires understanding the entire repository, such as a global refactor or a cross-cutting change, a diff will hide the context the agent needs. In those cases, provide the full repository or a carefully curated subset instead.

Extend the agent with tools that expose work state and decisions.

Claude Code speaks the Model Context Protocol, so you can plug in external tools that expose new capabilities. These tools can read your work state, surface overlaps, or capture decisions without you retyping them into the session.

For example, a tool can list active claims so you see what other agents or humans are working on before you start a session. Another can append your progress updates, assumptions, and blockers to a shared record the agent can read later.

The tools keep the context alive across sessions, so you don’t restart from scratch every time. Overlap warnings arrive when an agent claims work, which the five tools each contribute to in a different way.

This feature is most useful when you work in a shared codebase with multiple agents or when you need to track decisions across long-running tasks. The tools let you resume work without rereading old chat logs or scanning commit messages.

When this is not the right fit

If your workflow is entirely solo and short-lived, the overhead of setting up these tools may not pay off. They shine when work spans days or involves multiple contributors, not when you fix a typo in a single file.

End sessions deliberately instead of letting them sprawl.

Agents keep running until you stop them or hit a timeout, which can leave stale claims and out-of-date assumptions in the shared state. End each session when the task is done or when you realize the scope has changed.

Ending a session does not mean throwing away the work. It means capturing the outcome, the decisions made, and the next steps so the next session can resume cleanly. The agent writes a handoff note with the changes, tests, risks, and decisions.

Unfinished sessions accumulate noise and can interfere with new claims. They also make it harder to track progress, because the shared state becomes a mix of old and new work.

This feature is essential when you work in a shared repository where multiple agents or humans claim work. Ending sessions deliberately keeps the work state accurate and prevents conflicts when the next contributor starts their task.

When this is not the right fit