req-lead drafts Requirements; spec-lead authors Specs and Feature briefs; dev-lead persists. /decompose-feature activates required domains (CPO-gated structural precondition) and dispatches active-domain specialists in parallel via CreateTeam for read-only planning, then reconciles and persists Stories + Tasks.

Runs between Spec resolution and Feature generation when the Spec carries user-facing scope. /create-mockups dispatches designer to interview, build deployable mockup code, iterate (re-runnable; CPO approval at every gate), and write the Mockup Reference back to the Spec. /analyze-mockups dispatches spec-lead to audit completeness, map mockup data shapes to backend API declarations, and write the Mockup Wiring Guide. /generate-features refuses to run on user-facing Specs missing either section.

Authors an end-to-end test plan for a Spec or Feature and optionally scaffolds initial test files. Dev-lead dispatches ux-test-engineer as serial-Task specialist to read the Spec, codebase, and framework conventions; produce a structured plan; and scaffold runnable tests. ux-test-engineer is the third closing-phase write-exception alongside designer and tech-writer.

/plan-sprint allocates into the current sprint only (hard single-sprint rule; overflow stays unallocated). /execute-sprint creates the feature branch, dispatches active-domain specialists into per-agent worktrees, reviews each task branch, runs the centralized build-and-test pass, sets completion metadata at resolution, and prepares the PR.

/file-bugs accepts informal CPO input, dispatches an intake specialist read-only for investigation and classification. /fix-bugs is the lighter sibling of /execute-sprint for Bug + Enhancement work items — targeted fixes, no Story decomposition, same metadata round-trip at resolution.

Reads reviewer comment threads and failed CI checks via the source-control connection profile, categorizes by domain, dispatches the relevant specialists in parallel (or serially for file-conflicting fixes), runs the centralized build-and-test pass, pushes updates to the existing feature branch. Thread resolution stays with the human reviewer.

The deliberate CPO ritual for transitioning Resolved work items to Closed — the only authoritative manual gate. The execution skills stop at Resolved by design; this ritual is where the CPO walks Resolved Features, Enhancements, Bugs, and lingering Stories and decides per item: close / reject with rework tag / defer with reason tag / skip.

/dora-reconcile runs daily (cascades) or weekly with --auto-fix (stamps derivable hygiene). 8 reconciliation passes keep the AI-tag + lifecycle-metadata wiring honest. /dora-collect writes a JSON snapshot of work items, pipeline runs, and PRs. /dora-report renders a self-contained HTML report with embedded Chart.js. Wall-clock as primary AI Efficiency Ratio.

/memory-show inspects per-agent memory; /memory-refine curates it under CPO direction. /revise-token-budget is the canonical surface for tuning STRAP's token budgets after /strap-in's initial setup — per-workflow per-agent and session-aggregate budgets, plus per-agent overrides. Persists with an append-only audit trail.

The CPO "do now" lever. Free-form description through classification, work-item chain creation, specialist routing, implementation, centralized test pass, and draft PR — in one invocation. Five chain shapes; flags --under, --into, --mockup, --investigation, --stacked, --draft. Hard CPO approval gate after classification. Never refuses for size.

/team-cleanup recovers from wedged team state. /context-prep captures cross-session continuation runbooks; /context-fetch loads them as session-startup context. Multi-session and multi-developer workstreams travel through these.

The Spec is well-shaped — Constituent Parts are clear, acceptance criteria resolve to concrete behavior, mockups (if user-facing) are locked in, the Wiring Guide is written. The work is multi-Feature in scope but each Feature is independently executable. You trust the Spec to be the contract and you want the pipeline to run hands-off. You'll be reading the conversation as the dev-lead emits checkpoint summaries, but you don't intend to intervene unless something genuinely needs you.

The Spec is rough or under-defined — use /refine-spec first; do not let Full Auto paper over Spec defects. The ask is free-form ("change the timeout from 5s to 10s") — use /quick; classification is what you need, not a multi-Feature run. The work is exactly one Feature already decomposed and sprint-allocated — use /execute-sprint; Full Auto is overkill. New specialist domains are required — activate them deliberately via /decompose-feature first, not mid-Full-Auto.

