The Best Claude Code Prompts and Commands (2026)
The best Claude Code prompts are specific, hand it real context, and plan before they touch code. This is a curated copy-paste library organized by how you actually work — understand a codebase, plan, build, review, ship, and operate — built on Anthropic's official prompt library, with our own examples and notes on when to reach for each. Plus the slash commands (/init, /plan, /compact, and custom ones) that make a session faster.
Claude Code is only as good as what you ask it. This is our curated take on Anthropic's official Claude Code prompt library: the same copy-paste prompts, reorganized into the order you actually use them, with our commentary on when and why each one works and a few we've added ourselves. Fill the {placeholders} with your real files and goals. At the end: the slash commands and the prompt-writing habits that separate a smooth session from a frustrating one.
Prompts to understand a codebase
Start every unfamiliar repo by having Claude explain it — it's faster than reading, and it primes Claude's own context for the work ahead. These are for the "I just opened this project" moment. Every prompt below is drawn from Anthropic's official Claude Code prompt library, reorganized by workflow with our own notes and a few additions of our own.
| Prompt | When to reach for it |
|---|---|
| give me an overview of this codebase: architecture, key directories, and how the pieces connect | The first prompt in any new repo — orient before you touch anything. |
| explain what {path} does and how data flows through it. write it up as {format} | One unfamiliar module. Ask for a diagram or an HTML page and it will build one. |
| what would break if I deleted {target}? | Gauge the blast radius before you remove or change something. |
| which files would I need to touch to {change}? | Scope a feature before you build it — you'll spot surprises early. |
| look through the commit history of {path} and summarize how it evolved and why | Understand why code is the way it is before you "fix" it. |
| map the {module} module: its public API, who calls it, and what it depends on | Our addition — the go-to before refactoring anything with a lot of callers. |
Prompts to plan before you build
This is where most bad output is prevented. Make Claude plan and let you review before it writes a line — the "don't edit anything yet" clause is the single highest-leverage habit in this whole list.
| Prompt | When to reach for it |
|---|---|
| plan how to refactor {target} to {goal}. list the files you would change, but don't edit anything yet | The most useful pattern here: a plan you approve before any code changes. |
| I want to build {feature}. interview me about implementation, UX, edge cases, and tradeoffs until we have covered everything, then write the spec to {file} | Interview mode — Claude asks the questions you forgot to answer, then writes the spec. |
| list the error states, empty states, and edge cases for {feature} that the design needs to cover | Surfaces the 20% of cases that cause 80% of the bugs. |
| give me two or three ways to implement {feature}, with the tradeoffs of each, before we pick one | Our addition — forces real options instead of the first idea. |
Prompts to build: implement, test, refactor
Once the plan is agreed, these get the work done. The recurring trick: point Claude at an existing example so new code matches your patterns instead of inventing its own.
| Prompt | When to reach for it |
|---|---|
| look at how {example} is implemented to understand the pattern, then build {new} the same way | The best way to get consistent code — match what's already there. |
| read issue #{issue}, implement the fix, and run the tests | Hand off a whole ticket end to end. |
| write tests for {feature} first, then implement it until they pass | TDD with Claude — the tests keep it honest. |
| migrate everything from {from} to {to}: identify every place that needs to change, then make the changes | Large mechanical migrations, done in one pass. |
| optimize {target} to bring {metric} from {current} down to under {goal} | Performance work with a concrete target to hit. |
| implement {feature}, then show me a diff of every file you changed and explain each one | Our addition — makes the review easy before you accept anything. |
Prompts to review and steer
AI is a multiplier of sloppiness as much as speed — so review the output, and correct with rules, not repetition. The last prompt here is the one that compounds: it turns a one-off correction into a permanent fix — that CLAUDE.md-rule habit is why a good setup gets better over time, which we cover in our guide to Claude Code memory.
| Prompt | When to reach for it |
|---|---|
| review my uncommitted changes and flag anything that looks risky before I commit | The habit that catches bugs before they land. |
| use a subagent to review {path} for security issues and report what it finds | A fresh-context review — the reviewer shouldn't be the code's author. |
| that is not right: {feedback}. try a different approach | Correct course without starting the whole task over. |
| you keep {mistake}. add a rule to CLAUDE.md so this stops happening | The compounding trick — turn a repeated correction into a permanent rule. |
Prompts to ship: commit, PR, release
The un-glamorous end of the loop — the parts you'd rather not context-switch into. These hand them off.
| Prompt | When to reach for it |
|---|---|
| resolve the merge conflicts in this branch and explain what you kept from each side | Merge conflicts, with a paper trail of the decisions. |
| commit these changes with a message that summarizes what I did | A clean commit message without the context-switch. |
| find the {tracker} ticket about {topic} and open a PR that implements it | Ticket to pull request in one step. |
| compare {from} to {to} and draft release notes grouped by feature, fix, and breaking change | Release notes straight from your git history. |
| write a GitHub Actions workflow that {steps} on every push to {branch} | CI/CD scaffolding you can then refine. |
Prompts to operate: debug, incidents, automation
When something's on fire or you're staring at data, these move fastest — and the automation prompts turn a repeated chore into a one-word command.
| Prompt | When to reach for it |
|---|---|
| the {test} test is failing, find out why and fix it | The everyday one — hand it the failing test. |
| {symptom}. check the logs, recent deploys, and config changes, then tell me the most likely cause | Incident triage — Claude correlates faster than you can tab between dashboards. |
| here is a build error. fix the root cause and verify the build succeeds | Build breaks, root-caused instead of patched. |
| read {file}, summarize the key patterns, and write the results to an HTML page with charts, then open it in my browser | Turn a CSV into a visual report in one prompt. |
| create a /{name} skill for this project that {steps} | Turn a repeated workflow into a one-word command (see slash commands below). |
| set up the {server} MCP server so you can read my {data} directly | Wire in live context so you stop copy-pasting it. |
The essential Claude Code slash commands
Prompts do the work; slash commands run the session. Type / inside Claude Code to see every command available to you — here are the ones worth memorizing, roughly in the order you'd use them on a project.
| Command | What it does |
|---|---|
| /init | Generates a starter CLAUDE.md for the repo. Run it first in any new project. |
| /memory | Opens your CLAUDE.md — the file Claude reads every session — to refine it. |
| /mcp | Connects MCP servers so Claude can reach your tools and data. |
| /permissions | Sets what Claude can do without asking you each time. |
| /plan | Switches into plan mode before a big change — Claude proposes, you approve. |
| /model | Switches which model you're using. |
| /effort | Dials how much reasoning Claude applies up or down. |
| /context | Shows what's currently filling the context window. |
| /compact | Summarizes a long conversation to free up context and keep going. |
| /review, /code-review, /debug | Bundled skills for reviewing changes and systematic debugging. |
How do you create a custom Claude Code command?
Custom commands are now skills. Drop a markdown file at .claude/skills/<name>/SKILL.md (the older .claude/commands/<name>.md still works too) and it becomes /<name> — a reusable command for a workflow you run over and over. A skill can also carry supporting files and load automatically when relevant, which a plain command can't.
The fastest way to make one is to ask Claude directly, with the automation prompt from above: "create a /ship skill for this project that runs the linter and tests, then drafts a commit message." It writes the skill; you review and keep it. That's the whole loop — a repeated instruction becomes a one-word command.
How to write a Claude Code prompt that works
The prompts above share a shape. Once you see it, you can write your own for anything — these are the habits that make the difference.
- 01Be specific and use real names. Fill the {placeholders} with actual paths and goals — "refactor src/auth/session.ts to use the new token helper", not "refactor the auth stuff".
- 02Give context once, not every time. Put the project's stack, conventions, and rules in CLAUDE.md so you don't re-explain them — that's what /init and /memory are for.
- 03Plan before you build. Add "list the files you'd change, but don't edit anything yet" and review the plan before any code gets written.
- 04Tell it what not to touch. "Leave the tests and the changelog alone" saves you from cleanup.
- 05Ask it to verify its own work. "Run the tests", "take a screenshot and compare it to the mockup", "show me a diff" — make it check itself before you do.
- 06Correct with a rule, not a repeat. When Claude keeps making the same mistake, "add a rule to CLAUDE.md so this stops happening" fixes it for good.
Prompts, or the right tool for the job?
These prompts assume you're working in Claude Code. If you're still choosing an agent, our best AI coding tools guide compares the field, and Codex vs Claude Code goes deep on the two leaders. New to the whole idea? What is an AI agent harness explains what Claude Code actually is under the hood. And Claude Code has a listing in our directory.
Frequently asked questions
- What is the Claude Code prompt library?
- It's Anthropic's official collection of copy-paste prompts for Claude Code, tagged by task and role. This article curates the best of them by workflow, adds notes on when and why to use each, includes a few of our own, and covers the slash commands. The source is at code.claude.com/docs/en/prompt-library.
- What are the best Claude Code prompts?
- The highest-leverage ones: "plan how to… but don't edit anything yet" before a big change; "look at how {example} is implemented… then build {new} the same way" for consistent code; "review my uncommitted changes and flag anything risky" before you commit; and "add a rule to CLAUDE.md so this stops happening" to fix a repeated mistake for good.
- What are Claude Code slash commands?
- Built-in commands you run inside a session — /init, /plan, /compact, /model, /mcp, and more — plus custom ones you define yourself. Type / in Claude Code to see the full current list, since it changes with each release.
- How do I create a custom Claude Code command?
- Custom commands are now skills: add a markdown file at .claude/skills/<name>/SKILL.md (or the legacy .claude/commands/<name>.md) and it becomes /<name>. Or ask Claude to "create a /<name> skill that …" and it writes it for you.
- How do I get better results from Claude Code?
- Be specific with real file paths, give context once via CLAUDE.md, make it plan before it builds, tell it what not to touch, and ask it to verify its own work (run the tests, show a diff). Vague prompts get vague code.