human-pass

<skill id="human-pass">

<purpose>

A release that only machines have checked has not been checked. The human is the

only instrument that can see whether the thing FEELS broken, whether an upgrade

ate real data, and whether an error message is honest. This skill turns that

irreplaceable half hour into a designed pass instead of random clicking.

</purpose>

<why>

A 15-minute guided pass on a real device found a false paywall, a broken

selection interaction, reversed ordering, and two dead source paths. None were

visible to CI. In a parallel project, 7 defects found on a phone had been sitting

under 506 green tests. The gap is not test coverage; it is that some properties

only exist on the far side of a real screen and real data.

</why>

<scope>

Only what the human alone can verify:

• upgrade survival against THEIR real data, before anything else
• rendering, motion, and feel on the actual device
• whether failure states are honest (a fake success is worse than an error)
• flows that cross apps, accounts, or hardware

Everything a machine can check stays in CI. A pass that spends the human's

attention on something a test could have caught has wasted the only instrument

that cannot be automated.

</scope>

<form>

Literal or it does not count. The first draft of the founding example was

rejected in four words: "not a script, literally what to tap."

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.

1. The exact input, paste-ready. Real URLs, real ids, real values, one per line.
2. What should happen, in one sentence.
3. 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.

</form>

<ordering>

Worst case first. Data survival before features: if an upgrade ate the library,

the pass stops there and nothing else matters. Then the paths the release

actually touched, drawn from the diff, not from a generic checklist. Then the

cheap wide sweep for feel. Destructive or irreversible actions come last and are

usually skipped outright: never ask a human to gamble production data to test a

restore path.

</ordering>

<bundling>

Attention is the scarce resource, so the count of passes matters as much as

coverage. State the time cost up front and design to ONE sitting. Batch every

question that needs the same build, the same device, and the same state, so the

human is never called back for something that could have ridden along.

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.

</bundling>

<close>

The pass ends with a verdict, not a vibe: a thumbs-up, or findings. Findings come

back as prose and screenshots; converting them into issues is the agent's job,

not the human's. Record the verdict as a state-change receipt on the release

issue, and say plainly what the thumbs-up unlocks (the next build, the

submission, the deploy promotion).

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

</close>

<anti-patterns>

• Generic checklists ("test the main flows"). If it could have been written

without reading this diff, it is not a pass.

• Steps whose outcome is unstated, so any result looks like a result.
• Asking for something CI already proves.
• Silent scope: if the pass skips an area, say which and why.
• Assuming the human will improvise around a broken step. They will report it as

a bug in the pass, and they will be right.

</anti-patterns>

<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>

</skill>