Claude Code prompts for plan mode, subagents, CLAUDE.md and review

Good Claude Code prompts give Claude specific context, separate planning from coding, and end with a check Claude can run, so it iterates until the check passes instead of stopping when the work looks done. Below are 15 original prompts built on the features Anthropic documents in its Claude Code best practices: plan mode, interviews, subagents, verification, /code-review, CLAUDE.md, hooks, skills and claude -p.

These are for Claude Code, the coding agent. For prompts to use in the Claude chat app, see the Claude prompts collection.

How to use these prompts

Paste a prompt into Claude Code and replace the blanks in double braces, or keep the default after the colon: {{test_command:npm test}} means npm test unless you change it. Where a prompt names a file, type @ and pick the path so Claude reads it before answering.

The features these prompts rely on, all from Anthropic's commands reference and common workflows pages:

If you correct Claude twice on the same issue, the best practices page says the context is cluttered with failed approaches: run /clear and start fresh with a better prompt.

How do you explore and plan with Claude Code?

1. Get oriented in a new codebase (plan mode)

Start in plan mode so Claude reads without changing anything.

Give me an overview of this codebase for a developer joining today:

1. What it does, in two sentences.
2. The main architecture patterns and where they live.
3. The key data models.
4. How {{flow:a user signs in}}, traced from the front end to the database.
5. A glossary of project-specific terms.

Cite file paths. Say "unclear" rather than guessing.

2. Investigate with a subagent

Subagents run in their own context window and report back a summary, so the file reads don't fill your main session. Anthropic suggests exactly this kind of delegation. More in the Claude Code subagents guide.

Use subagents to investigate how {{system:our authentication system}}
handles {{question:token refresh}}, and whether we already have
utilities for {{reuse:OAuth}} that I should reuse. Report back with
file paths, a short summary of the flow, and anything that looks
fragile. Don't change any files.

3. Let Claude interview you, then write a spec

This builds on Anthropic's interview pattern: Claude asks multiple-choice questions, using its built-in AskUserQuestion tool, until it could write the spec. Start a fresh session afterwards to implement the spec with clean context.

I want to build {{feature:team invitations by email}}. Interview me in
detail using the AskUserQuestion tool.

Ask about implementation, UI, edge cases, permissions and tradeoffs.
Skip obvious questions and dig into the hard parts. When we've covered
everything, write a self-contained spec to {{spec_file:SPEC.md}} that
names the files and interfaces involved, lists what is out of scope,
and ends with an end-to-end check that proves the feature works.

4. Plan a feature before any edits

Run in plan mode. When the plan appears, press Ctrl+G to edit it before you approve, as described in Anthropic's plan mode docs. The plan mode guide covers the approval flow.

I want to {{goal:add Google sign-in}}. Read {{start_dir:src/auth}} and
how we load secrets from environment variables.

Create a plan: which files change and how, the new session flow, the
tests you'll add, and how you will verify the result. Follow the
existing patterns in {{pattern_file:src/auth/github.ts}}. List open
questions at the end.

How do you get Claude Code to build and fix things?

5. Fix a bug with a failing test first

Anthropic's example prompt describes the symptom, the likely location and what fixed looks like. This one adds a hard rule against hiding the error.

Users report that {{symptom:login fails after the session times out}}.
Check {{area:src/auth/}}, especially {{suspect:token refresh}}.

Write a failing test that reproduces the issue and show it failing.
Then fix the root cause. Don't suppress the error or loosen any check.
Run {{test_command:npm test}} until it passes and show me the output.

6. Implement a design and compare screenshots

Paste or drag the screenshot into the prompt. If you have the Chrome integration set up, Claude can take its own screenshot to compare.

Implement this design as {{component:the settings page header}} using
{{stack:React and Tailwind}} and our existing components.

When done, take a screenshot of the result, compare it to the original,
list every difference, and fix them. Repeat until the differences are
only ones you can't fix, and tell me what those are.

7. Follow an existing pattern

Look at how existing {{kind:widgets}} are built, starting with
{{example_file:src/widgets/WeatherWidget.tsx}}. Follow the same pattern
to build {{new_thing:a calendar widget that picks a month and pages through years}}.

Use only libraries already in the project. Add tests in the same style
as the example's tests and run {{test_command:npm test}}.

How do you verify and review Claude Code's work?

8. Adversarial review against the plan

Anthropic's best practices suggest this kind of review against your spec, run by a subagent instead of the session that wrote the code. Keep the part about skipping style: a reviewer asked to find problems will always find something.

Use a subagent to review the diff against {{plan_file:PLAN.md}}. Check
that every requirement is implemented, the listed edge cases have
tests, and nothing outside the task's scope changed. Report only gaps
that affect correctness or the stated requirements, not style
preferences. Then fix the gaps and run {{test_command:npm test}}.

