Feature & Bug-Fix Prompts

The Daily Feature prompt

The everyday workhorse. It leans on the memory system — CLAUDE.md for context, TODO.md for the task — so the prompt itself stays short:

Daily Feature prompt
Read CLAUDE.md and docs/TODO.md. Task: [TODO item name] ONLY. [Plan mode first. ← keep this line for 3+ file tasks]

GOAL: [outcome — e.g. "visitors can submit feedback via a form on every tool page; submissions arrive in my email"]

DETAILS: [2-5 specifics: where it lives, what it looks like, edge cases]

CONSTRAINTS: touch only what this feature needs; no new dependencies without asking; follow existing patterns in [@example-file of similar existing code].

VERIFY: [npm run build passes + a specific manual check, e.g. "show me the rendered HTML of the form"]

FINISH: check off the TODO item, update STATUS.md, commit as "feat: [name]".

What makes it work:

  • "ONLY." One TODO item per run. The word is doing real work — it's the fence against scope creep.
  • The plan-mode line stays in for anything structural (the 3+ file rule); delete it for small tasks.
  • @example-file — pointing at similar existing code is the single most effective way to get new code in your style rather than generic style.
  • "No new dependencies without asking" — beginners accumulate packages fast when nobody says this. Make adding a library a decision, not a side effect.
  • A specific VERIFY — "build passes" plus one concrete check for this feature. Vague verification invites vague work.

The Bug-Fix prompt

Diagnosis before surgery — the order is the entire trick:

Bug-Fix prompt
Read CLAUDE.md. Bug: [what's wrong, one sentence].

REPRODUCE: [exact steps/URL/input → wrong result vs expected result. Paste ONLY the error line + first stack-trace lines, not the whole log.]

Diagnose FIRST: find the root cause with minimum file reads and explain it to me in 3 lines BEFORE proposing the fix. Then fix the cause (not the symptom), tell me how to confirm it's gone, and check nothing else broke (run build/tests).

FINISH: commit as "fix: [description]". If the cause suggests similar latent bugs elsewhere, list them in docs/TODO.md — don't fix them now.

Why "diagnose FIRST" matters this much: the classic beginner-with-AI anti-pattern is the patch-the-symptom loop — each "fix" quiets the error at one spot while the real cause keeps leaking, smearing the bug around the codebase until nobody can find where it started. Forcing a stated, three-line root cause before any fix breaks that loop. And there's a bonus: you read a three-line explanation of a real failure every time something breaks. That's a systems education, drip-fed.

  • REPRODUCE precisely. "It's broken" gets you guesses; "entering 0 on /length/ shows NaN, expected 0" gets you a fix. Paste only the error line and the first stack-trace lines — the whole log is noise that costs context.
  • "Don't fix the latent bugs now." If the root cause suggests siblings elsewhere, they go to TODO.md as their own items. One session, one fix, one commit — the discipline that keeps diffs reviewable.

If a fix fails three times, stop. Don't run attempt four in the same session — /clear, then restate the bug fresh with this template. A context full of failed approaches actively makes the next attempt worse (chapter 6 explains why).

Up next: the two prompts that bracket every session — the End-of-Session handoff and the Grand Re-Entry briefing — the pair that makes "coming back after weeks" a twenty-second experience.

FAQ

Frequently Asked Questions

How do I ask Claude Code to build a feature?
Use the Daily Feature template: read CLAUDE.md and TODO.md, name one TODO item ONLY, give the goal as an outcome plus 2–5 details, constrain scope ("no new dependencies without asking", "follow the pattern in @example-file"), demand a specific verification, and finish with checkbox + STATUS update + commit.
What does "diagnose first" mean in the Bug-Fix prompt?
Claude must find the root cause and explain it in three lines before proposing any fix. That breaks the patch-the-symptom loop that smears a bug around the codebase — and the three-line explanations quietly teach you how things fail.
Why paste only the error line instead of the whole log?
The error line plus the first stack-trace lines carry nearly all the signal; the rest is noise that bloats the session's context and buries what matters. Precise reproductions get fixes; walls of log get guesses.
What if the fix keeps failing?
Three failed attempts is the stop signal: /clear the session and restate the bug fresh with the template. A context full of failed approaches actively makes attempt four worse — a fresh, well-stated session usually cracks it.