メニュー
Use when the strategist drafts per-issue graded checks after decomposition and before builder dispatch. Produces one check file per issue at `docs/checks/<run>/<slice>.md`, frozen in git, read-only after.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when the user asks to architect-fast a change, run the light factory lane, or factory-build a small goal — a few files, roughly one sitting, at most ~3 parallel issues — into a specced plan with parallel builders, one builder-performed closing review-and-fix, and a single PR. Same loop shape as /architect with the per-issue grading machinery removed; for larger, riskier, or many-issue work use /architect instead.
Use when the user asks to architect, run or continue the autonomous software factory, turn a goal into a hardened tracker issue plan, dispatch builder jobs, grade finished work, diagnose blockers, or finish a factory run.
Shared vocabulary for designing deep modules and for naming factory concepts consistently. Load before writing a spec, decomposing issues, freezing checks, or reviewing a diff - anywhere "module," "interface," "issue," or "frozen check" need to mean the same thing to every skill, builder, and reviewer. Also covers dependency categories for deepening and the parallel design-it-twice pattern for exploring interfaces before committing to one.
Use when the architect factory orchestrator dispatches a fresh strategist subagent to harden a draft spec: falsify it with file:line evidence, fold the surviving findings into a revised spec, decompose it (issues plus checks), and stress-test its own decomposition before returning all drafts. Never commits, touches the tracker, or edits product code.
Use for the closing whole-run review in the architect factory — the only model review in the loop: dispatched by the orchestrator, at finish, to one fresh strategist subagent that audits the entire run diff for defects only isolated parallel slices can produce, checks the merged whole against the spec, verifies every candidate finding, and delivers a review spec plus draft fix issues and draft graded checks — it never edits product code or the mutable test suite. Never description-triggered or self-invoked mid-run; the orchestrator calls it explicitly once every issue has closed.
Use when decomposing a hardened spec into tracker issues: cutting tracer-bullet vertical slices through every layer, ordering structural work first with blocking edges, maximizing the disjoint parallel frontier, publishing producer/consumer interface contracts, and attaching a compact change-skeleton to each issue. Invoked only from an explicit architect dispatch — by the harden strategist subagent in `/architect`, or directly by the orchestrator in `/architect-fast` — after the spec is written; never left to description-trigger discovery.
| name | frozen-checks |
| description | Use when the strategist drafts per-issue graded checks after decomposition and before builder dispatch. Produces one check file per issue at `docs/checks/<run>/<slice>.md`, frozen in git, read-only after. |
One check file per issue, at docs/checks/<run>/<slice>.md. Open it with
purpose, a spec pointer, and a fix contract stating what a failure means and
which file to fix — that header is the closing review's entire intent context
for the issue. Write for a reader with no other memory of this run, in the
codebase-design vocabulary (skills/codebase-design/SKILL.md).
Normative from the shipped runner, skills/architect/check-runner.ps1; cite
it, do not restate it divergently from skills/architect/dispatch.md's
## Check-runner dispatch. A graded item is exactly:
- RUN: `command` -> exit:<n> with optional trailing match:"<substring>".
match: is a fixed, case-sensitive stdout substring — never a regex. A RUN
item without an -> exit:<n> expectation makes the runner exit 5 with no
partial evidence kept; that is a check defect, not a builder defect. Every
other line — rationale, judge-only intent items — is read by the closing
review and the orchestrator, never graded by the runner.
Each RUN item asserts exactly one falsifiable fact. Run every draft command against the current tree before freezing; a check that cannot fail is not a check.
Attack-list, run before freeze:
git grep is blind to a builder's untracked new files in a worktree that
hasn't staged them; use filesystem grep/test there instead.git check-ignore <path>; a gitignored path
never gets graded no matter what the check says.All check files for a run commit to the factory branch before any builder is
dispatched; record the freeze SHA on the tracking issue.
After that commit, everything under docs/checks/ is read-only to every
builder and reviewer — an edit there is an automatic FAIL regardless of the
rest of the job report. An intent change discovered after freeze is a
ruling: it goes in the run's rulings file, never a rewrite of the frozen
check.
An issue or check file may note a duration hint in prose (e.g. "full suite ~20m") so a monitor doesn't mistake legitimate long work for a stall. A hint is informative only — never a kill ceiling, never a RUN expectation.