Claude Code prompts
How to write a Claude Code prompt that stays on task
A good Claude Code prompt names the file, describes what goes wrong, says what "fixed" looks like and gives Claude a check that passes or fails. Add what Claude cannot see, such as the bug report in your Slack thread, and tell it to read the code before it describes or changes it.
macOS 13+·Windows 10+·Free for 3 days, no card
Updated
Context
Tell it what it cannot see
Claude Code can open your files, but it cannot open your Slack thread, your customer's email or the decision in your head.
Anthropic's guide gives a test for what to write down: could Claude find this by reading the code, and would it go and look? If not, put it in the prompt. Typical examples are a team decision, a deploy step that lives in one person's head, or a setting the tests need.
Hand over what you have instead of describing it. Attach a file with @, paste a screenshot, or pipe in the output of a command (send it straight into the chat). For a bug, that means the report itself: who hit it, what they saw, when, and what they expected. Scrubbr pulls that report from your chat or email so you do not paste it by hand.
Scope
Name the file, the symptom and what fixed means
A short prompt leaves the scope open, so the tool picks one, and three details close it.
Anthropic's guide sets "fix the login bug" beside a prompt that names the folder, describes the symptom and asks for a failing test first. Here is the same shape with our own examples.
| Vague prompt | Specific prompt |
|---|---|
| fix the signup bug | Signup fails with an "invalid token" message when someone opens the email link a second time. The code is in the signup folder. Write a test that fails first, then fix it. |
| make the dashboard faster | The dashboard takes 9 seconds to load for accounts with over 500 invoices. Find out why before you change anything. Done when it loads in under 2 seconds on that account. |
If you do not know which file is the problem, say that. In our experience, "I do not know which file builds this email" is a useful sentence. It tells Claude to search instead of guess.
Safe changes
Read first, then change
Make Claude open the code before it tells you what the code does.
Anthropic's prompting guide includes a sample instruction for coding agents: never speculate about code you have not opened. Put the idea in plain words: "Open the code that builds the email before you say anything about it. If you have not opened a file, do not describe it."
Then set the edges. Claude reads a short request conservatively and builds the smallest thing that fits, so you are the one who sets the scope. Words like "be ambitious" still help when you want more. When you want less, name the files it may change and the files to leave alone. The file list is our own advice and appears nowhere in the guide.
Checks
Give it a check to run
A check is anything that says pass or fail, so you know the fix worked without reading code.
- A test file (a small program that checks one behaviour).
- The build finishing with no error.
- A linter (a tool that flags mistakes and style problems).
- A screenshot you can compare by eye.
Anthropic lists these as ways to give Claude something to check against. Then ask for evidence: the command it ran and what the command printed. A bare "all tests pass" tells you very little. If you have no tests yet, ask for a test that fails first, so you can see it turn to passing.
This tool
What is different in Claude Code
Claude Code works inside your project, so some advice only applies here.
The shared core of a good prompt (goal, facts, steps, limits, format) lives on the hub. Here is what is specific to this tool.
- A CLAUDE.md file. This is a plain text file of standing rules for your project. Keep it short. Put in only what Claude cannot work out from the code: the commands that run tests and checks, places in the code that mislead, decisions that are not written anywhere, and anything you had to correct twice.
- "Think step by step" is not a magic phrase. Anthropic calls it ordinary prompt text. The main control for how hard Claude thinks is the effort level.
- When you do not know what you want yet, ask Claude to interview you. Anthropic's example: "Interview me until you could write the spec, then write it to SPEC.md." Then start a fresh session to build from that file.
- Two failed corrections is the limit. After that, type /clear (it wipes the chat) and write a better prompt. Do not send a third correction.
Worked example
From "fix the bug from that thread" to a prompt that checks itself
Mara builds a booking app for pottery studios with Claude Code. A customer hit a bug, and the report sits in Slack and in the customer's email.
In Claude Code
You say
optionfix the bug from that thread, the wrong time one that jonas posted yesterday, greta emailed about it too, and make sure it actually works this time
Scrubbr finds
Slack · #bugs thread "Wrong time in confirmation email" (Jonas Keller, Nov 2)
Gmail · Greta Holm, "Class time looks wrong"- Knowledge base · How we run the tests
Claude Code · Prompt
Goal: Fix the bug where booking confirmation emails show the wrong class time. Customers turn up at the wrong hour or think the booking failed.
Facts: Jonas Keller (support) reported it in Slack #bugs on Nov 2. Greta Holm, of Harbor Clay, booked "Wheel basics" for Friday Nov 6 at 6:00 pm Denver time. Her confirmation email says 1:00 am. The booking page shows 6:00 pm. Two other customers reported the same. Jonas's guess is that the email prints UTC. That is not confirmed. I do not know which file builds the email. Tests run with npm test.
Steps: 1. Find and read the code that builds the confirmation email. Do not change anything yet. 2. Tell me which files and lines format the class time, and whether Jonas's guess is right. 3. Write a test that fails: a 6:00 pm Denver class must print as 6:00 pm in the email. 4. Make the smallest fix. 5. Run the new test and the full suite.
Limits: Change only the code that formats the time in this email. Add no new libraries. Do not describe code you have not opened. If reminder emails have the same bug, tell me and leave them alone. If you are not sure about something, say so and ask me.
Format: A short plan in plain words first. Then the changes. Then three plain lines: what was wrong, what you changed, how to check it.
A great answer: The new test fails before the fix and passes after. The full suite passes, and you show the command and its output. Only the time formatting changed.
Demo data. The people, company and facts are invented.
Questions
Claude Code questions
Why does Claude Code change files I did not ask about?
A short prompt leaves the scope open, so the tool decides it for you. Name the file, describe the symptom and say what "fixed" looks like, as Anthropic's guide advises. Then say which files it may touch and which to leave alone.
Do I need to write "think step by step" in Claude Code?
No. Anthropic treats it as ordinary prompt text, not a keyword. The effort level is the main control for how hard Claude thinks.
What is a CLAUDE.md file and what goes in it?
It is a plain text file of standing rules for your project. Keep it short and include only what Claude cannot work out from the code, such as the commands that run tests and checks, misleading places in the code, and anything you corrected twice.
What if I do not know what I want yet?
Ask Claude to interview you until it could write the spec, and have it save the spec to a file such as SPEC.md. Then start a fresh session and build from that file.
How do I know the fix worked if I cannot read the code?
Give Claude a check that passes or fails, such as a test or a build, and ask it to show the command and what it printed. A bare "all tests pass" tells you very little.
Sources
Where these facts come from
Sources checked on 2026-11-03.
Scrubbr writes this prompt for you. Hold Option and say one line.
Try Scrubbr free for 3 days
Download Scrubbr, connect your tools, and give your first prompt in two minutes.
macOS 13+·Windows 10+·Free for 3 days, no card