9. Writer and reviewer in two sessions

Run this in a second session, so the reviewer isn't biased toward code it just wrote. Paste the findings back into the first session to address them.

Review the implementation in @{{file:src/middleware/rateLimiter.ts}}.
Look for edge cases, race conditions, and consistency with our existing
middleware patterns. For each finding give the line, severity (blocker,
should fix, nit) and a concrete fix. Don't edit anything.

10. Commit and open a pull request

With the gh CLI installed and signed in, Claude opens pull requests without further explanation. The Claude Code review guide covers /code-review options to run before this.

Summarize the changes on this branch, then commit them with a
descriptive message: a summary line under 72 characters, a blank line,
and why the change was made. Open a pull request with what changed,
why, how to test it step by step, and any risks reviewers should look
at. {{extra:Link issue #123 in the description.}}

How do you set up CLAUDE.md, hooks and skills?

11. Prune CLAUDE.md

Anthropic's test for each line: could Claude find this by reading the code, and would it actually go and look? If both are yes, cut it. In a long file, important lines get lost. See the CLAUDE.md guide for where files live and how imports work.

Review CLAUDE.md line by line. For each line, ask: could you find this
by reading the code, and would you actually go and look? If both are
yes, remove it, along with standard language conventions and long
explanations. Keep commands you can't guess, style rules that
differ from defaults, test instructions and real gotchas. Run every
command in the file to confirm it works. Show me the diff before saving.

12. Write a hook for a rule that must never be skipped

CLAUDE.md is advisory; hooks are deterministic. Anthropic's docs suggest asking Claude to write them. The hooks guide explains events and matchers.

Write a hook in .claude/settings.json that {{rule:runs eslint on every file you edit and shows me the errors}}.
Use the right hook event and matcher, keep the script short, and
explain in two lines what it does and how to turn it off. Then edit a
file to prove the hook fires.

13. Turn a repeated workflow into a skill

Skills load on demand, so they don't bloat every session the way CLAUDE.md does. Use disable-model-invocation: true for workflows with side effects you want to trigger only by hand. The Claude Code skills guide has the format.

Create a skill at .claude/skills/{{skill_name:fix-issue}}/SKILL.md that
{{job:fixes a GitHub issue by number, reading it with gh issue view, fixing the code, adding tests and opening a PR}}.

Give it a name and a description that says when to use it. Set
disable-model-invocation: true because it has side effects. Use
$ARGUMENTS for the issue number. Keep the steps numbered and short,
then tell me how to run it.

14. Create a custom subagent

Create a subagent at .claude/agents/{{agent_name:security-reviewer}}.md
that {{role:reviews code for injection, auth flaws, secrets in code and insecure data handling}}.

Limit its tools to {{tools:Read, Grep, Glob, Bash}}. Write a one-line
description that tells you when to delegate to it, and a short system
prompt that asks for line references and suggested fixes. Then use it
on the current diff.

How do you run Claude Code from scripts?

15. A prompt for claude -p

claude -p runs without the interactive prompt, for CI, pre-commit hooks and loops over many files. The headless guide covers output formats and permission flags. Test a prompt like this on two or three files before running it on all of them.

Migrate {{file:the file passed in}} from {{from:Jest}} to {{to:Vitest}}.
Keep every test's behavior the same. Run {{test_command:npx vitest run}}
on that file. Reply with exactly one word: OK if the tests pass, FAIL
if they don't.

What makes a Claude Code prompt work?

Context is the constraint that shapes everything else. Exploring a large codebase fills the context window with file reads, so scope investigations, hand exploration to subagents, /clear between unrelated tasks, and use /compact with a focus, such as /compact keep the API changes and the test commands, when you want to keep going.

The second habit is verification. A prompt that ends with "run the tests and fix any failures" or "take a screenshot and compare" closes the loop without you. For longer runs, the docs describe stronger gates: a /goal condition that is rechecked after every turn, or a Stop hook that blocks the turn from ending until a check passes.

When an approach goes wrong, rewind instead of arguing. Press Esc twice or run /rewind to restore code and conversation to an earlier checkpoint, then try a tighter prompt. Checkpoints track Claude's file edits, not files changed only by shell commands or outside Claude Code, so commit the work you want to keep. For parallel work, worktrees keep sessions from editing the same files.

For the same ideas in other agents, see the Codex prompts, GitHub Copilot prompts and Gemini CLI prompts. The Claude Code cheat sheet lists the commands in one place.

Keep your best Claude Code prompts

Prompts like these are worth keeping. Kipt stores them as Markdown in a private GitHub repo you own: save a prompt with its blanks, tag it, and find it again with Cmd+K. When a prompt becomes a workflow, the free SKILL.md generator turns it into a SKILL.md, and Kipt can install your skills into Claude Code with one npx skills add command.