Claude Code Prompts: Task Specs That Survive Long Sessions

Claude code prompts are task specifications you paste into Claude Code so the agent knows what to build, what to touch, and how to prove it finished. Long sessions fail when specs drift: vague goals, missing paths, no verify steps, no stop rule. This guide teaches paste-ready task specs with goal, scope, context, steps, verify, and escalation blocks. You get examples for test fixes, refactors, and docs sync jobs. This is not an Agent Skills article. PromptMake at https://promptmake.net/loop-prompt-generator formats bounded loop command text when verify and turn caps matter. Copy output into Claude Code locally. Here the focus is the ticket-shaped brief you write before the agent reads your repo.

What makes a Claude Code prompt different from chat

Chat prompts optimize one reply. Claude Code prompts optimize a tool-using session that may read files, edit code, run shell commands, and iterate. The model sees your spec plus repo context plus prior turns. A spec that works in ChatGPT often fails in Claude Code because it never names paths, never lists forbidden directories, and never states verify commands.

Strong Claude code prompts read like a ticket a senior engineer would assign: outcome, inputs, constraints, verify, escalation. Weak prompts read like mood boards: make it cleaner, improve architecture, follow best practices.

Long sessions amplify small spec gaps. Turn ten the agent refactors a folder you never mentioned. Turn twenty it declares done without running tests. Turn thirty you burn tokens rediscovering the same missing env var. Task specs front-load the fences that keep multi-turn work aligned.

Claude Code as of mid-2026 commonly runs Claude Fable 5, Claude Opus 5, or Claude Sonnet 5 class models for coding. Haiku 4.5 suits narrow verify-heavy tasks with small diffs. The spec quality matters more than the model badge on the session.

The task spec skeleton that survives long sessions

Use six blocks in order. Goal states observable done. Scope lists paths in and out. Context gives links, tickets, or one-paragraph background. Steps suggest order without micromanaging every edit. Verify lists commands and checks the agent runs before success. Escalation says what to do when blocked or when verify fails twice.

Keep the whole spec under two screenfuls. Long specs suffer lost-in-the-middle drift. Put critical fences in the first and last paragraphs: do not touch paths outside src/features/billing, run npm test before claiming done.

Separate session facts from standing rules. Session facts belong in the user message: branch name, ticket id, failing test output pasted once. Standing rules belong in the spec template you reuse: never commit, never change public API without explicit goal line.

Goal: observable finish line

Good goals name evidence: all tests in packages/api pass, OpenAPI spec matches handler signatures, README install section lists every flag from bin/cli.ts.

Bad goals invite reinterpretation each turn: improve error handling, modernize the module, clean up types.

Write the goal so a human reviewer who missed the chat can audit the repo against it.

Scope: paths in, paths out

Scope is the highest-leverage block for long sessions. List directories the agent may edit. List directories that are read-only unless the goal explicitly includes them. Name generated folders to skip: dist, node_modules, vendor.

Example in-scope: packages/api/src/routes, packages/api/tests/fixtures.

Example out-of-scope: packages/web, infra/terraform, any file under migrations unless goal says migrate.

When scope is missing, agents optimize globally. That feels helpful until it breaks a sibling package.

Context: minimum background

Context is not a novel. Link the ticket, paste the failing test name once, note the framework version if it matters, state the branch.

Skip context the agent can read from files: do not paste entire stack traces if they live in logs/test.log and the agent can read files.

Do include non-obvious constraints: legacy Node 18 host, must keep CommonJS entry, feature flag OFF in production config.

Steps: ordered hints, not a script

Steps suggest sequence: read failing test, locate handler, patch validation, run targeted test, run full suite.

Avoid fifty micro-steps. Agents choke and skip. Five to eight phase steps beat a shell script cosplay.

Mark optional steps explicitly: optional: extract helper if duplication exceeds three lines.

Verify: commands that prove done

Verify is where long sessions succeed or lie. List commands with expected signals: npm test --workspace packages/api exits 0, rg 'TODO\(billing\)' src/features/billing returns empty, curl localhost:3000/health returns 200.

