Claude Prompts for Coding with Fable 5, Opus 5, and Sonnet 5

Claude prompts for coding work when you name the Claude tier, paste stack context, and demand one artifact: a task plan, a unified diff, a test file, or a review. You leave with ROLE / TASK / FORMAT blocks for Claude Fable 5, Claude Opus 5, and Claude Sonnet 5, plus stop rules that keep Claude from rewriting whole files. This page is for engineers who chat in claude.ai, Claude Code, or the Anthropic API. Cross-model prompt encyclopedias and Claude prompt-generator walkthroughs live elsewhere. Soft tip: PromptMake /text can turn a rough coding ask into a labeled scaffold at https://promptmake.net/text before you paste into Claude.

Who Claude coding prompts help

You ship in a repo Claude cannot see unless you paste files, diffs, test names, and error logs. The patterns fit people who use Claude as a pair for a bounded change: a failing test, a PR comment, a small API, a refactor inside named files. Backend, frontend, and infra work all fit if you name language, framework version, and files in scope.

Skip this page if you want a generic AI-for-code playbook that mixes ChatGPT, Copilot, and Cursor as equals, or if you want a tool that generates Claude prompts from a blank box. Stay here for Claude-specific paste shapes: Fable 5 for hard multi-file reasoning, Opus 5 for enterprise coding loops, Sonnet 5 for daily volume.

Treat Claude as a contractor with a written ticket. You supply stack, repro, files, tests, and banned edits. Claude proposes a plan, a diff, tests, or a review. You reject patches that touch files you did not name.

Claude prompts for coding: the paste stack

A strong Claude coding prompt leads with four blocks before any tone request: stack, task, scope, and output shape. Stack is language, framework, versions, test runner, and package manager. Task is the bug, feature, or review goal in one sentence plus repro or acceptance. Scope is files Claude may change and files Claude must leave alone. Output shape is unified diff, single function, test file, or numbered review. Paste those four near the top. Put banned edits at the end so they survive a long paste.

Vague "fix this" pastes with 400 lines of a component produce a full rewrite because you asked for a rewrite. Claude Fable 5, Opus 5, and Sonnet 5 all follow labeled blocks. They still invent helper files if you omit DO_NOT_MODIFY. They still drop error handling if you omit TESTS. Keep a short STACK sheet outside the chat and reuse it. One artifact per thread. Mixing a plan, a diff, and a review in the same message muddies length and git history.

Stack, scope, and output shape

Copy this wrapper and fill the brackets:

ROLE: You are a [language] engineer on this repo. You edit only FILES_IN_SCOPE. You do not invent files, APIs, or dependencies.

STACK: [language + version], [framework + version], [test runner], [package manager]

TASK: [one sentence goal]. Repro or acceptance: [steps or checks].

FILES_IN_SCOPE: [paths]

DO_NOT_MODIFY: [paths, schemas, public APIs]

OUTPUT: [unified diff | single function | test file | review with Blocking / Optional]

TESTS: [exact command, e.g. npm test -- SignupForm.test.tsx]

RULES: No full-file rewrites. No new dependencies without asking. If the root cause sits outside FILES_IN_SCOPE, stop and explain in 3 sentences. Mark missing facts with [NEED CONTEXT].

REMINDER: Output the artifact named in OUTPUT. Do not paste the whole file unless I asked for a full file.

That reminder line cuts the rewrite habit. Claude likes complete files because they look tidy. Your rule forces a patch you can read in git.

Stop rules and [NEED CONTEXT]

Add stop rules when logs are incomplete or the bug might live in another service. Example: "If STACK or FILES_IN_SCOPE cannot explain the failure, write [NEED CONTEXT] and list the file or log you need. Do not guess network timeouts or race conditions." Fable 5 and Opus 5 follow this when you put it in RULES and repeat it in REMINDER.

For API work, name the contract: "Public function signatures stay stable. If the fix needs a signature change, propose it in 3 bullets and wait." For UI, name the library: "React 19, no class components, no new CSS framework." Sonnet 5 still needs those lines; speed does not replace scope.

Optional few-shot: paste a 10-line sample of the house diff style (imports last, no drive-by rename). Fable 5 and Opus 5 copy format from that sample. Skip long "think step by step" slogans on these reasoning-class models. Goal, constraints, and format already steer them.

Task, diff, test, and review templates

