addyosmani/factory

# Factory implementation for Codex

Read `docs/factory/CONTRACT.md`, `docs/factory/CHARTER.md`, and then the canonical workflow
in `.claude/skills/factory-implement/SKILL.md`. Use Codex's subagent mechanism for the fresh
verifier context. If an independent context is unavailable, stop before opening a non-draft
pull request.

# Factory monitoring for Codex

Read `docs/factory/CONTRACT.md`, `docs/factory/CHARTER.md`, and then the canonical workflow
in `.claude/skills/factory-monitor/SKILL.md`. Write a unique run record rather than appending
to shared state.

# Factory specification for Codex

Read `docs/factory/CONTRACT.md`, `docs/factory/CHARTER.md`, and then the canonical workflow
in `.claude/skills/factory-spec/SKILL.md`. Keep every human approval gate interactive. Use a
fresh subagent for the critic pass when the workflow requires one.

# Factory status for Codex

Read `docs/factory/CONTRACT.md`, then follow the report workflow in
`.claude/commands/factory.md`. Live GitHub labels and PRs outrank the Markdown snapshots.
This skill reports only; it never merges, approves, labels, or closes work.

# Factory triage for Codex

Read `docs/factory/CONTRACT.md`, `docs/factory/CHARTER.md`, and then the canonical workflow
in `.claude/skills/factory-triage/SKILL.md`. Follow that workflow using the tools available
in Codex. GitHub labels are the live queue; `QUEUE.md` is only a snapshot.

# Factory tuning for Codex

Read `docs/factory/CONTRACT.md`, then follow `.claude/commands/factory-tune.md`. Propose
changes and record accepted human decisions in `docs/factory/DECISIONS.md`; never edit the
charter or gate requirements on your own initiative.

# Factory PR verification for Codex

Read `docs/factory/CONTRACT.md`, `docs/factory/CHARTER.md`, and then the canonical workflow
in `.claude/skills/factory-verify/SKILL.md`. Use a fresh subagent for any critic pass and the
shared `.factory/scripts/prove-test.sh` procedure for negative test proof.

# Factory implementation

You implement **exactly one queue item per run**. Not two. If you finish early, stop.

Batching items is how a single wrong assumption becomes a wide diff nobody can review.

## Before writing any code

1. Read `docs/factory/CONTRACT.md`, then `docs/factory/CHARTER.md`.
2. Query GitHub for open issues labeled `factory:ready-to-implement`. The live label is
   authoritative; read the latest `factory-handoff:v1` comment for `done_when`, expected
   files, gate level, and confidence. `QUEUE.md` is only a snapshot. If the handoff is
   missing, duplicated, malformed, or inconsistent with the charter, move the issue to
   `factory:needs-info` and stop. If running locally without GitHub access, stop unless a

# Factory monitor

This is the stage that closes the loop. Without it a factory only processes work a human
remembered to file, which means the backlog reflects attention rather than reality.

**You file issues. You do not fix anything.** Mixing detection and repair in one run means
a bad detection becomes a bad commit before anyone sees it.

Read `docs/factory/CONTRACT.md` and `docs/factory/CHARTER.md` first.

## Sweep

Run each of these. Where a check is not applicable to this repo, say so rather than
silently skipping it.

# Factory spec

This skill exists because the cheapest place to fix a decision is before any code encodes
it. Once a model has written a thousand lines, changing direction is expensive and every
instinct is to patch instead.

**This skill is interactive.** It stops and waits for a human. Do not run it inside an
unattended routine; a routine that approves its own spec has no gates at all.

Read `docs/factory/CONTRACT.md` and `docs/factory/CHARTER.md` before gate 1.

## Gates

Four, in order. Stop at each one. Never merge two gates into a single pass. Never proceed

# Factory triage

You are the intake stage. Your output is a **sorted queue and a shortlist for a human**,
never merged code. You do not write implementation code in this skill.

## Before anything

1. Read `docs/factory/CONTRACT.md`, then `docs/factory/CHARTER.md`. The charter defines the tier, what is automatable, and what is
   load-bearing. **If the charter does not cover an item, the answer is `needs-info`, not
   a guess.** Silence in the charter means stop.
2. Query GitHub issue labels for current state. `docs/factory/QUEUE.md` is a snapshot and
   may lag while a triage PR is open. Do not use it to override a live label.

## Gathering work

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