Claude Code Prompts

What a Claude Code request needs

Claude Code reads your repository, edits files and runs commands, and it keeps going until the work looks finished to it. That's the catch: without a check it can run, «looks finished» is the only signal it has, and you become the person who finds every mistake. A request that works carries five things.

1. The goal, as behavior. «Exports show the right date for users west of UTC» beats «fix the export». Describe the symptom and what fixed looks like.
2. Where to look. Name the folder or file, or type @ and pick it. If the codebase already has a pattern for this change, point at one file that follows it.
3. The constraints. What it mustn't touch: the public interface, the column order, the lock file, other packages. No new dependencies unless you say so.
4. How to verify. The exact test or build command, and what passing looks like. This line lets Claude check its own work and fix what fails.
5. Where to stop. What done means, and what to show you at the end: the diff, the commands it ran and their output. Evidence is faster to review than a claim that everything works.

Put together, a request you can type from memory:

[What is wrong, or what should exist], in [folder or file].
Follow the pattern in [an existing file that does this well].
Don't change [what must stay the same]. No new dependencies.
Verify with [test or build command] and fix anything that fails.
Done means [the condition]. Show me the diff and the test output.

Every prompt on this page is that pattern worked out for one job. The Bug Reproduction Test adds a failing test before any fix; the Safe Refactor Pass runs the tests after every small step and stops at the first red one.

Which prompt for which job

One request, before and after

We wrote this pair ourselves to show the difference. The first is what gets typed at the end of a long day:

the export is broken, fix it

Claude will fix something, but you can't tell whether it's what you meant. Here's the same request with the five parts in it:

CSV exports from the reports page show dates one day early for users
west of UTC. The export code is in src/reports/export/. Write a failing
test that reproduces it for a user in America/Los_Angeles, run it and
show me the failure. Then fix the cause, not the formatting of the output.
Don't change the column order or add a dependency.
Run npm test -- reports and show the output.
Done means the new test and the existing reports tests pass.

Each line removes a guess. The time zone says which bug. The folder keeps it from wandering the repo. The failing test proves the bug exists before anything changes, and the test command gives it a pass or fail it can read. The column order is what a downstream spreadsheet depends on and a tidy fix might «improve».

Plan first, then small steps

For a change that spans several files, or code you don't know well, separate exploring from editing. Plan mode does this: Claude reads files and writes a plan, but doesn't edit your source. Press Shift+Tab until the status bar shows plan mode, start the request with /plan, or launch with claude --permission-mode plan. Ctrl+G opens the plan in your text editor so you can correct it before approving. Anthropic's own guidance is to skip the plan when you could describe the diff in one sentence.

The Repo Feature Planner is written for that first step. Once you approve, ask for one step at a time with the tests run after each, and commit as you go. Small diffs are ones you'll actually read.

CLAUDE.md: say it once

Claude reads CLAUDE.md at the start of every session, so it's where things you'd otherwise repeat belong: commands it can't guess, style rules that differ from the defaults, branch and PR conventions, a required environment variable. Leave out what it can learn from the code. As of October 2026, Anthropic's docs suggest keeping each file under 200 lines, because longer files cost context and get followed less. Running /init drafts a starter file, and on a repo that already has one it suggests improvements. The CLAUDE.md Writer goes further and records only commands it has run.

One limit worth knowing: Claude treats CLAUDE.md as context, not as enforced rules. If something must never happen, such as writes to a migrations folder, that's a job for a hook.

Follow-up lines that fix a weak result

You rarely need a new prompt. One line in the same session usually repairs it.

Where Claude Code sessions go wrong

The failures are predictable, which makes them cheap to avoid.

• The session gets crowded. Every file read and command output stays in context, and quality drops as it fills. Run /clear between unrelated tasks.
• You correct it again and again. After two failed corrections the context is full of wrong attempts. Clear it and write one better request that includes what you learned.
• «Investigate» has no edges. An unscoped question can send it through hundreds of files. Name the folder, or say «use subagents to investigate X» so the reading happens in a separate context and only the summary comes back.
• Rewind isn't version control. Checkpoints restore edits made through Claude's file tools, not changes made by shell commands. Commit before anything risky.

Ask for a picture before an edit

For an unfamiliar module or a big pull request, a diagram reads faster than three screens of terminal text. Claude Code can publish an artifact: one interactive web page on claude.ai, built from what the session can see and updated as it continues. Anthropic's own examples include a PR walkthrough with the diff annotated inline. Ask for the explanation before any edit:

Don't change any code yet. Make an artifact that explains how
[module or feature] works: a diagram of the main parts and how one
request moves through them, with the file path on every box.
Then list the three places a change to [what I want] would touch.

As of October 2026, artifacts need a Pro, Max, Team or Enterprise plan and a session signed in with /login; API-key and cloud-provider sessions can't publish them. Without that, ask for the diagram as an HTML file in a folder you name. For reasoning in the terminal as it works, the Explanatory output style (/output-style explanatory) adds short Insight blocks explaining its choices.

Commands and features that change the result

As listed in Anthropic's Claude Code docs, October 2026. Type / in a session to see what your version has; our Claude Code cheat sheet has the rest.

• /code-review reviews the current diff for bugs in a fresh subagent, so the reviewer isn't grading its own work. Our /code-review page covers the options. /security-review checks your branch's changes against origin's default branch.
• /goal sets a condition that a separate model checks after every turn; Claude keeps going until it holds. Make it verifiable, like a passing test command.
• Skills are SKILL.md files in .claude/skills/ that Claude loads when relevant, or you call by name; see Claude skills.
• Subagents run in their own context with their own tools, which keeps heavy reading out of your main session.
• Hooks run your scripts at set points, such as after every edit. Unlike CLAUDE.md, they always run.

Claude Code comes with Claude's Pro and Max plans, and usage there is shared between the Claude apps and Claude Code. Our Claude Code review has the plan details, and the parent Claude prompts page covers the chat app.