Best Claude Code Prompts

The Workflow · Prompts Cluster

At a glance

Claude Code responds dramatically better to XML-structured prompts than to plain-English requests. The 7 prompts below cover the most common dev situations: write a feature, debug a failure, review a PR, refactor a file, generate tests, document an API, audit dependencies. Each one is wrapped in XML tags that Claude Code reads as instructions plus context. Once you find the prompts that work, save them as Claude skills so you do not retype the structure every time.

Why do XML-structured prompts work better in Claude Code?

Claude Code is the Anthropic CLI for building software in the terminal. It is the same underlying model as Claude.ai, but the way it is invoked changes which prompt patterns produce strong results. The model was trained with a heavy emphasis on parsing structured XML inputs, so prompts wrapped in tags like <task>, <context>, <constraints>, and <output_format> consistently outperform the same request written as a paragraph of plain English. The improvement is not subtle. Anthropic's own prompt-engineering documentation walks through the structure as the recommended pattern for any non-trivial task.

The 7 prompts below are templates. Each one is short, structured, and parameterized so you can fill in the actual specifics for your codebase. Each one also includes a <persona> tag, telling Claude Code the role you want it to play (senior reviewer, debug specialist, test writer) routes the response toward the kind of work that role does well.

📝 Heads-up on copy-paste

The prompts use HTML-entity escapes for the XML tags (so they render readable on this page). When you copy them into Claude Code, the angle brackets restore automatically. If you find yourself reusing the same prompt 3+ times, that is the signal to save it as a skill. The Claude Skills guide walks through how. After 3-5 skills, bundle them as a plugin. Our companion guide on the prompt-to-workflow climb: The AI Ladder.

What are the seven XML prompt templates?

The 7-template stack

Feature build — structured request for new functionality
Debug session — failure investigation with reproduction
PR review — line-by-line review with constraints
Refactor — intent-preserving structural rewrite
Test generation — cases that probe edges
API documentation — reference from source
Dependency audit — security and freshness sweep

1. Feature build

<persona>You are a senior engineer on this codebase.</persona>

<task>

  Implement [feature description in 1-2 sentences].

</task>

<context>

  Files most relevant: [paste paths or let Claude search].

  Existing patterns to mirror: [name 1-2 conventions in this codebase].

  Existing tests structure: [test runner + naming convention].

</context>

<constraints>

  – Match the existing code style (do not introduce new dependencies)

  – Write tests for new behavior before implementation

  – Make minimal changes outside the target feature surface

</constraints>

<output_format>

  1. The plan (3-5 bullets) before any code

  2. New test file(s)

  3. Implementation

  4. Diff of any existing files modified, with one-line reason each

</output_format>

Why this works: The plan-first output format catches scope misunderstandings before code gets written. The “minimal changes outside feature surface” constraint stops Claude Code from refactoring everything it touches. The persona tag biases the response toward production-grade output rather than tutorial-style code.

2. Debug session

<persona>You are a debugging specialist who reproduces before fixing.</persona>

<failure>

  What I observed: [paste exact error or behavior]

  What I expected: [paste expected behavior]

  Frequency: [intermittent / consistent / triggered by X]

</failure>

<reproduction>

  Minimal repro steps: [list]

  Environment: [OS, runtime version, key deps]

</reproduction>

<constraints>

  – Do NOT guess at the fix. First, reproduce locally.

  – If you cannot reproduce, list 3 hypotheses and the smallest test for each.

  – Once reproduced, name the actual cause before proposing a fix.

</constraints>

<output_format>

  1. Reproduction result (yes/no, what you saw)

  2. Cause analysis (file:line where the bug lives)

  3. The fix (smallest possible change)

  4. Regression test that would have caught this

</output_format>

Why this works: The biggest failure mode in AI debugging is “fix without reproducing.” The reproduction-first constraint pushes Claude Code to actually run code before guessing. The regression-test output is what compounds: every debug session ends with a test that prevents the same class of bug from returning silently.

3. PR review

<persona>You are a careful senior reviewer who comments on the diff, not the whole file.</persona>

<pr>

  Branch: [name]

  Description: [the PR description, verbatim]

  Files changed: [list]

</pr>

<review_focus>

  1. Correctness (will this do what the description claims?)

  2. Edge cases the author may not have considered

  3. Test coverage gaps

  4. Performance regressions (only if obvious)

  5. Codebase-conventions deviation

