Claude Code prompts: 16 copyable prompts for plan mode, CLAUDE.md, subagents and more

01 The first-day codebase overview

A broad-to-narrow set of questions that maps an unfamiliar repository without changing it.

Feature

Read-only exploration; the built-in Explore subagent for wide searches

Use when

You have just cloned a repo or inherited a project

Check afterward

Does the answer name real files and functions you can open?

The common workflows page recommends starting broad and narrowing. Ask one question per message so you can correct course.

give me an overview of this codebase

explain the main architecture patterns used here

what are the key data models?

how is authentication handled? name the files involved

which parts look fragile or inconsistent?

The last question is yours to keep or drop. It turns up the places where a first change is most likely to go wrong.

02 Interview me, then write the spec

Lets Claude ask the questions when you cannot yet describe what you want, and ends in a SPEC.md you can build from.

Feature

Claude’s question tool and a plain file as the handoff

Use when

The idea is clear in your head but not on paper

Check afterward

Does SPEC.md list what is out of scope and a definition of done?

This prompt is from Anthropic’s best practices page. Claude comes back with multiple-choice questions about the parts you have not pinned down, and keeps asking until the answers add up to a spec. Then start a fresh session to build from the file, so the build begins with a clean context.

I want to add [feature] to [part of the product] but haven't thought it through yet. Interview me until you could write the spec, then write it to SPEC.md. Include: what is out of scope, the edge cases, and how we will know it is done.

03 Turn a board idea into a first build

Starts a new project from a short idea description, in plan mode, with a boundary on scope.

Feature

/plan with a task

Use when

You have an idea but no code yet

Check afterward

Is the plan one screen, one action and a list of what is not included?

Example: the idea “Explain this cron expression in plain English, and the reverse” was posted on the board in the developer tools category. It is small enough for one session. See the idea, or browse more in the developer tool ideas.

/plan Build a single-page tool: the user pastes a cron expression and gets a plain-English explanation, and can type a sentence like "every weekday at 9am" and get the expression back. No login, no database. Stack: [your stack]. Before editing, list the files you will create, five example expressions you will test, and what you are leaving out of version one.

Every idea on the board also has a generated build prompt you can copy into Claude Code, so you do not have to write this first one from scratch.

Read “Turn a board idea into a first build” on the board and copy its build prompt →

01 Plan a multi-file change with a pattern to follow

Asks for a plan that cites an existing example, so the new code matches the old.

Feature

Plan mode; Ctrl+G to edit the plan in your editor

Use when

The change spans several files or the approach is open

Check afterward

Does the file list match the size of the feature?

/plan add CSV export to the invoices page. Read how the existing PDF export works and follow that pattern. No new dependencies. List the files you will change, the tests you will add, and anything you are unsure about. Do not edit anything yet.

When Claude presents the plan you can approve it with auto mode, approve and review each edit by hand, or choose “No, keep planning” and say what to change. Send back any plan that lists far more files than the task deserves.

02 Trim the CLAUDE.md that /init wrote

Cuts the generated file down to what Claude cannot discover on its own.

Feature

/init, then CLAUDE.md and /context

Use when

You have just run /init, or the file has grown past about 200 lines

Check afterward

Run /context and confirm the file loads under Memory files

Run /init first. It generates a starting file from your codebase. The memory guide recommends staying under 200 lines, and the best practices page says to write down only what Claude cannot find by reading the repo.

Review CLAUDE.md. Remove anything you can discover by reading the code, such as the folder layout and the framework name. Keep: the exact commands to run one test file, the typecheck and the linter; places where the code is misleading; decisions that are not in the repo. Show me the diff before you save it.

For a second opinion, /doctor prompt-audit flags instructions written for older models, references to files that no longer exist, and instructions that contradict each other. For writing the file from scratch, see how to write a CLAUDE.md.

03 Save a correction as a rule

Moves something you have typed twice into the file Claude loads every session.

Feature

CLAUDE.md, .claude/rules/ with a paths: filter

Use when

Claude made the same mistake a second time

Check afterward

Is the line concrete enough to verify?

The memory guide lists this as a signal to add to the file: you typed the same correction into chat that you typed last session. Write instructions concrete enough to check, such as “Use 2-space indentation” rather than “Format code properly”.

You just got [the thing] wrong for the second time. Add one line to CLAUDE.md under Gotchas that would have prevented it: [the exact rule, with the file or command]. If the rule only matters in one folder, put it in .claude/rules/ with a paths filter instead. Keep it to one line.

If a line keeps being ignored, the docs say adding emphasis probably will not help. Either the file is too long, or it is a rule that cannot have exceptions and belongs in a hook.

01 Delegate research to a subagent

Sends the file reading to a separate context and brings back only the findings.

Feature

Subagents; the built-in Explore agent is read-only

Use when

The question needs many file reads you will not reference again

Check afterward

Are the findings specific enough to act on?

use a subagent to investigate how our auth system handles token refresh. Report: the files and functions involved, where a refresh can fail silently, and what tests exist. Do not change anything.

02 Create a read-only reviewer subagent

Asks Claude to write a reusable subagent file with limited tools and a fixed job.

Feature

Custom subagents in ~/.claude/agents/ or .claude/agents/

Use when

You keep spawning the same kind of worker

Check afterward

Open the file; confirm tools lists only read tools

A subagent is a Markdown file with YAML frontmatter. Only name and description are required. The description is how Claude decides when to delegate, so keep it short and clear.

