Prompting Patterns

The 4-Prompt Flow tells you what to send and when. This section is the craft layer underneath it: how to phrase a prompt so it lands, and which phrasings reliably cost you a session. The patterns apply to any prompt you send, not only the four.

What makes a bootstrap prompt work

The Full and Simple Bootstrap templates are long for a reason. Four things do the work:

• The stack is stated rather than implied. “Next.js App Router, TypeScript strict, Tailwind, Supabase” leaves nothing to infer, and Claude Code will pick a stack for you if you leave the choice open.
• The files it may create are named. A prompt that lists the expected structure gets the expected structure; one that doesn’t gets whatever structure Claude Code reaches for.
• It has one job. The bootstrap scaffolds and writes PLAN.md; implementing features is Prompt 04’s job.
• The stopping point is part of the instruction. “Then stop and wait for approval” belongs in the prompt, not in your memory.

Copy the templates rather than writing bootstraps from scratch — Full Bootstrap for a project with a database and external APIs, Simple Bootstrap without. Reading them closely is how you learn to recognise the shape in your own prompts later.

Orientation before action

Before Claude Code changes any files, ask it to summarise what it’s about to do. If the summary doesn’t match your intent, you’ve caught the mistake for the price of one message.

This shows up twice in the spine as a named step — the understanding summary in the 4-Prompt Flow, and the plan review at the Plan Gate — but it isn’t confined to those two moments. Any prompt that will touch more than a couple of files earns an orientation check first.

Constraining scope

Most prompts that go wrong go wrong by doing too much. Claude Code reads an under-specified request generously: it refactors adjacent code, renames things for consistency, and improves files you never mentioned. The fix is to say what’s out of bounds.

• Name the files: “only change src/lib/auth.ts and src/app/login/page.tsx.”
• Rule out drive-by work: “don’t refactor anything you weren’t asked to change.”
• Separate thinking from writing: “propose the approach first, and don’t write code until I approve it.”
• Keep to one goal. “Fix the login redirect, clean up the types, and add tests” is three prompts, not one.

Scope language costs you a sentence and saves you a review cycle.

Challenge prompts

When Claude Code proposes a plan or hands back a finished feature, ask it to argue the other side:

• “What’s the weakest part of this plan?”
• “What would you do differently starting over?”
• “What breaks first under real usage?”

These are worth sending before you approve a plan, before a PR, and any time a proposal looks fine but you can’t say why. One caveat: asked this about work that is genuinely sound, Claude Code tends to manufacture an objection rather than answer “nothing”. Read the reply as a list to evaluate, not a list to action.

Patterns to avoid

• “Make it better.” No criteria means no way to verify the result. Name the axis: faster, fewer files, fewer dependencies, easier to test.
• Several goals in one prompt. Each goal makes the others harder to verify, and a failure in one obscures the rest. Send them separately.
• Asking for code before an approach. Claude Code writes quickly, so the wrong approach arrives as forty files instead of a paragraph you could have corrected.
• Re-supplying context that’s already in CLAUDE.md. It’s read at session start. Repeating it burns context and leaves two versions of the truth to drift apart — see CLAUDE.md.