</review_focus>

<constraints>

  – Do NOT comment on style if the linter is happy

  – Do NOT comment on lines unchanged in this PR

  – Rank comments: BLOCKING / SUGGESTION / NIT

  – Skip the “this looks great” wrapper

</constraints>

<output_format>

  A list of comments, each tagged with severity and file:line.

  End with: ship / request changes / discuss

</output_format>

Why this works: AI PR reviews tend toward “everything looks great with a few small suggestions.” The severity ranking + “do not comment on unchanged lines” + “skip the looks great wrapper” gets you a review that actually saves time. The terminal verdict (ship / request changes / discuss) makes the output actionable instead of advisory.

4. Refactor

<persona>You are a refactoring engineer who preserves behavior.</persona>

<target>

  File: [path]

  Current shape: [1-2 sentences on what is bad about it now]

  Desired shape: [what good looks like]

</target>

<invariants>

  – Public API must not change

  – All existing tests must pass

  – Performance must not regress (if there are benchmarks)

</invariants>

<output_format>

  1. Plan in 5 small steps (each independently committable)

  2. Step 1 diff + test results

  3. Wait for me to approve before step 2

</output_format>

Why this works: Big refactors fail when AI does the whole thing in one shot and one of the middle steps breaks something. Five small independently-committable steps with a checkpoint between each is how real engineers refactor. The “wait for me to approve” line is what stops Claude Code from running ahead.

5. Test generation

<persona>You are a test author who writes tests that find real bugs.</persona>

<target>

  Function or class: [paste]

  Existing tests for this: [paste, or “none”]

</target>

<test_style>

  Framework: [paste test framework name + version]

  Naming convention: [e.g., test_X_should_Y]

  Mocking approach: [e.g., dependency injection / monkeypatching]

</test_style>

<coverage_focus>

  1. Happy path (1 test)

  2. Each documented edge case (1 test each)

  3. The 3 most likely failure modes (1 test each, even if not currently in spec)

  4. Null/empty/zero inputs (1 test)

</coverage_focus>

<constraints>

  – No tests that just re-state the implementation

  – Each test should fail if the bug it targets is reintroduced

</constraints>

Why this works: AI test generators tend to produce tautologies (tests that pass as long as the code compiles). The “each test should fail if the bug it targets is reintroduced” constraint is the difference between tests that catch regressions and tests that just inflate the test count. Asking for 3 likely failure modes not in the spec is the part that turns testing into engineering.

6. API documentation

<persona>You are a technical writer who documents from source code, not from intuition.</persona>

<source>

  Files: [paths]

  Existing docs (if any): [paste or “none”]

</source>

<output_sections>

  1. Overview (3 sentences max, what this API is for)

  2. Authentication (only if applicable, with code example)

  3. Endpoints (one block per endpoint: method, path, params, response shape, example)

  4. Errors (table of error codes + meaning)

  5. Rate limits (if any in source)

  6. Quickstart (5-line code example that does something real)

</output_sections>

<constraints>

  – Do NOT invent endpoints, parameters, or error codes not in the source

  – Flag any section where the source is ambiguous (do not paper over it)

  – Use real example values, not placeholders like “foo” / “bar”

</constraints>

Why this works: The “do not invent endpoints” constraint is the safeguard against AI hallucinating API surface that does not exist. The “flag ambiguous sections” output is the gift to your future self; it tells you where the code needs to be clarified before the docs ship. Real example values are what makes docs usable on the first read.

7. Dependency audit

<persona>You are a security-conscious engineer reviewing the dependency graph.</persona>

<manifest>

  File: [package.json / requirements.txt / Cargo.toml / etc.]

  Lockfile: [paste or path]

</manifest>

<audit_checks>

  1. Outdated majors (deps more than 1 major behind)

  2. Known CVEs (check against advisory database)

  3. Unmaintained (no commit in 18+ months)

  4. Single-maintainer risk (high-blast-radius deps with one author)

  5. Duplicate functionality (we have lodash AND ramda?)

</audit_checks>

<output_format>

  Table with: dep name, current version, latest version, status, recommendation

  Rank by RISK (security first, then maintenance, then duplicates)

  For each top-5 risk: the 1-line action to take

</output_format>

