Claude Code Prompts: Patterns That Work

The best Claude Code prompts name the file, describe the symptom and say what done looks like. They hand Claude the things it cannot see, such as a decision from a meeting or a command that proves the work is finished. This page collects prompt patterns from Anthropic's own best-practices page, checked on 31 October 2026, with templates you can paste.

Quick facts

We use the docs' own examples where we quote a prompt, and say so. Anything we add is marked as ours. We did not run any of these prompts for this page, and we make no claim about how they perform.

The big idea: tell Claude what it cannot see

Anthropic's page opens with a point that explains most good prompting. Claude reads your code well, so you rarely need to explain the layout. What it cannot find is what was never in the repo: "A decision your team made in a meeting", "A deploy process that lives in one person's head", "The environment variable your integration tests need".

The docs give a two-question test before you write something down:

1. Could it find this by reading the code?
2. Would it actually go and look?

If both answers are yes, leave it out. That test applies to prompts as well as to CLAUDE.md.

Pattern 1: a specific prompt

A specific prompt "gives Claude information it doesn't already have". The docs show two before-and-after pairs.

Look at what the better prompts add. The first names the symptom, the place to look and the order of work: reproduce, then fix. The second names an existing pattern to copy and a constraint. Neither says anything about how hard to think.

A template of ours, built from that shape:

Problem: <what the user sees, in one sentence>
Where to look: <file or folder>
Done means: <a test, a command or an observable result>
Constraints: <libraries, style, things not to touch>

If you prefer a choice between two reasonable approaches, say which. The docs note Claude cannot read that preference from the code.

Hand over, don't describe

If you already have the thing, pass it in:

• A file: type @ and the path.
• An image: paste a screenshot of the design or error.
• Command output: pipe it in, as in cat error.log | claude -p "what's going on here".

A pasted stack trace beats a paragraph about it every time.

Pattern 2: say "be ambitious" when you mean it

The docs make a point that surprised us. Phrases like think step by step or be thorough are "ordinary prompt text rather than keywords". The control for how hard Claude thinks is the effort level. One phrase does still help: be ambitious. Claude reads requests conservatively and builds the smallest thing that satisfies them, since it cannot see how much you hoped for.

The docs' example:

build the settings page from the mockup. be ambitious: empty and error states, the save flow wired up, keyboard navigation, not just the layout

Their explanation is that this tells Claude about scope, which only you know, rather than how hard to think. The useful rule: describe the scope you want in concrete items. A list of what "ambitious" means keeps the result predictable.

Pattern 3: interview first, then spec

When you do not know what you want yet, the docs suggest asking Claude to interview you:

I want to add rate limiting to the public API but haven't thought it through yet. Interview me until you could write the spec, then write it to SPEC.md.

Claude comes back with multiple-choice questions about what you have not pinned down: per-user versus per-key limits, what happens to requests over the limit, what is out of scope. Once SPEC.md exists, the docs say to start a fresh session to build from it, so the build has a clean context and a written definition of done.

This is the best prompt on the page for vague ideas. It turns "I do not know" into a document, and the document becomes the reference for the review step later.

Pattern 4: give Claude a check to run

This is the section we would read first. "Claude stops when the work looks done. If it has nothing to run that tells it whether the work actually is done, 'looks done' is all it has to go on. In practice that makes you the test suite."

The fix is something that returns pass or fail: a test file, a build's exit code, a linter, a script that diffs output against a fixture, or a browser screenshot next to the mockup. The docs list four strengths of enforcement:

The docs also say to ask for evidence: "the command it ran and its output, or the screenshot". "All tests pass" alone tells you little.

Prompt template of ours:

Make the change. Then run <command>. If it fails, read the output and fix the cause, then run it again. Show me the final command output.

After Claude says it is done, /verify has it build and run the app and look at the result, which catches what tests and typechecks miss, per the docs.

Pattern 5: review against the spec, and skip style

The docs give a review prompt of their own:

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

They add a warning worth remembering: "Don't drop the skip style part of that prompt. A reviewer that's asked to find problems will always find something. If you fix every finding, you end up with extra abstraction layers and tests for cases that can't happen."

That is a good rule for any review prompt. Tell the reviewer what to ignore. For a reusable reviewer, see the code reviewer subagent, and for failures, the debugger subagent.

Pattern 6: steer early

No prompt replaces watching the first minute. The docs' advice: "Watch the first minute, press Esc the moment Claude drifts, and after two failed corrections run /clear and write a better prompt instead of a third."

A caution from the docs: checkpoints cover files Claude edited with its own file tools. A file touched only by a Bash command is not restored, and checkpoints work alongside git, not instead of it.

A replacement prompt after /clear should fold in what you learned. Our template:

Earlier attempts failed because <reason>. Start again. <specific prompt>. Do not <the thing that went wrong>.

