Skip to content
cccskills
FreePublished on GitHub

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.

The English summary is being prepared. Showing the original description.

See how to install

Files included (1)

  • SKILL.md3.0 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

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

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

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.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Claim one live GitHub queue item, implement it end to end, run fail-closed gates and independent verification, then open a draft PR. Use for one ready-to-implement issue or the implementation routine.

The English summary is being prepared. Showing the original description.

addyosmani/factory-demo7Updated Aug 19, 2026

Claim and implement one ready GitHub issue, run fail-closed gates, obtain independent verification, and open a draft pull request.

The English summary is being prepared. Showing the original description.

addyosmani/factory-demo7Updated Aug 19, 2026

Inspect factory health, stale work, CI, security advisories, and recent run evidence without implementing fixes.

The English summary is being prepared. Showing the original description.

addyosmani/factory-demo7Updated Aug 19, 2026

Scheduled health sweep that closes the factory loop - reads CI failures, recent commits, dependency and security advisories, and live queue labels, then files issues and writes an immutable run record. Use for the nightly or weekly monitor routine.

The English summary is being prepared. Showing the original description.

addyosmani/factory-demo7Updated Aug 19, 2026

Turn an ambiguous factory issue into human-approved product, behavior, design, and implementation slices. Use interactively before implementation.

The English summary is being prepared. Showing the original description.

addyosmani/factory-demo7Updated Aug 19, 2026

Turn a ready-to-spec queue item into an approved plan through explicit human gates. Use when an item needs scope decided before code exists, when planning a feature, or before starting a migration. Runs interactively - not for unattended routines.

The English summary is being prepared. Showing the original description.

addyosmani/factory-demo7Updated Aug 19, 2026

See all skills by addyosmani

Report a problem with this skill