A requirements doc into an acceptance checklist you can tick off

When to use

A multi-page requirements doc, engineering and QA reading it differently, and an argument at acceptance time. You need a checklist where every line traces back to the source.

Preparation

Host version

0.1.2-alpha.5

Model

To fill

Mode / permissions

--profile headless / workspace-write / Windows 11 / node 22.22.2

Plugins required

None (add name & version after testing if used)

Input materials

A 1,225-character synthetic PRD for a points-redemption redesign, with two contradictions planted on purpose: section 3.1 says show redeemable items while 3.3 says show out-of-stock ones; section 4 promises the success rate will not drop while section 1 only gives a 2.3 percent conversion figure

Full instruction

Read prd.md and produce an acceptance checklist at acceptance.md.

[Output]
A table with columns: id | acceptance item | how to judge (what counts as pass) | source (section number and verbatim excerpt) | type (functional / edge / performance / interaction / data) | testability (automatable / manual / untestable)

[Hard constraints]
1. Every item must trace to the source. Anything untraceable stays out of the checklist and goes in a separate 'requirements not stated' section.
2. 'How to judge' must be an observable action or result. Never 'meets expectations', 'good experience', or 'works correctly'.
3. 'Untestable' is an allowed value, but it must say why (for example 'the source only says it must be fast, with no figure').
4. If the source contradicts itself, put it in a 'requirement conflicts' section quoting both passages. Do not pick one.
5. Do not add requirements the source lacks. Anything you think of belongs in a final 'suggested but not required' section, strictly separate from the checklist.

[Staged delivery]
Do only the first third of the document so I can check the format, then continue.

Report at the end: total items, count per type, testability distribution, how many are unstated, how many conflicts.

Copy full instruction

Run log

What the run showed

• Both planted contradictions were caught without being silently resolved: C-01 reports that 3.1 (show redeemable items) and 3.3 (show out-of-stock items) define the list set oppositely; C-02 reports that 'raise conversion' and 'success rate must not drop' may not even be the same metric, which the PRD never says.
• The 'how to judge' column contains nothing vague. Three real examples: the insufficient-balance check is written as 'construct pairs (P,B) with B<P and require the displayed difference D to equal P − B, e.g. P=1000, B=300 must show 700'; greying out is 'disabled is true and a click issues no redemption request, with a B≥P control group proving it is not always grey'; transactional consistency is 'inject a stock-decrement failure that affects zero rows and require all of: API failure, stock unchanged, balance unchanged, no new record, no success toast'.
• It judged three vague lines in the source as untestable rather than inventing thresholds: smooth on 4G, loads fast, success rate does not drop — each with what is missing (no quantitative metric, no budget or timing basis, no baseline or scope). That is the checklist's most valuable output: the source's defects surfaced.
• Fifteen 'not stated' items were listed separately (which product fields on the confirm page, which layer the button sits in, stock display format, failure messaging) and none leaked into the main table. The 12 suggestions sit in their own section.
• It added its own three-tier testability definition with per-tier criteria above the table. Nothing in my instruction asked for that; it is a sensible addition.

Output

After a successful run, list files and screenshots here, and note whether originals changed.

Acceptance checklist

Tap to tick each item off as you verify.

• Every item traces to the source; spot-check three against the original
• No unjudgeable wording such as 'meets expectations' or 'works correctly'
• Untestable items explain why
• Conflicts are listed separately rather than silently resolved
• 'Suggested' items are strictly separate from the checklist

Failures & boundaries

• Constraint 5 is the one that erodes: models love adding requirements and they sound reasonable. Keep 'suggested' in its own section or you lose track of what was actually asked
• The 'how to judge' column is the whole value. 'Can submit normally' says nothing; 'returns success within 3 seconds and the record appears in the list' is checkable
• Words like 'fast' and 'smooth' land in 'untestable' — that is a defect in the source, not the recipe. Surfacing it is itself the output

Claim this recipe Back to recipes