Why this works: Dependency audits are the kind of work humans put off because the output is verbose and the urgency feels low. AI handles the verbose-output part well; the risk-ranking output is what makes it useful. The “1-line action” output transforms an audit report into a backlog you can actually work through.

What is the worst thing you can do with AI in Claude Code?

Run prompts without an output format. Claude Code will happily write 3000 words when you needed a diff. The <output_format> tag is the difference between actionable and verbose.
Skip the persona tag. “You are a senior reviewer” vs “You are a debugging specialist” produces materially different work. The persona biases the response.
Let Claude Code commit without your review. The model is excellent at producing code that compiles and tests that pass; it is still capable of subtle correctness errors. Every commit needs human approval.
Use plain-English prompts for complex tasks. XML tags improve responses by a measurable margin on multi-constraint requests. Anthropic's docs make this explicit; treat it as the default.
Forget to save the working prompt. If a prompt produced a strong result, save it as a skill before you close the terminal. The work to recreate the prompt from memory next week is non-trivial.

What if you use Claude Code daily?

The 7 prompts above are the highest-frequency dev situations and the most-improved by structure. The ladder play is to convert them into skills, then plugins, then automations. A working pattern: save each prompt as a skill (file in .claude/skills/), bundle the 7 into a plugin called code-stack, then wire CI hooks so that PR review runs automatically on every push. The setup is a half-day of investment; the time saved across a year of development is large enough that this is the highest-impact tier of the ladder for any developer who uses Claude Code more than twice a week.

📊 The Prompt-to-Workflow Ladder

Tier 1: the prompts (this post). Tier 2: the skill (one file per prompt template). Tier 3: the plugin (code-stack bundle). Tier 4: the workflow (CI hooks that fire the right template automatically). When to climb →

What are common questions about Claude Code prompts?

Do the XML tags need to be exact?

The tag names are conventional, not required. Claude Code parses the structure, not the exact names. <task> and <objective> work equally well. Consistency within a prompt matters more than which specific names you pick.

Will plain-English prompts still work?

Yes, for short and simple requests. The XML structure starts paying off once your prompt has 3+ constraints, a non-trivial context block, or a specific output format. For “rename this variable,” plain English is fine; for “implement this feature respecting these patterns,” structure helps.

How do I save a prompt as a Claude skill?

Save the XML template (with placeholder values) as a file in your Claude Code skills directory. Then invoke the skill by name; Claude Code substitutes the placeholders from your call. The full setup is in our Claude Skills guide.

Where do these prompts come from?

They are the Claude Code section of the larger AI Prompt Library. The Library has over 500 prompts across 33+ categories with three difficulty levels, including a dedicated Claude Code section with XML-optimized versions for production codebases.

Is Claude Code different from Claude.ai?

Yes. Same model, different interface. Claude.ai is the web chat at claude.ai. Claude Code is the terminal CLI for development work. The model responds to similar prompts but Claude Code has access to your filesystem, can run commands, can write/edit files, and integrates with your git workflow. The XML structure works in both, with a larger measurable improvement in Claude Code where the prompts tend to be longer and more constraint-heavy.

Sources to read next?

✏️ Before you ship code from any prompt

Code that AI wrote still needs human review. Our editing pass for prose applies to code comments and PR descriptions too: How to Edit AI Out of Your Writing → The full 29-pattern catalog is documented there, along with the open-source Humanizer skill for Claude Code (MIT license, 20K+ stars), which lives in the same skill format the prompts above use.

🎯

The AI Prompt Library · $39

over 500 tested prompts including the full Claude Code section

The seven Claude Code prompts above are a free preview. The full Library has the rest of the dev stack: monorepo navigation, migration planning, performance profiling, security review, oncall runbook generation, technical-debt mapping, and the integration patterns for the most common backend frameworks.

Get the Library →

🌵

1-on-1 Deep Work Session with James · $175

Build your code-stack plugin in 2 hours

A focused 2-hour session. We run prompts 1-7 on your actual codebase, save each as a skill, bundle them as the code-stack plugin, and wire one CI hook so the PR review template fires automatically. You walk out with a reusable dev workflow.

Book Deep Work →

Get Smarter About AI Every Morning

Free daily newsletter. Built for people who want to use AI well, not chase every model.

Free forever. Unsubscribe anytime.

Best AI Wearables Compared (2026)

Cabinet AI: We Set Up an Agent Team

Adobe Firefly Video Explained