The Universal Prompt Shape

Five parts, every time

The Universal Task Structure — memorize this shape 
CONTEXT:  Read CLAUDE.md [and @specific files]. [One line of situation.]

GOAL:     [What should be TRUE when you're done — outcome, not steps.]

CONSTRAINTS: [What must NOT change. Scope limits. Conventions.]

VERIFY:   [The command/check that proves it works: build passes, test X, show me Y.]

FINISH:   [Update STATUS/TODO, commit as "type: message".]

You won't always write all five parts longhand — for tiny tasks two lines are plenty. But when a task matters, running down this list catches what you forgot to say before Claude builds the wrong thing.

Why each part exists

  • CONTEXT stops Claude re-exploring the project from scratch — you point at the files that matter and save the token burn (and the wrong guesses).
  • GOAL as an outcome lets Claude choose a good implementation, which it is genuinely better at than following steps you guessed. Describe what should be true when it's done.
  • CONSTRAINTS prevent the classic AI failure: "improving" things you didn't ask about. Scope limits are kindness — to the diff you'll have to review.
  • VERIFY converts "looks done" into "provably done". A prompt without a verification step is a wish.
  • FINISH maintains your memory system automatically — TODO checked off, STATUS updated, work committed — so the system never depends on you remembering.

Outcome-goals beat step-lists

The beginner instinct is to dictate steps: "open the file, find the array, add an entry, then…". Resist it. You're guessing at an implementation you haven't seen — and Claude will dutifully follow your guess even when the codebase has a better way. Say the outcome ("the footer links to the new guide, styled like its neighbours") and constrain what must not change. Let the builder pick the route; you hold the destination.

Point at examples — the strongest trick there is

One line beats three paragraphs of description: "follow the pattern in @Header.astro". Existing code is the most precise spec you own — naming, spacing, idioms, all included. Whenever the project already contains something similar to what you want, point at it.

The shape, filled in

A small real task wearing the shape:

Example — a filled-in everyday task 
CONTEXT: Read CLAUDE.md and @src/components/Footer.astro. The footer has a "Learn" column.

GOAL: The Learn column also links to the new /claude-code/ guide, matching the existing entries.

CONSTRAINTS: touch only Footer.astro; same classes and style as the neighbouring links; nothing else changes.

VERIFY: npm run build passes; show me the rendered HTML of the new link.

FINISH: commit as "feat: footer link to Claude Code guide".

Notice what the parts did: CONTEXT named the exact file, GOAL described the end state, CONSTRAINTS kept the diff to one file, VERIFY demanded proof, FINISH banked the work. Thirty seconds to write; it reads like a work order, because it is one.

Up next: the two prompts you'll run most days of your life — the Daily Feature prompt and the Bug-Fix prompt — both just this shape, pre-filled for their situations.

FAQ

Frequently Asked Questions

What are the five parts of a good Claude Code prompt?
CONTEXT (what to read, one line of situation), GOAL (the outcome that should be true), CONSTRAINTS (what must not change), VERIFY (the check that proves it works) and FINISH (update memory files, commit).
Why describe the goal as an outcome instead of steps?
Because Claude is better at choosing an implementation than you are at guessing one. Steps you dictate get followed even when the codebase has a better way; an outcome plus constraints lets the builder pick the route while you hold the destination.
What belongs in CONSTRAINTS?
Scope limits ("touch only what this feature needs"), conventions to follow, and standing rules like "no new dependencies without asking". Constraints prevent the classic AI failure of "improving" things you never asked about.
What makes a good VERIFY step?
Something checkable, not vibes: "npm run build passes", "show me the rendered HTML of the form", "test with input 100 and confirm the result is 1". VERIFY converts "looks done" into "provably done".