Four jobs cover most Claude coding chats: a task plan before you touch git, a unified diff for a bounded bug, tests that lock the repro, and a PR review that ranks Blocking vs Optional. Run them as separate messages or separate threads. A plan that also dumps a 200-line rewrite hides the decision you needed: which files, which tests, which risk. The templates below share the paste stack from the last section. You swap TASK and OUTPUT. You keep STACK and DO_NOT_MODIFY stable so Claude does not drift mid-thread.

Pick the Claude tier after you pick the job. Sonnet 5 fits first-pass plans, small diffs, and test stubs when the stack is short. Opus 5 fits enterprise repos, strict review, and multi-file diffs you will merge. Fable 5 fits the hardest reasoning: tangled bugs, cross-module contracts, and reviews where you need ranked risk. All three still fail if you omit TESTS and FILES_IN_SCOPE.

Task plan and implementation prompts

Task plan pattern (run this before any diff):

TASK: Propose an implementation plan for [feature or bug]. Do not write production code yet.

OUTPUT: 1) Goal in 2 sentences. 2) Files to touch (paths only). 3) Files to leave alone. 4) Tests to add or change (names). 5) Risks (2 bullets). 6) Open questions marked [NEED CONTEXT]. Cap the plan at 250 words.

Read the plan out loud. Cross out files you will not allow. Then send the implementation prompt:

TASK: Implement the approved plan. Change only FILES_IN_SCOPE. OUTPUT: unified diff. TESTS: [command] must stay green in intent; if you cannot run tests, list the cases the diff should pass.

RULES: Match existing names and error style. No drive-by refactors. No comments that restate the code.

Fable 5 handles long plans plus two files in one paste. Sonnet 5 handles a single-file feature if the plan already named the function. If Claude starts coding in the plan pass, you forgot "Do not write production code yet."

Unified diffs, tests, and review prompts

Unified diff pattern:

TASK: Fix BUG. OUTPUT: unified diff only. No full file. No markdown fences around extra commentary except a 3-sentence hypothesis above the diff.

BUG: [symptom]. Repro: [steps]. Expected: [behavior].

FILES_IN_SCOPE: [path]. DO_NOT_MODIFY: [tests you will write in a later pass, or schemas].

If the root cause is outside scope, stop. Do not patch callers you did not name.

Test pattern (second message after you accept the diff):

TASK: Add or update tests that fail on the old bug and pass with the diff. OUTPUT: the test file or a diff against the test file. Use [test runner] style already in STACK. Cover the repro steps. Do not test private helpers I did not expose. Name the test after the bug, not after the function.

Review pattern:

ROLE: Senior [language] reviewer. TASK: Review the PR diff below. FOCUS: [correctness | security | API | performance]. OUTPUT: Summary (2 sentences). Blocking (must fix). Optional (nits). Questions ([NEED CONTEXT] if the diff lacks a test or a contract). Ban praise stacks. Ban "looks good" with no evidence. Cite file:line from the paste.

Paste the git diff, not the whole branch. Opus 5 and Fable 5 rank Blocking vs Optional with more care than a vague "review this." Sonnet 5 still works if FOCUS is one concern and the diff is under a few hundred lines.

Mistakes that wreck Claude coding chats

Mistake 1: Pasting a whole component and writing "fix this" with no repro. Claude rewrites the file. You spend the next hour restoring imports. Add BUG, Repro, Expected, and OUTPUT: unified diff.

Mistake 2: Asking for tests in the same message as a production diff. Claude mixes fixtures into app code or skips tests. Split: diff first, tests second, or tests first if you want red-green.

Mistake 3: Leaving FILES_IN_SCOPE empty. Claude adds utils.ts and a new package. Name paths. Name DO_NOT_MODIFY for lockfiles, generated clients, and public types.

Mistake 4: Routing a multi-file contract bug to Sonnet 5 and accepting the first patch. Sonnet 5 is the daily driver. Fable 5 or Opus 5 fit the merge-risk pass.

Mistake 5: Padding prompts with "think step by step" on Fable 5 and Opus 5. Give goal, constraints, format. Drop CoT slogans unless you measured a gain on that task.

Mistake 6: Treating a review as a compliment request. FOCUS plus Blocking / Optional plus file:line citations. Empty praise wastes a paid Claude turn.

Mistake 7: Dumping Cursor, Copilot, and ChatGPT rules into a Claude Project without a Claude-shaped OUTPUT. This article stays on Claude paste. IDE agent rules belong on their own pages.

Mistake 8: Trusting Claude on secrets. Strip tokens, customer data, and private keys from pastes. Ask for structure on logs you redacted.

Fable 5, Opus 5, and Sonnet 5 notes (mid-2026)