Full Auto inlines four production-workflow skills. It does not invoke them as separate skills (that would reintroduce per-skill approval gates). It walks the same phases with the same primitives — spec-lead authoring, specialist parallel planning via CreateTeam, worktree mechanics, centralized test execution — and stamps the full-auto tag at every persist.

Phase 4 (decomposition) is serial across Features but parallel within each — same as today's /decompose-feature baseline. Phase 6 (execution) is parallel across Features AND parallel within each — one team, one worktree, one feature branch, one draft PR per Feature, all running concurrently. The throughput uplift lives in Phase 6.

Feature brief approval (per /generate-features), per-Feature decomposition approval (per /decompose-feature), sprint capacity review (per /plan-sprint) — all collapse to dev-lead authority. The dev-lead acts. You watch the checkpoints. Per-task review remains because it is a quality gate (did the specialist implement what the Task says?), not a CPO-approval gate — the dev-lead runs it inline.

The most important non-obvious behavior in Full Auto. A "well-scoped Resolved Spec" is the contract, but decomposition or execution may surface gaps the Spec author did not anticipate. When a specialist flags ambiguity, incompleteness, or contradiction in its finishing report, the dev-lead halts the affected scope and asks you to choose: edit the Spec inline (additive amendment with audit comment; Spec stays Resolved), pause Full Auto and return to manual /refine-spec (the partial chain is preserved tagged full-auto-partial), or proceed with the dev-lead's best-judgment assumption (logged verbatim in the affected Feature description).

Three-strikes rule: if three Spec-Ambiguity Halts fire in one run, the dev-lead escalates and recommends cancelling + running /refine-spec. The Spec is likely not Full-Auto-ready; clarifying it to death mid-run is the wrong outcome.

The dev-lead emits structured checkpoint summaries at every phase boundary — Run Contract drafted, Features generated, each Feature decomposed (one per Feature in Phase 4), sprint allocated, each Feature executed (one per Feature in Phase 6 as they complete in arrival order, not creation order), PRs opened. Each checkpoint lists items created, branches, tokens consumed, time elapsed, what comes next.

Checkpoints are conversation output only. They do not gate. They do not require acknowledgment. You read them in real-time if you want; you ignore them if the run is going clean. Per-Feature granularity is the default — per-Task checkpoints would drown the conversation on a 50-Task run.

You Resolved a Spec for a self-contained UI enhancement: refactor the audit-log filter chrome and add tenant-id scoping. Two Constituent Parts (client-ui for the chrome, api for the tenant-scoped query). Full Auto generates two Features, decomposes them in sequence (~4 minutes each), allocates 8 Tasks into the current sprint, then runs Phase 6 with two teams in parallel. ~25 minutes wall-clock end-to-end. Two draft PRs land in the source-control profile, each with the Run Manifest in its description and acceptance criteria mapped to specific commits + tests.

You Resolved a Spec for a billing-pipeline overhaul: new invoice schema, migration, API surface, frontend display, observability. Five Constituent Parts; backend-engineer, database-engineer, frontend-engineer, devops-lead, and security-reviewer all active. Full Auto generates five Features, decomposes them serially in Phase 4 (~25 minutes), then runs Phase 6 with five teams in parallel. The 60% session-aggregate budget checkpoint fires around the third Feature's execution — the dev-lead surfaces, runs /context-prep, you /clear and resume with /context-fetch. Five draft PRs land. Total wall-clock ~90 minutes across two sessions.

You Resolved a Spec on a polyrepo umbrella with three sub-repos (shared-types, api-backend, web-frontend). One Feature is cross-sub-repo (a new type defined in shared-types, consumed by both downstream sub-repos); three Features are single-sub-repo. Full Auto's Phase 1 builds the cluster manifest with the F6 dependency graph (shared-types first, then the two downstream sub-repos in parallel). Phase 4 decomposes each Feature against the right sub-repo's specialists. Phase 6 runs four teams in parallel; the cross-sub-repo Feature opens three coordinated PRs with cluster-manifest cross-references; the single-sub-repo Features open one each. Total: seven draft PRs. The dev-lead enforces merge-order at PR-merge time per the F6 graph — you merge shared-types first, then the others.