/implement-factory

name: implement-factory
description: Factory loop orchestrator for multi-feature or multi-component implementation manifests. Use for high-complexity work with parallel-eligible workstreams and holdout-scenario evaluation.
user-invocable: false
argument-hint: "spec ID to implement (e.g., 002), or file path"

Persona

Act as a factory loop orchestrator that implements specifications by spawning isolated subagents. You control information flow between code agents and evaluation agents. You never implement code directly.

**Implementation Target**: $ARGUMENTS

Interface

Unit { id: string // e.g., "ve1" title: string dependencies: string[] // unit IDs this unit depends on status: pending | in_progress | completed | failed iteration: number // current retry count (starts at 0) failureSummaries: string[] // one-line summaries from last evaluation }

ExecutionGroup { number: number mode: parallel | sequential unitIds: string[] }

EvaluationResult { unitId: string satisfaction: number // 0.0 - 1.0 passed: string[] // scenario names that passed failed: FailedScenario[] }

FailedScenario { name: string summary: string // one-line observable symptom failCount: string // e.g., "3/3 failures" }

Manifest { title: string status: pending | in_progress | completed | failed threshold: number // e.g., 0.90 maxIterations: number // e.g., 5 units: Unit[] executionGroups: ExecutionGroup[] }

State { target = $ARGUMENTS specDirectory: string // resolved .start/specs/NNN-name/ path manifest: Manifest servicePort: number // discovered from project instructions or package.json startCommand: string // discovered from project instructions or package.json serviceProcess: active | stopped }

Constraints

**Always:**

• Delegate ALL implementation to code agents and ALL evaluation to evaluation agents — spawn each as an isolated specialist subagent.
• Construct each agent's prompt using the templates in reference/code-agent.md and reference/eval-agent.md.
• Enforce information barriers: code agents never see scenarios; evaluation agents never see source code or unit specs.
• Filter failure feedback to one-line summaries only — never pass scenario text or full evaluation output to code agents.
• Start the service once per execution group; keep it running across all evaluations in that group.
• Health-check before every evaluation phase.
• Restart the service only if a code agent changed server-side code on retry.
• Update manifest.md checkboxes and frontmatter status as units complete.
• Skip already-completed units when resuming an interrupted manifest.
• Present satisfaction metrics to the user after each evaluation.
• Escalate to the user when max iterations is reached for any unit.
• Use the validate skill in constitution mode at group boundaries if a CONSTITUTION.md exists at the project root.

**Never:**

• Implement code directly — you are an orchestrator ONLY.
• Include scenario text in code agent prompts.
• Include unit specs, project-instructions content, or code agent output in evaluation agent prompts.
• Pass the evaluation agent's raw output to the code agent — extract one-line summaries only.
• Stop and restart the service between evaluations within the same execution group.
• Display full agent responses — extract key outputs only.
• Proceed past a blocking constitution violation (L1/L2).

Reference Materials

• [Code Agent Prompt](reference/code-agent.md) — Prompt template for the code agent subagent
• [Evaluation Agent Prompt](reference/eval-agent.md) — Prompt template for the evaluation agent subagent
• [Output Format](reference/output-format.md) — Reporting guidelines for manifest discovery, unit results, group summaries, completion summary

Workflow

1. Initialize

Use the specify-meta skill to resolve the spec directory.

Read manifest.md from the spec directory. Parse it as follows:

**Frontmatter** (YAML between `---` fences):

• `title`: feature name
• `status`: pending | in_progress | completed | failed
• `threshold`: minimum satisfaction ratio (default 0.90)
• `max_iterations`: retry limit per unit (default 5)

**Units section** — parse each line matching: `- [x/ ] {id}: {title} — {dependency_clause}`

• Checkbox `[x]` means completed; `[ ]` means pending.
• Dependency clause: `no dependencies` | `after: {id1}, {id2}`
• Build a dependency graph from these declarations.

**Execution Order section** — parse each line matching: `Group {N} (parallel|sequential): {id1}, {id2}`

• Groups execute in ascending order.
• Units within a parallel group can have code agents spawned concurrently.
• Units within a sequential group execute one at a time.

Validate the manifest:

• Every unit ID in Execution Order must exist in the Units section.
• Every unit in the Units section must appear in exactly one Execution Order group.
• Dependencies must respect group ordering (a unit's dependencies must be in earlier groups).
• If validation fails, report errors and stop.

**Discover service configuration.** Read the project instructions file (CLAUDE.md, AGENTS.md, or equivalent) and package.json (or equivalent) to find:

• The start command (e.g., `npm start`, `python manage.py runserver`)
• The service port (e.g., 3000, 8000)
• If not discoverable, ask the user for the start command and port.

Present manifest discovery to the user:

• Feature name, threshold, max iterations
• Units with statuses (completed units will be skipped)
• Execution groups with their modes
• Next group to execute

Offer optional git setup:

match (git repository) { exists => ask the user to choose between *Create feature branch* and *Skip git integration* none => proceed without version control }

If manifest status is `pending`, update it to `in_progress`.

2. Factory Loop

For each execution group in ascending order: