メニュー
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.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/addyosmani/factory --skill factory-verifyコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SKILL.md を表示中
Claim and implement one ready GitHub issue, run fail-closed gates, obtain independent verification, and open a draft pull request.
Inspect factory health, stale work, CI, security advisories, and recent run evidence without implementing fixes.
Turn an ambiguous factory issue into human-approved product, behavior, design, and implementation slices. Use interactively before implementation.
SOC 職業分類に基づく
| name | factory-verify |
| description | 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. |
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.
docs/factory/CONTRACT.md, then docs/factory/CHARTER.md for the tier,
load-bearing globs, and definition of done.FACTORY_GATES line in the PR
body; produce your own and compare. A mismatch is the finding../.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.done_when literally true?factory-critic subagent and include its output.Post one PR comment. Structure it so a human reads the verdict first and the detail only if they need it.
### Factory verification
accepted | accepted-with-reservations | rejected
yes () | no
| 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 |
| doneApply the label factory:verified or factory:rejected.
Write one unique verify run record under docs/factory/runs/; do not append to
STATE.md.
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.
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.