2.0free~6 min

The five parts (and which one most prompts skip)

Artifact: your last prompt, audited against the five parts

1. The five parts

Every prompt that works has five parts. Some can be implicit; none can be absent. The parts:

  1. Role — the perspective the model is operating from. Senior reviewer. Skeptical critic. Junior teacher. (Optional. Use only when it changes behavior.)
  2. Context — the surrounding facts the model needs but doesn't have. Codebase, constraints, what you've tried, what can't change.
  3. Task — the verb, the noun, the bound. Refactor X to do Y. Review for Z. List the failure cases.
  4. Format — the shape of the output. JSON, prose, code-only, diff, bullet list, table.
  5. Examples / success criteria — what good looks like, in concrete form. Usually shown, not described.

If you write nothing else, write parts 2, 3, and 4. Those three carry most of the signal.

2. The one most prompts skip

It's format.

Most people specify what they want done and forget to specify what the output should look like. The model picks for you — usually prose, usually with hedges, usually with markdown headings you didn't ask for. Then you spend the next thirty seconds trying to extract the part you actually wanted.

Format is the cheapest leverage in prompting. One sentence — return JSON with keys X, Y, Z — turns a paragraph of prose into a structured response you can pipe into a tool, scan in three seconds, or compare across runs.

3. The same task, five parts versus none

Same review task. Two prompts.

textVibe — no parts
Can you review this function?

[function]
textSpec — five parts present
Role: senior backend reviewer.

Context: TypeScript, Express, called from a hot path (~1k req/sec). Used in production for 6 months. Test coverage is at 80%.

Task: review the function below. Find the three highest-impact issues — correctness or performance, not style.

Format: return a JSON array. Schema:
[{ severity: "high" | "med", category: "correctness" | "performance", description: string, suggested_fix: string }]

Example of a good entry:
{ severity: "high", category: "correctness", description: "userId is not validated; an attacker could pass a non-uuid and crash the handler", suggested_fix: "validate with zod schema before query" }

[function]

The spec version isn't longer because of fluff. Every sentence does work: rules out style nits, names the criteria, fixes the output shape, shows what a good answer looks like.

4. Try it

Look at the last prompt you sent.

The part you skipped is almost always the part the output went sideways on.