Numbered Steps and Checklists — The Secret Sauce for Actionable Prompts

"A model doesn't suffer from decision fatigue. It suffers from vague instructions." — Your future, less annoyed self

You already know the core principles: clarity, specificity, grounding, and iteration. You've learned to state acceptance criteria and include constraints. Now we get nitty-gritty: how to structure the actual instructions so the model behaves like a reliable teammate and not a mood board of half-baked ideas.

Why numbered steps and checklists? (Quick reminder, no intro repeat)

Numbered steps give sequence and control. Checklists give coverage and verification. Use numbered steps when order matters and the model must perform a process. Use a checklist when you want the model to ensure multiple independent conditions are met. Often you'll combine the two: step-by-step execution followed by a checklist of acceptance criteria (recall Position 3) and constraints (recall Position 4).

The difference in 30 seconds

How to write effective numbered steps

1. Start with a role and outcome. One short line: "You are an expert X whose job is Y." This grounds the model.
2. Use imperative verbs. Start every step with a verb: Extract, Normalize, Explain.
3. Be explicit about order and parallelism. Spell out when steps can run in parallel: "Steps 2–3 can be done in any order; do step 4 after both finish."
4. Limit step scope. Each step should do one thing. If a step is long, split it.
5. Include decision points and fallbacks. If something fails, tell the model what to do next.
6. Quantify where possible. Use numbers, formats, thresholds: "Return top 5 results in descending relevance."
7. Reference acceptance criteria and constraints inline. Example: "Validate against the acceptance criteria below before returning output. If any criterion is unmet, return 'INCOMPLETE' with reasons."

Example — bad vs good:

Bad:

1. Make a summary. 2. Fix issues.

Good:

1. Read the article and extract the 3 main claims.
2. For each claim, write a 2-sentence summary and cite the paragraph number (format: P#).
3. If a claim lacks explicit support, flag it as "unsupported" and list evidence needed.

How to write sharp checklists

• Phrase items as testable statements. Avoid: "Make it clear." Prefer: "Each paragraph begins with a topic sentence."
• Group by type. E.g., Content checks, Style checks, Safety checks.
• Include pass/fail actions. For each failed item, instruct the model on remediation (rewrite, annotate, ask for more input).
• Make them concise and atomic. One idea per bullet.

Example checklist for the summary task above:

• Contains exactly 3 claims, each labeled Claim 1–3
• Each claim has a 2-sentence summary and P# citation
• No hallucinated facts (flag and list uncited claims)
• Word count <= 250

If any box is unchecked, output a JSON object {"status":"INCOMPLETE","issues":[...]} and stop.

Templates you can steal (use, tweak, love)

Code block template — Numbered Steps + Checklist:

You are [role]. Goal: [clear, measurable goal].

Steps:
1. [Verb] [what], [how], [format/output].
2. [Verb] [what], [how], [format/output].
3. If [condition], then [fallback]. Else continue.

Checklist (must pass before final output):
- [ ] [testable condition 1]
- [ ] [testable condition 2]

If checklist fails:
Return {"status":"INCOMPLETE","failed":[list items],"notes":"[brief fix steps]"}

Else:
Return {"status":"COMPLETE","result": [your standard output]}

Use this as the “magic scaffolding” for any prompt that needs reliability.

Handling branching, loops, and parallel tasks (yes, the fancy stuff)

• Branching: Spell out conditions. "If the document is >2000 words, summarize into 3 tiers: 50, 200, 800 words. Otherwise proceed to step X."
• Loops: Limit iterations. "Repeat steps 4–6 for each section up to a max of 10 sections; stop early if all sections pass the checklist." This prevents endless churn.
• Parallel tasks: Mark them explicitly. "Run steps 2 and 3 in parallel; merge results in step 4." Models don't actually 'parallelize' but they follow the logical structure you give.

Real-world example: Prompt for a model to clean a dataset

1. You are a data-cleaning assistant. Goal: return a cleaned CSV and a remediation log.
2. Load the CSV and detect column types (string, int, float, date).
3. For each numeric column: remove rows with NaN > 20% of column; otherwise impute with median.
4. For date columns: convert to ISO 8601; if conversion fails for >5% rows, list affected rows and stop.
5. For categorical columns with >50 unique values: collapse infrequent categories into "OTHER".
6. Output: cleaned CSV, and a JSON log {"removed_rows":N,"imputations":{...},"issues":[]}.

Checklist (must pass):

• No missing values in primary_key column
• All dates in ISO 8601
• Numeric values within realistic constraints (min, max)

If a checklist item fails, return status INCOMPLETE with the remediation steps to fix or ask the user for guidance.

Common pitfalls and how to avoid them

• Vague verbs: "Check" → replace with "Confirm X equals Y".
• Overly long steps: break them into atomic actions.
• Missing failure branches: always tell the model what to do when something goes wrong.
• Forgetting acceptance criteria: reference them inline and via the final checklist (you learned this earlier — use it!).

Pro tip: when in doubt, write the checklist first — it tells you what 'done' looks like and forces meaningful steps.

Closing — The tiny ritual that saves hours

Before you send the prompt: read the steps and the checklist aloud. If you can’t read the checklist and immediately know what "PASS" looks like, rewrite. Good prompts are boringly unambiguous. They are not creative writing exercises — they're construction blueprints.

Final one-liner to remember:

Numbered steps = how to do it. Checklists = how to know it's done.

Now go forth and make prompts that behave like trained interns — reliable, precise, and inexplicably eager to follow your numbered commandments.