Pipeline

Value: Flow -- continuous, gated progression from slice to shipped code eliminates idle coordination overhead and makes quality evidence accumulate automatically.

Purpose

Orchestrates the build phase end-to-end: takes vertical slices from the queue, dispatches TDD pairs, runs full-team code review before push, enforces mutation testing and CI gates, and merges or escalates. The pipeline controller handles all operational tasks (running tests, pushing code, managing git) so team member agents focus exclusively on creative work.

Practices

Slice Queue Management

The pipeline reads vertical slices from event model output and maintains their state in

.factory/slice-queue.json

. See

references/slice-queue.md

for the full queue schema and operations.

Each slice carries a

context

block with enriched metadata for downstream pipeline stages: boundary annotations on each GWT scenario (so the gate can verify boundary coverage), an event model source path (so the TDD pair can consult the original model), related slice IDs for cross-slice dependency tracking, domain types referenced by the slice (enabling pre-implementation type discovery), and UI components referenced (triggering conditional context gathering when the slice touches the interface layer).

Ordering strategy: Walking skeleton first (the thinnest end-to-end path), then by dependency graph (slices whose predecessors are complete), then by priority. The first slice in any project must always be a walking skeleton.

Slice states: pending, active, blocked, completed, escalated. Only one slice may be active at a time unless running at full autonomy level, where parallel slices operate in isolated git worktrees (one worktree per active slice at

.factory/worktrees/<slice-id>

). See

references/autonomy-levels.md

Per-Slice Pipeline

Each slice flows through a fixed sequence of stages. Every stage has a binary quality gate. A gate failure routes back for rework; it never skips forward.

Decompose -- Invoke
```
task-management
```
to break the slice into leaf tasks with acceptance criteria. Output: task tree in
```
.factory/audit-trail/slices/<slice-id>/decomposition.json
```
.
Implement -- Before dispatching the TDD pair, the pipeline gathers pre-implementation context: architecture docs, glossary, existing domain types matching the slice's referenced types, and event model context from the slice. If the slice touches UI, design system components are included. This context is passed to the TDD orchestrator as
```
project_references
```
and
```
slice_context
```
so every phase agent operates with full domain awareness. The TDD pair then works through red-green-domain-commit cycles without consensus rounds. No team discussion during implementation. Output: passing tests, committed code, cycle evidence in
```
.factory/audit-trail/slices/<slice-id>/tdd-cycles/
```
.
Review -- Before pushing, invoke
```
code-review
```
with the full team for three-stage mob review (spec compliance, code quality, domain integrity). All review findings must be addressed before proceeding. See
```
references/gate-definitions.md
```
for review gate criteria.
Address feedback -- Route review findings back to the TDD pair. The pair fixes via their existing ping-pong process. Re-review scoped to flagged concerns only (unless critical-category feedback).
Mutation test -- Invoke
```
mutation-testing
```
scoped to changed files. Required: 100% kill rate. Survivors route back to the TDD pair.
Push and CI -- Pipeline pushes the branch and waits for CI. On infra failures at standard or full autonomy, auto-retry once. On test failures, route to triage.
Merge or flag -- If all gates pass, merge (auto at full autonomy, manual otherwise). If any gate failed after exhausting rework budget, escalate to human.

Quality Gates

Five binary gates. Each requires structured evidence. See

references/gate-definitions.md

for full criteria, evidence schemas, and failure routing.

Gate	Pass Criteria	Failure Route
TDD	Acceptance test passes, all units pass, domain review approved	Back to tdd pair
Review	All three stages PASS	Back to tdd pair with findings
Mutation	100% kill rate on changed files	Back to tdd pair with survivors
CI	Pipeline green	ci-integration triage
Merge	All upstream gates pass, no blocking escalations, branch current	Rebase and re-gate

Rework Protocol

Gate failures route back to the appropriate skill. Each gate allows a maximum of 3 rework cycles per slice. After 3 failures at the same gate, the pipeline halts the slice, compiles full context (all attempts, all evidence), and escalates to the human. See

references/rework-protocol.md

for routing rules and tracking schema.

Progressive Autonomy

The pipeline operates at one of three autonomy levels configured in

.factory/config.yaml

. See

references/autonomy-levels.md

for full details.

Conservative: All gates enforced, no auto-merge, human notified of every gate result, human approves every merge.
Standard: Auto-rework within budget, batch non-blocking findings, skip trivial review items, auto-retry CI on infra failures.
Full: Auto-merge when all gates pass, parallel slice execution using git worktree isolation (each active slice gets its own worktree; conflicts are detected at merge time), pair selection and slice ordering optimization. If
```
git worktree
```
is not available, the pipeline falls back to sequential execution and logs a warning.

Pipeline Operates Directly

Unlike the ensemble-team coordinator (which delegates everything), the pipeline controller directly executes operational tasks: running test suites, invoking mutation tools, pushing branches, checking CI status, managing git operations, updating queue state. Team member agents are invoked only for creative work: writing tests, writing code, conducting reviews.

Audit Trail

Every pipeline action produces structured evidence in

.factory/audit-trail/

. See

references/audit-trail-schema.md

for the directory layout and JSON schemas. The audit trail enables retrospectives, trend analysis, and reproducible escalation context.

Enforcement Note

The pipeline provides structural enforcement through gating: no stage proceeds without evidence from the prior stage, and gate failures mechanically route to rework. The pipeline cannot prevent an agent from producing low-quality work, but it can prevent low-quality work from reaching the main branch. Rework budgets and human escalation provide a safety net when automated gates are insufficient.

Verification

After completing a slice through the pipeline, verify:

Slice was decomposed into leaf tasks with acceptance criteria
Pre-implementation context was gathered and passed to the orchestrator
TDD pair implemented without consensus rounds (no team discussion)
Full-team code review occurred before push (all three stages)
All review findings were addressed before proceeding
Mutation testing achieved 100% kill rate on changed files
CI pipeline passed green
Merge occurred only after all five gates passed
Audit trail entries exist for every stage
Acceptance test exercises the application boundary
Rework cycles (if any) stayed within the 3-cycle budget per gate

Dependencies

This skill requires other skills to function. It orchestrates them; it does not replace them.

tdd: Pair implementation engine. The pipeline dispatches TDD pairs and collects cycle evidence.
code-review: Three-stage review protocol. The pipeline invokes full-team review before every push.
mutation-testing: Quality gate for test effectiveness. The pipeline runs mutation testing scoped to changed files.
task-management: Work decomposition. The pipeline decomposes slices into leaf tasks before implementation.
ci-integration: CI pipeline monitoring. The pipeline pushes and waits for CI results.

Missing a dependency? Install with:

npx skills add jwilger/agent-skills --skill tdd

pipeline

NPX Install

Tags

SKILL.md Content

Pipeline

Purpose

Practices

Slice Queue Management

Per-Slice Pipeline

Quality Gates

Rework Protocol

Progressive Autonomy

Pipeline Operates Directly

Audit Trail

Enforcement Note

Verification

Dependencies