Order cheap checks before expensive ones. Lint before full e2e. Diff before deploy scripts.

Weak verify: make sure it works, ensure quality. Strong verify: run make check, expect zero errors.

Escalation: stop rules and human handoff

Escalation prevents infinite loops. If verify fails after two attempts, stop and summarize: what changed, what still fails, suggested next human action.

Name turn or time budget when using loop commands: max 12 agent turns, then report blockers.

Escalation also covers missing credentials: do not guess AWS keys, ask once for env var names.

Paste-ready Claude Code task spec examples

Copy these shells. Swap bracket tokens. Keep verify commands real for your repo.

Example A: fix failing unit tests

Goal: make npm test --workspace packages/api pass without changing exported function signatures in packages/api/src/index.ts.

Scope: edit packages/api/src and packages/api/tests only. Do not touch packages/web or shared UI.

Context: branch fix/billing-422, ticket BILL-188, failing test is validates invoice totals in tests/invoices.test.ts.

Steps: read failing assertion, trace handler, patch validation, run targeted test file, run full workspace test.

Verify: npm test --workspace packages/api exits 0; npm run lint --workspace packages/api exits 0.

Escalation: if still failing after two fix cycles, list changed files, failing test names, and first error line. Stop.

Example B: refactor module with behavior lock

Goal: extract pure functions from packages/search/queryBuilder.ts into packages/search/queryBuilder/pure.ts with zero behavior change.

Scope: packages/search/queryBuilder.ts, new folder packages/search/queryBuilder/, update imports in packages/search only.

Context: no API changes, consumers import named exports today.

Steps: copy logic to pure module, re-export from index, run search tests, compare snapshot outputs if present.

Verify: npm test --workspace packages/search exits 0; git diff shows no changes under packages/search/tests/__snapshots__ unless expected.

Escalation: if snapshots drift unexpectedly, stop and report diff summary without committing.

Example C: docs sync with CLI source

Goal: update docs/install.md so every flag in bin/cli.ts appears with one usage example.

Scope: docs/install.md read/write, bin/cli.ts read-only reference.

Context: release 2.4 adds --dry-run and --verbose flags.

Steps: enumerate flags from bin/cli.ts, diff against doc headings, add missing sections in alphabetical flag order.

Verify: manual diff list empty for missing flags; markdown headings match flag names exactly.

Escalation: if bin/cli.ts uses dynamic flag registration, list discovered flags in report and pause for human confirm.

Example D: narrow bugfix with reproduction

Goal: fix null dereference when session expires in src/auth/session.ts line reported in SENTRY-4421.

Scope: src/auth/session.ts and src/auth/session.test.ts only.

Context: reproduce with yarn test session.test.ts -t 'expired token'.

Steps: reproduce failure, guard null path, add regression test, rerun file tests.

Verify: yarn test session.test.ts exits 0; no new eslint errors in src/auth.

Escalation: if reproduction fails, capture command output and stop without speculative edits.

How task specs differ from Agent Skills

Agent Skills are reusable SKILL.md packages with triggers and reference files loaded when the skill matches. Claude code prompts in this guide are session task briefs you paste for one job: fix this test, sync this doc, extract this module.

Use Skills when the same expertise applies across many tasks: security review checklist, company API style, design system rules. Use task specs when the job has a finish line tied to today's branch and ticket.

Do not dump an entire skill library into a task spec. Link or name one skill if your workspace loads it. Keep the spec focused on outcome and verify.

Read claude code skills guide when you need SKILL.md anatomy. Stay here when you need the ticket-shaped prompt that starts a coding session.

Long session habits that prevent drift

Commit or stash before a long agent run on risky refactors. Revert paths stay obvious when verify never passes.

Refresh the spec in a new message when the goal changes mid-session. Do not append contradictory goals to turn forty.

Paste verify output once when it is stable. Ask the agent to trust the last green run unless files changed.

Split mega-tasks into sequential specs: spec one fixes tests, spec two refactors after green. One spec per finish line.

