Builds stakeholder-readable scripted manual test cases from a feature spec in four formats: a step-table (preconditions / steps / expected result / actual / pass-fail / notes) for spreadsheet review, a Gherkin Given/When/Then format for BDD-aware teams, a business-language UAT script with acceptance-criteria mapping and contractual sign-off (references/uat-format.md), and a one-line-per-item execution checklist for smoke / on-call / bug-bash / compliance sweeps (references/checklist-format.md). Each script is self-contained (no implicit team knowledge), single-scenario (one happy + N edge per script), and includes the data setup the tester needs without being a developer. Use when a feature can't be (or shouldn't be) fully automated and a human tester needs an executable script or checklist - UAT sign-off rounds, regression baselines, certification testing, deploy smoke checklists, exploratory follow-up scripts.
94
88%
Does it follow best practices?
Impact
95%
0.98xAverage score across 10 eval scenarios
High
Do not use without reviewing
{
"context": "A five-line paragraph - 'given the warehouse is set up, when the operator scans the pallet the usual way, then receiving works' - bundling a clean receipt, an over-receipt and a short receipt, against a data file that supplies the operator badge, the dock-door binding without which no scan is accepted, the mandatory LPN-then-bin scan order (with the reverse-order message that operators keep raising as a false defect), five still-open purchase orders out of eight, and the exact handheld text for each outcome. Predicted baseline failure: the agent emits well-formed Given/When/Then but keeps the vagueness intact - 'Given the warehouse is configured for receiving', 'Given a purchase order exists for 120 units', 'When the operator scans the pallet', 'Then the goods are received successfully' - inventing generic PO and LPN placeholders instead of using PO-88404 onward, omitting the dock-door binding and the scan order entirely so a night-shift operator still cannot reach the first scan, and assigning every scenario to the same PO, which the second scenario can no longer receive against.",
"type": "weighted_checklist",
"checklist": [
{
"name": "Deliverable exists at the named path",
"description": "A markdown document exists at docs/receiving-scenarios.md, written as Given / When / Then. Any other path scores zero; prose-only steps with no Given/When/Then shape score at most half.",
"max_score": 5
},
{
"name": "One behaviour per scenario",
"description": "The three behaviours - receipt matching the order, over-receipt, short receipt - are separate scenarios so a failure names one of them. Full marks also for splitting over-receipt into within-tolerance and above-tolerance. A single scenario covering more than one of the three scores zero. Two of the three covered scores at most half.",
"max_score": 22
},
{
"name": "Shared setup replaces 'the warehouse is set up'",
"description": "MUST NOT leave a vague precondition. The setup states concretely: the handheld and client, the operator badge OP-1020, binding to dock door DD-03, the SKU WID-2200 with 120 units ordered, the LPN labelling, and the destination bin RCV-A-01. Any surviving 'the warehouse is set up', 'the system is configured', 'the operator is logged in' with no badge, or an omitted dock-door binding scores zero, since without the binding the first scan is refused. Setup present but missing the bin or the SKU scores at most half.",
"max_score": 26
},
{
"name": "The scan order is spelled out",
"description": "The scenarios state that the pallet licence plate is scanned before the destination bin, and the document records that `Unexpected scan - expecting LPN` from scanning in the reverse order is correct behaviour rather than a defect - the false defect the night shift keeps filing. 'Scans the pallet the usual way' or any wording that does not fix the order scores zero. Correct order stated but the false-defect note omitted scores at most half.",
"max_score": 20
},
{
"name": "Then steps assert the handheld or console text with figures",
"description": "MUST NOT assert that receiving worked. Each Then names what appears, with values - `Receipt complete 120/120`, the PO moving to `Received` / `Received (over)` / `Partially received`, `Over tolerance - supervisor override required`, the discrepancy note under Receiving > Discrepancies. Any Then of the form 'receiving works', 'the goods are received successfully', 'the system handles it correctly' scores zero. Concrete outcomes in most scenarios with one vague one scores at most half.",
"max_score": 24
},
{
"name": "Purchase orders allocated so the pool survives",
"description": "Each scenario is given its own open purchase order from PO-88404 to PO-88408 - never PO-88401 to PO-88403, which are already closed - and the document tells a tester what to do when their scenario's order has been consumed, plus states that the pool only refills at the quarterly rebuild. Reusing one PO across scenarios that each close it scores zero. Assigning distinct open POs but giving no guidance for a consumed one scores at most half. Using invented PO numbers scores zero.",
"max_score": 20
},
{
"name": "Supervisor override covered where it is required",
"description": "The above-tolerance scenario includes scanning supervisor badge S-4471, and states that nothing is received until it is. An over-receipt scenario that stops at the refusal message without the override path scores at most half; omitting the badge identity scores zero.",
"max_score": 12
},
{
"name": "Failure capture",
"description": "A structured place to record which scenario and step failed, expected versus observed, and a defect reference. Absent scores zero.",
"max_score": 8
}
]
}