compound-v

Compound V

"You don't tell people you're injecting them with Compound V. You just hand them the spec and watch them go faster." — internal Vought memo, probably

Compound V is a transparent interceptor that sits between Superpowers phases AND, as of v1.0, a lightweight execution orchestrator — the orchestrated pipeline is now the default execution path. You don't invoke it directly — it fires automatically at four transitions:

Stage −1 — Pre-Evaluation (v2.9). Before Trigger 0 even offers recon, a fast, cheap Pre-Evaluation scores the change request on two separate axes (difficulty ⊥ impact) from deterministic tiered evidence and — only when a change is provably trivial and low-impact — OFFERS a proportionate fast-path that collapses the full pipeline into one scope-gated implementer plus one combined SPEC+QUALITY Opus review. Everything else routes to the full pipeline below. It uses no raw LLM magnitude, never auto-routes (it only ever offers), and fails closed on any ambiguity, sensitive-path touch, or shared-token/a11y surface. A sibling post-diff re-classifier can still ESCALATE an accepted fast-path back to the full pipeline before merge (minting a new run-id, never mutating the frozen manifest). See [phase-preeval.md](phase-preeval.md); the offer/accept decision is captured as a thin ADR via /v:adr.

1. Before brainstorming begins → offers a gated pre-brainstorm recon (Trigger 0): a bounded deep-research/WebSearch pass that writes an anti-anchoring recon doc to docs/superpowers/recon/ — evidence to widen the brainstorm's questions, never a conclusion to converge on. See [phase-0-recon.md](phase-0-recon.md).
2. After brainstorming, before writing-plans → injects THREE parallel pre-flights:
3. Phase 1A: Code-Archaeology — the technical reality of the existing code
4. Phase 1B: Domain-Expert Advisor — the product/domain reality (web-searched if needed, knowledge-base persisted)
5. Phase 1C: Library/Doc Validator — library currency via Context7 MCP (stale deps, abandoned libs, outdated API signatures)
6. Inside writing-plans → enforces Disjoint File Partitioning and materializes a manifest.yaml (the machine-readable contract) so tasks can run in parallel
7. At execution → runs the orchestration pipeline: dispatch each manifested job to its backend (Claude subagent on Opus by default, Sonnet only for clearly junior mechanical tasks, or a headless Codex worker for large isolated builds — see phase-3-parallel-opus-dispatch.md), enforce file-scope with a git diff gate after every job, collect canonical job_results, review against the spec's Acceptance Criteria, and update outcome memory. Runs autonomously with guardrails and is crash-resumable via state.json.

The unified pipeline (orchestrator-as-default):

★ PRE-EVAL (v2.9)  two-axis score → OFFER fast-path | FULL_PIPELINE   (fail-closed; never auto-routes)
   │  └─ accepted fast-path ─► materialize 1-job manifest ─► implement ─► scope gate
   │        ─► post-diff re-classify (ESCALATE → full pipeline, new run-id) ─► review ─► merge
   ▼  (full pipeline)
★ RECON (gated)  docs/superpowers/recon/YYYY-MM-DD-<topic>.md   (Trigger 0 — skip: plumbing | KB hit | off)
   ▼
brainstorm ─► spec (carries feature-level Acceptance Criteria)
   ▼ auto-fire
[1A archaeology ∥ 1B domain ∥ 1C library] ─► 3 audits   (🔴 critical finding → HALT)
   ▼ writing-plans + Phase 2 Partition Map
★ MANIFEST  docs/superpowers/execution/<run-id>/manifest.yaml   (partition FAIL → HALT)
   ▼ DISPATCH — batched Task (4–6) ∥ Codex via backend-launcher; per-job worktree|direct
★ COLLECT + SCOPE GATE  git diff --name-only vs write_allowed   (violation → BLOCKED → HALT)
   ▼ REVIEW  spec + quality + final integration (Opus), AC-gated   (unfixable ISSUES → HALT)
   ▼ MEMORY  append task-outcomes.jsonl + routing-lessons.md
   ▼ finishing-a-development-branch
                          state.json updated after every phase ──► /v:status · /v:resume

The orchestration contracts and scripts live alongside this skill: the manifest schema in [execution-manifest.md](execution-manifest.md), the backend contract in [backend-launcher/SKILL.md](../backend-launcher/SKILL.md), and the canonical result shape in [schemas/job_result.schema.json](../../schemas/job_result.schema.json). No daemon, no MCP server, no external vector DB service, no fabricated cost metrics — the anti-ruflo charter. (V-memory's optional DENSE lane is pure-Python embeddings in a repo-external venv, not a service — see [memory.md](memory.md).) Manual control is available via /v:orchestrate, /v:dispatch, /v:collect, /v:status, /v:resume, /v:init, plus /v:remember (recall search) and /v:memory-refresh (index/bootstrap); in default operation the agent flows through orchestrate → dispatch → collect itself.

Epic mode (v1.1) — chain many features into one build. A single run executes one plan (one feature). An epic chains several: an ordered set of features, each run through the full v1.0 pipeline above in dependency order, accumulating onto one branch — "build a whole app." It is the same discipline one level up: a deterministic topological spine (epic-state.json via [scripts/compound-v-epic-state.py](../../scripts/compound-v-epic-state.py)) drives a resumable, no-daemon feature loop, ending in a cross-feature integration review and finishing-a-development-branch. Run it with /v:epic; the model, run-dir layout, and honesty boundary are in [epic-mode.md](epic-mode.md).

Why three pre-flights, in parallel:

• 1A catches "the building is 200m², not 500m²" (existing code reality)
• 1B catches "you're designing OAuth but Notion uses Basic auth + JSON body" (domain reality)
• 1C catches "the spec suggests oauth2orize but it hasn't been updated in 4 years; use @node-oauth/oauth2-server" (library currency)

All three are independent — different failure modes, different lookup paths, no shared state. Dispatch them in one message with three concurrent Task calls to keep wall-clock cost low.

Auto-fire caveat: "Auto-fires after brainstorming" is description-driven (the parent agent reads this skill's description and recognizes the trigger condition). It is NOT enforced by Claude Code hooks. The plugin ships three helper hooks (SessionStart banner, the plan-saved nudge, and hooks/brainstorm-trigger0-nudge.sh — a one-line reminder injected when the Skill tool invokes superpowers:brainstorming) that print reminders to the parent agent, but the actual skill invocation still depends on the parent recognizing the description trigger. Reliability is high on Opus / Sonnet 4.6+; weaker models may miss the trigger. Trigger 0 shares the same description-driven mechanism; its hook backstop is a reminder, not enforcement — the model can still skip it — so Trigger 0 remains the weakest of the four triggers; do not overclaim its reliability. A missed Trigger 0 degrades to plain upstream brainstorming, and nothing breaks.

The skyscraper metaphor (see [assets/skyscraper-metaphor.md](../../assets/skyscraper-metaphor.md)): Without pre-flight you build a 500m² hat on a 200m² tower. With the pre-flight audits, you add three proper floors that fit the building AND the building code.

Announce at start of each phase:

• Phase 0: "💉 Compound V — pre-brainstorm recon (gated)." — only when the gates decide to RUN; a gate-skip gets the one-line log plus its terminal event, no announcement
• Phase 1: "💉 Compound V injected — triple pre-flight (archaeology + domain-expert + library-validator) in parallel."
• Phase 2: "💉 Compound V — enforcing Disjoint Partition Map."
• Phase 3: "💉 Compound V — dispatching N implementers in parallel on Opus."

(Heavy theming is optional flavor; technical content is straight business.)

When This Skill Fires

flowchart LR
    Z[