Keep a personal template file in your repo: docs/agent/TASK_SPEC.md with the six blocks empty. Copy before each session.

When using loop commands, align task spec verify with loop verify criteria. Mismatch causes false success or endless retries.

Step-by-step: write your first surviving spec

Step 1: Write one sentence observable goal before opening Claude Code.

Step 2: List in-scope and out-of-scope paths from repo root.

Step 3: Add three to five context lines: branch, ticket, failing command.

Step 4: Draft five phase steps, not thirty micro commands.

Step 5: List verify commands you would run manually.

Step 6: Add escalation: two failed verify cycles then stop and report.

Step 7: Paste spec as first message. Avoid burying it below unrelated chat history.

Step 8: After success, save the spec variant as a template for the next ticket in the same module.

When you want loop command text with goal, verify, and turn cap pre-filled, open https://promptmake.net/loop-prompt-generator. Paste your task spec summary as input. Copy output into Claude Code. PromptMake generates command text only. It does not run agents or bill Anthropic tokens for you.

Common mistakes with Claude code prompts

Mistake 1: Goal without verify. The agent declares victory on partial work.

Mistake 2: No scope fences. Unrelated packages get refactored helpfully.

Mistake 3: Mega-spec covering refactor plus feature plus docs. Split jobs.

Mistake 4: Pasting entire logs when a file path suffices. Burns context window.

Mistake 5: Contradictory constraints: fast hack plus zero tech debt forever.

Mistake 6: Verify vibes instead of commands. make sure tests pass is not verify.

Mistake 7: Changing goal every few turns without new spec message.

Mistake 8: Skipping escalation. Agent loops on missing secrets.

Mistake 9: Confusing this with Skills authoring. Skills are packages. Task specs are tickets.

Mistake 10: No git hygiene before long runs. Hard to undo speculative edits.

When PromptMake /loop-prompt-generator fits

Use the loop generator when your task spec already has goal and verify but you want bounded loop command formatting for Claude Code. Feed it the observable goal, command verify list, and turn cap from your spec.

Typical loop: write six-block spec by hand, open https://promptmake.net/loop-prompt-generator, paste summary, copy loop block, run in Claude Code, audit verify output yourself.

Guests receive about three generations per day on that path. Free registration raises quota separately from text, image, and video tools.

The generator does not replace scope fences or path lists. You still paste those in the session. It formats iteration bounds so long sessions stop instead of wandering.

FAQ

What are Claude code prompts?

Claude code prompts are structured task specifications for Claude Code sessions: goal, scope, context, steps, verify, and escalation. They tell the coding agent what done means and how to prove it across many tool turns. Unlike one-shot chat prompts, they name file paths, forbidden directories, and shell commands the agent must run before claiming success. A strong spec reads like a senior engineer ticket, not a mood board.

How is this different from Agent Skills?

Agent Skills are reusable SKILL.md packages with triggers. Task specs are one-session briefs tied to a ticket and branch. Skills teach standing expertise. Specs assign a finish line.

How long should a Claude Code task spec be?

Aim for under two screenfuls. Put critical scope and verify lines in the opening and closing paragraphs to survive long context. Long specs suffer lost-in-the-middle drift where the agent forgets middle constraints. Repeat the highest-risk fences twice rather than adding ten more paragraphs.

Do I need loop commands for every task?

No. Simple one-shot edits may need only a tight spec without loops. Use loops when verify may fail twice and you want bounded retries with turn caps.

Can PromptMake write my task spec?

PromptMake /loop-prompt-generator formats loop command text from your goal and verify summary. You still own scope, paths, and repo-specific commands. Start at https://promptmake.net/loop-prompt-generator when verify and turn cap matter.

Which Claude model fits long coding sessions?

As of mid-2026, Claude Fable 5, Claude Opus 5, and Claude Sonnet 5 are common for long coding sessions. Haiku 4.5 suits narrow verify-heavy tasks with small diffs. The spec quality matters more than the model badge on the session.