human-pass

---

name: human-pass description: "Guide real-build acceptance: literal taps, real inputs, expected outcomes, worst case first, one sitting. Triggers: testflight, human pass, acceptance test, before we ship, what should I test, release checklist, device test." allowed-tools: Read, Bash, Grep, Glob, Write, Edit kernel: kind: methodology version: 1 side_effects: none confirmation: none

Each step gives:

1. The exact control, named as it appears on screen. Mine the real labels from the UI source; never invent or paraphrase them.
2. The exact input, paste-ready. Real URLs, real ids, real values, one per line.
3. What should happen, in one sentence.
4. What counts as a bug, when that is not obvious. Known rough edges get named so the human does not go hunting for something already on the board.

The tension is real and worth naming when it bites: more coverage per pass, or more passes. Prefer one thorough pass over three thin ones. When a finding will obviously force a rebuild, say so in the same breath, so the next pass is expected rather than a surprise.

Until that verdict exists, the release is not done, whatever CI says.

<on_complete> Report where the guide is, the time it should cost, the single worst-case check it opens with, and what the verdict unlocks. </on_complete>