Pattern 7: prompts for unattended runs

When you are not watching, the docs ask five questions before you leave a task:

1. Does it know what done looks like?
2. Can it check its own work?
3. What is it allowed to touch?
4. What stops it, such as --max-turns, --max-budget-usd or a spend limit?
5. Where does the result go, and who signs off?

So an unattended prompt should contain a definition of done and a check, and the run should have a cap. The ending should be a pull request or a summary, with a person approving the merge.

claude -p "Fix the failing tests in tests/auth. Run them after each change. Stop and summarize if they still fail after three attempts." --max-turns 20

That command is our template. The -p (or --print) flag is in the docs' headless section. --max-turns is in the CLI reference, applies to print mode only, exits with an error when the limit is reached, and has no limit by default.

Advice the docs say to drop

Anthropic keeps a table of old tips that current models no longer need. It is useful if you have copied prompt lists from older blog posts.

If you keep a personal prompt library, prune it against this table.

Save prompts you reuse as skills

A prompt you paste twice is a skill waiting to happen. Per the docs, "custom commands have been merged into skills": a file at .claude/commands/deploy.md and a skill at .claude/skills/deploy/SKILL.md both create /deploy. Skills add optional extras such as supporting files and frontmatter, and a skill wins if both exist.

A minimal saved prompt, our adaptation of the documented frontmatter:

---
description: Review a diff against SPEC.md and report correctness gaps only
disable-model-invocation: true
argument-hint: [path-to-spec]
---
Use a subagent to review the current diff against $ARGUMENTS. Check every requirement
is implemented and the listed edge cases have tests. Report gaps that affect
correctness. Skip style.

Save it as .claude/skills/spec-review/SKILL.md, then run /spec-review SPEC.md. $ARGUMENTS expands to what you typed after the command, per the docs. The disable-model-invocation: true setting stops Claude from invoking it on its own, which suits actions you want to trigger yourself. See the slash commands guide and skills, and the skill creator if you want help writing one.

Where saved prompts live in other agents

The prompt patterns above are model-agnostic in spirit: be specific, give a check, steer early. The file locations differ. Gemini CLI is now Code Assist enterprise only, so we do not cover its commands here. For a longer list of curated resources, see Awesome Claude Code and Claude Code workflows.

Prompts to copy

Our own templates, built from the patterns above. Replace the angle brackets.

Security notes

Prompts are short, but they can still cause trouble.

• Never paste secrets into a prompt, or into a file you hand over with @. Everything goes to the model provider.
• Piped input is untrusted. cat error.log | claude -p ... feeds log text, which may contain instructions from outsiders. Treat it as data.
• Unattended runs need limits. The docs' five questions exist because nobody is there to stop a mistake. Use caps and a sandbox.
• Shared skills are code. A project skill in version control is run by everyone on the team. Review changes to it.
• Rules that cannot bend belong in hooks or permissions, not in a prompt. The docs say a prompt alone cannot guarantee that something never happens.

Limits and known issues

• A prompt cannot replace a check. If nothing can fail, "done" is a guess.
• Advice changes as models change. The docs' own "what you can stop doing" table shows how fast. Re-read the page now and then.
• Prompt wording that works on one model may not work on another. The docs' best-practices page is written for Claude models and does not say how far it carries to other vendors' models.
• We did not test any prompt for this page.

Our take

The best Claude Code prompts are boring. They name the place, the symptom and the check. They give Claude what it cannot see and nothing it can. That is a smaller claim than most prompt lists make, and it matches how the docs now describe the tool.

Two habits give the most for the least. First, always include a command that proves the work: it turns a hope into a loop. Second, clear after two failed corrections: it feels slower and is faster. Everything else, such as saved skills and hooks, is a way of not repeating yourself.

This is our reading of the documentation, not a hands-on test.

A short checklist

1. Name the file or area, the symptom and what done looks like.
2. Attach files, screenshots or output instead of describing them.
3. Add a command that returns pass or fail, and ask for the output.
4. For vague ideas, ask for an interview and a SPEC.md.
5. Watch the first minute, and press Esc early.
6. After two failed corrections, /clear and rewrite.
7. Save repeated prompts as skills.
8. Prune old tips such as emphasis and "think harder".

See also the Claude Code cheat sheet and subagents.

Frequently asked questions

What makes a good Claude Code prompt?

Naming the file, describing the symptom and saying what fixed looks like, and handing over files or output instead of describing them.

Do I need phrases like think harder?

No. Effort level is the control. be ambitious still helps for scope.

How do I keep a prompt I reuse?

Save it as a skill at .claude/skills/name/SKILL.md.

What should I do when Claude gets it wrong twice?

Run /clear and write a better prompt, not a third correction.

Should I put architecture notes in CLAUDE.md?

Only what Claude cannot find in the repo.