As of mid-2026, Claude Fable 5 is the widely released top tier for hard reasoning. Claude Opus 5 is the strong enterprise and coding tier. Claude Sonnet 5 is the volume model for daily chats. Haiku 4.5 fits cheap classification, not merge-ready diffs. Mythos 5 stays limited or trusted-access; skip it in public prompts unless your org has it.

Sonnet 5: first-pass plans, small unified diffs, test stubs, and reviews of short PRs. Keep prompts short: ROLE, TASK, FORMAT, STACK, RULES. Few-shot a house diff if format slips.

Opus 5: multi-file coding, strict review, and enterprise repos with long STACK sheets. Give goal, constraints, format. Repeat DO_NOT_MODIFY. Use Blocking / Optional on reviews.

Fable 5: tangled bugs, cross-module contracts, and ranked risk on large diffs. Paste more context (two modules, the failing test, the error). Still demand one OUTPUT. A Fable 5 rewrite of an entire service is as costly as a Sonnet 5 rewrite.

Prompting split that holds: fast Sonnet chats get RTF plus a short sample. Fable 5 and Opus 5 get goal + constraints + format, with [NEED CONTEXT] and no CoT padding. None of them replace running TESTS on your machine. Claude cannot see your CI unless you paste logs.

Build coding prompts with PromptMake

Write the rough ask in plain words: language, bug or feature, diff vs tests vs review, files in scope. Open https://promptmake.net/text and generate a structured prompt once. Expect labeled sections you can fill with STACK, BUG, and FILES_IN_SCOPE.

Edit paths, test commands, and public APIs yourself. PromptMake cannot see your repo. Paste the filled prompt into Sonnet 5 for drafts or Opus 5 / Fable 5 for merge-risk work. Keep free-tier runs for scaffolding. Guests get about three runs per day; free accounts get about five.

Workflow that sticks: STACK sheet → PromptMake scaffold → fill files and repro → Sonnet 5 plan or small diff → Fable 5 or Opus 5 for the hard patch or review → run tests locally → human read of the diff. Store one wrapper per repo so you do not rewrite ROLE and RULES each morning.

FAQ

What are the best Claude prompts for coding in 2026?

The best Claude prompts for coding lead with STACK, TASK, FILES_IN_SCOPE, DO_NOT_MODIFY, OUTPUT, and TESTS. Demand one artifact: plan, unified diff, test file, or Blocking / Optional review. Add [NEED CONTEXT] so Claude stops instead of guessing. Match Sonnet 5 for volume and Fable 5 or Opus 5 for merge-risk work.

Should I pick Claude Fable 5 or Claude Opus 5 for coding?

Pick Fable 5 when the bug crosses modules or the review needs ranked risk. Pick Opus 5 when you work in an enterprise loop with long STACK sheets and strict contracts. Pick Sonnet 5 for small diffs and first-pass plans. All three need the same paste stack; tier choice does not replace FILES_IN_SCOPE.

How do I get Claude to output a unified diff?

Set OUTPUT to unified diff only and ban full-file rewrites in RULES and REMINDER. Name FILES_IN_SCOPE. Paste the current file excerpt or git diff so Claude has a base. If Claude still returns a whole file, send one follow-up: "Rewrite as unified diff against the paste. No full file."

Can Claude write tests from a prompt?

Yes when you name the runner, the repro, and the test file path. Run tests as a second pass after you accept the production diff, or first if you want a failing test before the fix. Ban tests of private helpers you did not expose. Claude still cannot run your suite unless you paste results.

How do I use Claude prompts for coding on a PR review?

Paste the git diff, not the branch. Set ROLE to senior reviewer, FOCUS to one concern, and OUTPUT to Summary, Blocking, Optional, and [NEED CONTEXT] questions. Ask for file:line citations and skip empty praise. Opus 5 and Fable 5 fit this job; Sonnet 5 fits short diffs with one FOCUS.

Do I need a Claude prompt generator for coding work?

A generator helps you scaffold ROLE / TASK / FORMAT once. Coding quality still comes from STACK, repro, and scope you paste. PromptMake /text at https://promptmake.net/text can shape a rough ask; fill paths and tests yourself. A generator without repo facts still yields generic code advice.

How do I start with free Claude and PromptMake?

Write STACK and one BUG in a notes file. Open PromptMake /text, generate a coding scaffold, fill FILES_IN_SCOPE, and paste into Claude Sonnet 5 (or the Claude tier your plan includes). Guests get about three PromptMake runs per day; free accounts get about five. Spend those runs on the wrapper, then iterate inside Claude.