vc-agent-strategy-compare

# vc-agent-strategy-compare

> **Output style:** Follow `process/development-protocols/communication-standards.md` — answer-first, plain language, no unexplained jargon, TL;DR on long responses.

Evaluate 4 execution strategies for any RIPER-5 phase or fan-out task. Computes the 7-signal score, shows explicit agent count math, applies cost guards, and outputs a ranked strategy recommendation.

All strategies use the existing vc-system agents and skills. The question is only how they are orchestrated.

---

## Model Selection Policy

Every spawned agent — across ALL four strategies (sequential, parallel subagents, dynamic workflow, agent team) — defaults to **sonnet**. Spawn opus ONLY when the agent is carrying out real source-code or build execution (writing/editing code, running builds, applying migrations). Planning, research, analysis, validation, review, and synthesis all run on sonnet.

Concrete rules:

- **Default = sonnet** for any teammate, parallel subagent, or `agent()` call in a workflow. State the model explicitly when spawning.
- **opus ONLY for execution work**: the agent that actually implements code (the vc-execute-agent leg, or a workflow `agent()` step whose job is to modify source / run a build). The RIPER-5 phase that runs on opus is EXECUTE; all other phases (RESEARCH, SPEC, INNOVATE, PLAN, VALIDATE, UPDATE PROCESS) run on sonnet.
- **Agent-team members**: assign sonnet to reviewers, researchers, validators, and planners; assign opus only to the teammate doing real code execution.
- **Dynamic workflows**: pass `model: 'sonnet'` on `agent()` calls by default; pass `model: 'opus'` only on the execution stage that writes code or runs builds.
- **Parallel subagents**: fan-out investigation/review subagents are sonnet; only an implementing subagent is opus.

Rationale: opus is reserved for the one place judgment-under-execution materially changes code quality. Everything upstream is sonnet-cheap without quality loss, and this keeps fan-outs (which multiply agent count) on the cost-efficient tier. This mirrors the live agent frontmatter: `vc-execute-agent`, `vc-fast-mode-agent`, and `vc-quick-fix-agent` are opus; every other vc-agent is sonnet.

---

## Mode Selection

This skill runs in one of two modes. Choose based on context availability and decision stakes.

### Simple Mode (default)

Score the 7 signals from information already present in the conversation context. No additional file scanning.

Use Simple Mode when:
- File count and blast radius are already clear from the current plan or research summary
- Test infrastructure status is already mentioned or irrelevant
- The strategy decision is not gating a phase program kickoff
- No signal is ambiguous given current context

Output format: `Signal 3: +1 (estimated 5-10 files)`

### Deep Mode

Run targeted codebase scans BEFORE scoring signals, then score each signal with concrete evidence.

**Trigger conditions — any one is sufficient:**
- Signal 3 (file count / directions) cannot be accurately determined from context alone
- Signal 5 (test infra maturity) is unknown — no test files have been mentioned yet
- The strategy recommendation will gate a phase program kickoff (high-stakes decision)
- Caller explicitly requests deep mode (e.g. "run deep mode", "scan first")

**Scans to run before scoring:**

Signal 3 scan — count actual touchpoint files:
```bash
find . -path '*/active/*' -name '*.md' | head -5
grep -A 30 "Touchpoints" [plan path] | grep -E "^\s*-"
```

Signal 5 scan — assess test infra maturity:
```bash
# Check if local test script exists
grep -l "test:local" packages/*/package.json apps/*/package.json 2>/dev/null | head -5
# Count test files in blast radius directories
find [blast-radius-dirs] -name '*.test.ts' -o -name '*.spec.ts' 2>/dev/null | wc -l
# Check validate-contract for tier assignments
grep -A 5 "tier:" [plan path] | head -20
```

Signal 6 scan — find independent phases for parallelization:
```bash
grep -A 5 "Phase Ordering\|phase.*depend" [umbrella plan path] | head -20
```

Signal 7 scan — check prior parallel execution outcomes:
```bash
find process/features/[feature]/active/ process/features/[feature]/completed/ -name '*_REPORT_*' 2>/dev/null | grep -i "parallel\|execute" | head -5
```

After scanning, score each affected signal with concrete evidence:
`Signal 3: +1 (14 files confirmed via Touchpoints scan: packages/api/src/router/billing.ts, apps/web/src/components/billing/*, ...)`

---

## When To Invoke

Invoke this skill at these five RIPER-5 checkpoints:

1. **RESEARCH** — when 2+ distinct investigation directions are identified before fanning out (Checkpoint 1: Research Fan-Out)
2. **INNOVATE** — after 2-3 approaches are surfaced and before the Decision Summary is locked (Checkpoint 2: Innovate Fan-Out)
3. **PLAN** — when 3+ phase plans will be created (phase program detected; Checkpoint 4: Phase-Program Validation Fan-Out)
4. **VALIDATE** — at V4 (Validate Menu) — always runs as part of the mandatory VALIDATE sequence
5. **UPDATE PROCESS** — when post-execute review involves multiple dimensions simultaneously (Checkpoint 5: Post-Execute Review Fan-Out)

### Phase-END Invocation Rule

Invoke at the END of each RIPER-5 phase to recommend the execution strategy for the NEXT phase. The skill receives the current phase's output as context and produces a strategy recommendation that the orchestrator carries into the next phase handoff.

### Fan-Out-Level Invocation Rule

When any agent is about to spawn multiple parallel subagents for work WITHIN the current phase, invoke `vc-agent-strategy-compare` FIRST to determine the execution method.

- **Input context**: describe the specific fan-out task (not the whole phase). Example: "run feasibility checks on 5 phase plans" or "review 3 independent API surface changes."
- **Output**: Workflow / Parallel-subagents / Agent team / Sequential recommendation for THIS fan-out only.
- This prevents defaulting to parallel subagents for tasks that are bet