Create a personal code-reviewer subagent in ~/.claude/agents/. It should read a diff and report bugs that affect correctness, missing tests for new behavior, and security problems. It should skip style. Make it read-only (Read, Grep, Glob) and use Sonnet.

---
name: code-reviewer
description: Reviews a diff for correctness bugs, missing tests and security problems. Use after writing or modifying code.
tools: Read, Grep, Glob
model: sonnet
---

You are a code reviewer. Read the diff, then report only problems that affect correctness, missing tests for new behavior, and security issues. Skip style. For each finding, name the file and line and explain the failure.

Claude Code watches those folders and picks up a new file within a few seconds, except when the agents folder itself did not exist when the session started; then restart. Invoke it by name (“Use the code-reviewer subagent on my recent changes”) or with an @-mention. See Claude Code subagents for more.

03 Review the diff against the spec

Checks the work against the plan instead of hunting for bugs in general.

Feature

A subagent, plus SPEC.md

Use when

Claude says it is finished and you want an outside read

Check afterward

Are findings about requirements and edge cases, not style?

use a subagent to review the rate limiter diff against SPEC.md, check every requirement is implemented and the listed edge cases have tests, report gaps that affect correctness and skip style

Do not drop “skip style”. The docs warn that a reviewer asked to find problems will always find something, and fixing every finding leaves you with extra abstraction layers and tests for cases that cannot happen.

01 A bug fix that starts with a failing test

Forces a reproduction before the fix, so you can see the bug is real and then see it gone.

Feature

Your test command, named in the prompt

Use when

A user reported a bug and you have a symptom

Check afterward

Did the test fail before the fix and pass after?

users report that [symptom] after [trigger]. Look at [file or folder]. Write a failing test that reproduces it, run it with [test command] and show me it failing. Then fix the bug and run it again. Show the output of both runs. Do not edit existing tests.

02 Set a goal that a second model checks

Keeps Claude working across turns until a stated condition is true.

Feature

/goal

Use when

A long or unattended run where Claude might stop with items still open

Check afterward

Is the condition something a command can show?

/goal all tests in tests/auth pass and pnpm lint reports no errors

A separate model checks the condition against the conversation after every turn, and Claude keeps going until it is met. /goal clear removes it. You rarely need it in a session you are watching.

03 Ask Claude to add a Stop hook

Turns “always typecheck before you finish” from a request into a rule Claude Code enforces.

Feature

Hooks in .claude/settings.json

Use when

A step must happen every time, not most times

Check afterward

Introduce a type error on purpose and confirm Claude is sent back to fix it

Add a Stop hook to .claude/settings.json that runs pnpm tsc --noEmit, redirects its output to stderr, and exits with code 2 if it fails, so you cannot finish while the typecheck is red. Show me the JSON before you save it.

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          { "type": "command", "command": "pnpm tsc --noEmit 1>&2 || exit 2" }
        ]
      }
    ]
  }
}

Exit code 2 blocks the stop and sends stderr back to Claude. If the hook blocks eight stops in a row with no tool call between them, Claude Code ends the turn anyway. See Claude Code hooks.

01 Write a release skill that only you can start

Saves a multi-step procedure as a skill with side effects locked behind a manual command.

Feature

Skills in .claude/skills/<name>/SKILL.md; disable-model-invocation: true

Use when

You repeat a procedure that touches something real, like a release

Check afterward

Confirm Claude cannot start it on its own; you run it with /release

Create a skill at .claude/skills/release/SKILL.md with disable-model-invocation: true. Steps: confirm I am on main with a clean tree and stop to ask if not; run the version bump command and commit the result; summarize the PRs merged since the last tag into CHANGELOG.md, one line each, user-facing changes only; tag the new version and push the tag. Never publish from my machine, CI publishes from the tag.

With that flag, Claude cannot start the skill itself, and it runs only when you type /release. For more on this, read Claude Code skills.

02 Commit and open the pull request

Summarizes, commits and drafts the PR in plain language, then asks for the risks.

Feature

Built-in git workflow; claude --from-pr finds the session later

Use when

The check passed and you have read the diff

Check afterward

Read the generated description before you submit

summarize the changes I've made to the [module] module

commit my changes with a descriptive message

create a pr for this feature

enhance the PR description with more context about the testing, and list the risks a reviewer should look at

When Claude opens the PR with gh pr create, Claude Code links the session to it, so claude --from-pr 1234 (with your own number) opens the session picker filtered to that pull request.

03 A batch change across many files

Splits one mechanical change into independent units, each in its own worktree with its own pull request.

Feature

/batch, worktrees

Use when

One rule must be applied in dozens of places

Check afterward

Review the plan it shows before it runs

/batch migrate every handler to the v2 response helpers

The docs say this splits the work into 5 to 30 units, shows you the plan, then runs each unit in its own worktree and opens a PR for it. Try a small version first.

04 Pipe output into a one-shot prompt

Uses Claude Code as a Unix tool for summaries, checks in CI and bulk jobs.

Feature

claude -p, the non-interactive mode

Use when

You want an answer on the command line, not a conversation

Check afterward

Add caps and permissions before you loop it

git log --oneline -20 | claude -p "summarize these recent commits for a changelog, grouped by user-facing change"

In a loop, add the flags the best practices page recommends: --allowedTools to pre-approve what the run may use, --permission-mode dontAsk to refuse anything else, and --max-turns to cap it. Try it on three files first.