How to Prompt Claude for Coding (2026): Formulas + Examples

Claude Opus 4.8 posts leading scores on real coding benchmarks — 69.2% on SWE-bench Pro and 74.2% on Terminal-Bench 2.1 — and it's roughly four times less likely than the previous Opus to let a flaw in its own code slip through. But the model only does its best work when the prompt gives it enough to reason with. This guide is the pattern that gets there, then 10 prompts you can paste today.

For finished prompts built on this, see 28 Claude prompts for coding; for the quick reference, the Claude prompt cheat sheet.

The RTCF formula

Almost every strong Claude coding prompt has four parts: Role, Task, Context, Format. State who Claude should be, exactly what to do, everything it needs to know, and the shape of the answer you want.

Here is the formula assembled into one prompt:

Act as a staff Python engineer. [Role]
Fix the bug that makes this function drop the last record when the list length is odd. [Task]
<code>
[paste the function]
</code>
Stack: Python 3.12. Expected: process every item. Actual: last item skipped when len is odd. [Context]
Give the root cause first, then the corrected function, then one test that would have caught it. Don't rewrite unrelated code. [Format]

You don't need literal labels — just keep the four ideas present. Miss one and you get the classic failure modes: no Role means generic code, no Task means Claude guesses, no Context means invented assumptions, no Format means a wall of text you have to reshape.

Use XML tags for every input

Claude was trained to pay close attention to XML tags, so wrap each piece of input in its own: <code>, <error>, <spec>, <tests>, <context>. This matters most in debugging, where you paste several things at once and don't want Claude confusing your stack trace with your source, or a stray comment inside the code with your instructions.

Debug this. Think step by step.
<error>
[full stack trace]
</error>
<code>
[the relevant code]
</code>
Expected: [x]. Actual: [y].
Give the most likely cause, the fix, and how to verify it.

The tags cost you two seconds and reliably improve results on anything longer than a snippet.

Turn on thinking for hard problems

Extended thinking lets Claude reason step by step before it writes code, which is exactly when it catches the edge cases that turn into bugs. Turn it on — or add "think step by step before writing code" — for debugging, architecture, algorithms, and concurrency. Leave it off for boilerplate and simple functions where speed wins. On Fable 5, adaptive thinking scales to the task automatically, so you rarely have to think about it.

The tell for when you need it: if you'd want a senior engineer to pause and think before answering, ask Claude to do the same.

Give it real context, not a vague description

The single biggest lever is context. Paste the actual code, the real error, the true expected-vs-actual behavior, and a sibling file when you want Claude to match your patterns. Claude's large window (up to 1M tokens on Fable 5 and the extended-context models) means you can drop in a whole module. For multi-file changes in a real repo, use Claude Code so it navigates and edits your files, runs tests, and verifies its own work.

Write a new [component] that matches our existing patterns.
<context>
[paste a sibling component so Claude copies the conventions]
</context>
It should [responsibility]. Include types, error handling, and a test.
Leave TODOs where business logic goes.

Best for: Code that fits your project — a real example teaches conventions better than a paragraph describing them.

10 example prompts

Ten complete prompts built on RTCF. Swap the [brackets] and paste.

1. Write a function

Act as a senior [language] engineer. Write a function that [inputs -> behavior -> outputs] and handles [edge cases]. Clean, idiomatic code following [convention], with input validation and unit tests for the happy path and every edge case. Explain any non-obvious decision in one line.

2. Debug an error

Diagnose and fix this. Think step by step.
<error>
[full error + stack trace]
</error>
<code>
[relevant code]
</code>
Expected: [x]. Actual: [y]. Give the most likely root cause first, then 2 alternates, the exact fix, and how to confirm it's resolved.

3. Code review

Act as a staff engineer reviewing this change. Think step by step. Intent: [what it should do].
<code>
[the diff or files]
</code>
List issues most severe first (correctness, security, edge cases, then style), each with the location and a fix. Don't rewrite the whole file — point to specific lines.

4. Refactor safely

Refactor this for readability without changing behavior.
<code>
[code]
</code>
Keep inputs and outputs identical. Improve naming, structure, and duplication. Show the result, list what changed and why, and flag anything that looked like a latent bug.

5. Write tests

Write thorough [Jest / pytest] tests for this.
<code>
[code]
</code>
Cover the happy path, edge cases, and errors, including the boundaries I'd forget (empty, null, max, negative, unicode). Name each test after the behavior it verifies. Flag anything hard to test — it may signal a design issue.

6. Build a single-file app (Artifact)

Build a working single-file app as an Artifact: [what it does] for [users] on [device]. One self-contained HTML file, inline CSS/JS, no dependencies. Clean responsive UI, sensible defaults, handle empty and error states. After it works, list 3 features I could add next.

7. Explain a codebase

Help me understand this codebase. I'm a [level] dev new to it.
<code>
[files or a small repo]
</code>
Give a high-level map of the components and how they connect, trace one full flow from entry point to output, list the 5 files to read first and why, and flag anything fragile.

8. Write a SQL query

Write a [Postgres] query that answers: [question].
<schema>
[CREATE TABLE statements or column lists]
</schema>
Give the formatted query, explain each join and filter in one line, note a performance concern and an index that helps, and warn me about NULLs, duplicates, and time zones.

9. Migrate an API

Migrate this from [old lib/version] to [new lib/version], preserving behavior.
<code>
[code using the old API]
</code>
List every changed call in a table, flag breaking changes and deprecations, and note anything the new version handles differently. If unsure about a current API detail, say so instead of guessing.

10. Implement a change in Claude Code

Implement this across the repo. Goal: [what should be true when done]. Acceptance: [how we'll verify]. Find the files involved and outline your plan before editing, follow existing patterns, add/update tests and run them, then summarize what changed and why. Ask before anything destructive.

Mistakes to avoid

The habits that waste turns:

• No expected-vs-actual. "It's broken" makes Claude guess. State what should happen and what does.
• Pasting everything unlabeled. Without tags, Claude can't tell your trace from your code. Wrap each input.
• Asking for a rewrite when you wanted a fix. Say "point to the specific lines" or "return a diff" to keep the change scoped.
• Skipping thinking on hard bugs. For logic and concurrency, "think step by step" pays for itself.
• Trusting invented APIs. Paste real signatures, ask Claude to flag uncertainty, and always run the code.
• Describing your style instead of showing it. A sample file in a <context> tag beats any written convention.

Put your standing setup — stack, conventions, commands — in a Project or repo config so you don't repeat it. Then browse the full coding pack and keep the cheat sheet open, or grab fill-in-the-blank templates.