How do I install the Factory Verify skill?

Run npx skillmds@latest add addyosmani/factory-verify-2 in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Factory Verify safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Factory Verify?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Factory Verify free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Factory Verify?

Addy Osmani (@addyosmani) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Factory Verify by addyosmani — Agent Skill

Name: Factory Verify
Author: Addy Osmani

Factory Verify

Verify an open factory PR before human review - re-runs gates, checks the test proves the fix, checks scope and test tampering. Use when reviewing a factory PR, running the PR review routine, or asked to independently check a change.

Addy Osmani 46a6dc1 3.0 KB Updated Sep 17, 2026 69.5k repo stars

File contents

Factory verify

Use this when a PR already exists and you are the check standing between it and a human. For verification during implementation, the factory-verifier subagent is the right tool; this skill is the PR-level version and can be driven by a GitHub-triggered routine.

Procedure

Read docs/factory/CONTRACT.md, then docs/factory/CHARTER.md for the tier, load-bearing globs, and definition of done.
Check out the PR branch.
Run the required gate level yourself. Do not trust the FACTORY_GATES line in the PR body; produce your own and compare. A mismatch is the finding.
Run the checks the deterministic gates cannot make:
- Does the test fail without the implementation? Start from a clean committed branch and run ./.factory/scripts/prove-test.sh <base-ref> --test-path <test-path> -- <focused-test-command>. Do not use git stash or an ad hoc destructive revert.
- Were pre-existing test files modified? Any change there needs an explicit, argued justification in the PR body.
- Does the diff stay inside the declared scope?
- Is done_when literally true?
For anything touching a load-bearing path, or any PR where the diff looks suspiciously clean, additionally run the factory-critic subagent and include its output.

Reporting

Post one PR comment. Structure it so a human reads the verdict first and the detail only if they need it.

### Factory verification

**Verdict:** accepted | accepted-with-reservations | rejected
**Human read required:** yes (<reason>) | no

<the FACTORY_GATES line, verbatim>

| Check | Result |
|---|---|
| Gates reproduce PR claim | yes / no |
| Test fails without fix | yes / no / could-not-determine |
| Pre-existing tests untouched | yes / no |
| Scope within declared files | yes / no |
| done_when literally true | yes / no |

**Must fix**
1. ...

**Critic** (load-bearing changes only)
<factory-critic output>

Apply the label factory:verified or factory:rejected.

Write one unique verify run record under docs/factory/runs/; do not append to STATE.md.

What this is for, and what it is not

This routes a human's attention. It is not an approval and it never merges.

The value is allocation: a human reads the flagged PRs closely and gives the rest a confirming glance, instead of spreading the same attention evenly over everything. That reallocation is the whole point, and it only works if the flags are trustworthy, which is why the standing bias is to reject when uncertain.

Standing bias

Reject when uncertain. A false accept is worse than no verification, because it spends a human's trust that was never earned. They will read the next one less carefully because this one said it was fine.

---name: factory-verify-2description: Verify an open factory PR before human review - re-runs gates, checks the test proves the fix, checks scope and test tampering. Use when reviewing a factory PR, running the PR review routine, or asked to independently check a change.---# Factory verifyUse this when a PR already exists and you are the check standing between it and a human.For verification during implementation, the `factory-verifier` subagent is the right tool;this skill is the PR-level version and can be driven by a GitHub-triggered routine.## Procedure1. Read `docs/factory/CONTRACT.md`, then `docs/factory/CHARTER.md` for the tier, load-bearing globs, and definition of done.2. Check out the PR branch.3. Run the required gate level yourself. Do not trust the `FACTORY_GATES` line in the PR body; produce your own and compare. A mismatch is the finding.4. Run the checks the deterministic gates cannot make: - Does the test fail without the implementation? Start from a clean committed branch and run `./.factory/scripts/prove-test.sh <base-ref> --test-path <test-path> -- <focused-test-command>`. Do not use `git stash` or an ad hoc destructive revert. - Were pre-existing test files modified? Any change there needs an explicit, argued justification in the PR body. - Does the diff stay inside the declared scope? - Is `done_when` literally true?5. For anything touching a load-bearing path, or any PR where the diff looks suspiciously clean, additionally run the `factory-critic` subagent and include its output.## ReportingPost one PR comment. Structure it so a human reads the verdict first and the detail only ifthey need it.```markdown### Factory verification**Verdict:** accepted | accepted-with-reservations | rejected**Human read required:** yes (<reason>) | no<the FACTORY_GATES line, verbatim>| Check | Result ||---|---|| Gates reproduce PR claim | yes / no || Test fails without fix | yes / no / could-not-determine || Pre-existing tests untouched | yes / no || Scope within declared files | yes / no || done_when literally true | yes / no |**Must fix**1. ...**Critic** (load-bearing changes only)<factory-critic output>```Apply the label `factory:verified` or `factory:rejected`.Write one unique `verify` run record under `docs/factory/runs/`; do not append to`STATE.md`.## What this is for, and what it is notThis routes a human's attention. It is not an approval and it never merges.The value is allocation: a human reads the flagged PRs closely and gives the rest aconfirming glance, instead of spreading the same attention evenly over everything. Thatreallocation is the whole point, and it only works if the flags are trustworthy, which iswhy the standing bias is to reject when uncertain.## Standing biasReject when uncertain. A false accept is worse than no verification, because it spends ahuman's trust that was never earned. They will read the next one less carefully becausethis one said it was fine.

Frequently asked questions