architect-loop

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.

Spec-writing stage skill for the architect factory: synthesizes the run's conversation, repo evidence, and research findings into `docs/spec/<run>.md` after grounding. Invoked by the strategist subagent the orchestrator dispatches during `/architect` intake — or directly by the orchestrator in `/architect-fast` (that skill's stage-skill deltas apply) — before decomposition into issues.

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.

Factory-context integrate stage (end-of-run shipping) for one dedicated builder subagent dispatched by the orchestrator after the fix wave has merged, after a GREEN verdict, or after a recorded ruling skips the review. First step is the docs pass — update product docs from the change-context digest — then end-of-run integration, postflight, PR or markdown finish prep, and a digest DRAFT; returns evidence for the orchestrator to rule on.

Use when the user asks for discovery-scale research that informs a decision: brainstorming a project or feature, choosing a technology, or requests like "research X", "what's the state of the art", or "deep research". Use this skill to turn broad, uncertain questions into sourced decision evidence and a reusable research handoff. For narrow slice-level fact checks inside the build loop, /architect handles those inline.

Test-driven development for factory builders. Use when a ship job implements at the issue's pre-agreed seams — the red -> green loop, one test then one minimal implementation per cycle, never a refactor while RED.