human-pass
Skill15 starsChanged 4 months agoMITView on GitHub
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.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- lupsalexandra33/ilabsro-designtheir own version, first seen Oct 25, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- lupsalexandra33/ilabsro-design★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository30 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- llms.txtllms.txt
- app-devSkill
- architectureSkill
- buildSkill
- checkpointSkill
- context-mgmtSkill
- debugSkill
- dreamSkill
- evalSkill
- experimentSkill
- forgeSkill
- frontendSkill
- governance-syncSkill
- handoffSkill
- helpSkill
- ingestSkill
- initSkill
- knowledge-graphSkill
- landing-pageSkill
- marketing-siteSkill
- metricsSkill
- orchestrationSkill
- qualitySkill
- retrospectiveSkill
- reviewSkill
- shipSkill
- simplifySkill
- tearitapartSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 30
Only what the human alone can verify:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
<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:
- The exact control, named as it appears on screen. Mine the real labels from the UI source; never invent or paraphrase them.
- The exact input, paste-ready. Real URLs, real ids, real values, one per line.
- What should happen, in one sentence.
- 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>Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.