vc-agent-strategy-compare

name	vc-agent-strategy-compare
description	Evaluate 4 execution strategies (sequential, parallel-subagents, workflow, agent-team) for a phase or fan-out task. Outputs 7-signal score table, agent count math, cost guards, and strategy recommendation.
argument-hint	[phase context description or fan-out task description]
trigger_keywords	execution strategy, parallel agents, strategy comparison, agent count, fan-out recommendation
layer	contract
metadata	{"author":"vibecode-pro-max-kit","version":"1.2.0"}

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:

find . -path '*/active/*' -name '*.md' | head -5
grep -A 30 "Touchpoints" [plan path] | grep -E "^\s*-"

Signal 5 scan — assess test infra maturity:

# 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:

grep -A 5 "Phase Ordering\|phase.*depend" [umbrella plan path] | head -20

Signal 7 scan — check prior parallel execution outcomes:

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 better served by a deterministic workflow or a single sequential agent.

Orchestrator Pre-Spawn Rule

Before any multi-file edit begins, the orchestrator surfaces a strategy recommendation from this skill and waits for user confirmation before spawning vc-execute-agent. This is not optional for non-trivial plans (blast radius ≥ 3 files or any high-risk class present).

---

7-Signal Scoring Table

Count how many signals are present. Each signal counts as 1. Use the score to select a strategy threshold.

Seven Signals

ID	Signal	Present?
S1	Multi-package scope — files touch 3+ workspace packages	[ ]
S2	Schema/API/auth surface touched — plan or research identifies changes to DB schema, public API contracts, or auth/identity flows	[ ]
S3	3+ viable directions — research or innovate surfaced 3+ meaningfully different approaches or investigation areas	[ ]
S4	Phase program classification — the work was classified as a phase program (3+ phases)	[ ]
S5	User requests depth — the user explicitly asks for depth ("go deep", "explore all options", "compare thoroughly")	[ ]
S6	High-risk class in plan — plan's Blast Radius or Public Contracts section names auth/identity, billing/credits, schema/migration, public API, container/proxy/gateway, or secrets/trust-boundary	[ ]
S7	5+ files in blast radius — plan's Blast Radius section lists 5 or more distinct files	[ ]

Total score: [0–7]

Threshold Table

Score	Label	Recommended strategy
0–1	LOW	Sequential — one vc-agent at a time. Do not mention fan-out.
2–3	MEDIUM	Parallel subagents — spawn one vc-agent per direction; orchestrator merges outputs.
4+	HIGH	Workflow or Agent team — workflow for deterministic step-by-step pipelines (automated, predictable sequence); agent team (named teammates + shared task list: TeamCreate + TaskCreate/TaskUpdate + Agent with team_name/name + SendMessage, tracked by TaskList — NOT parallel subagents) when specialists must share what they find while still working (real-time coordination). Parallel subagents are fire-and-forget and cannot talk to each other; agent-team members can send messages mid-run.

Auto-skip rule: single-file or trivial changes always use sequential regardless of score. Do not mention other strategies for trivial changes.

Fit note: the right strategy is the one that fits the work — not the highest tier. Sequential is correct for trivial changes. Workflow is correct for deterministic pipelines and full RIPER-5 automation. Agent team is correct only when 2+ specialists need to coordinate mid-execution.

---

Strategy Options Table

ALL 4 strategies must always be evaluated and presented. Never omit one.

Strategy	How it works in the vc system	Agent count math	Cost guard	Best fit
Sequential	One vc-agent at a time in strict RIPER-5 order: orchestrator spawns vc-research-agent → waits → spawns vc-innovate-agent → waits → etc. Each agent gets the previous agent's output. Single context window per phase.	1 agent per phase (6 total for full RIPER-5)	None	Trivial/single-file changes; iterative /goal phase-program execution where steps are known but parallelism adds no benefit
Parallel subagents	Orchestrator spawns multiple vc-agents simultaneously via the Agent tool, each investigating one independent direction. Each agent loads its own context, invokes its own skills (vc-scout, vc-docs-seeker, vc-sequential-thinking), and returns a result. Orchestrator merges.	4 (Layer 1 dimensions) + N (one per direction) + 3 (optional validation fan-out) = 7–15 typical	>30: show breakdown before proceeding; >100: ask explicit confirmation	5+ independent directions (e.g. 5 separate codebase areas, 5 phase plans to validate simultaneously) with no mid-task communication needed between agents
Workflow	Full RIPER-5 pipeline as a deterministic Workflow script. Each phase is a phase() + agent() call. Supports pipeline() for per-item fan-out, parallel() barriers when all-results are needed before proceeding, and loop-until-dry patterns. Can run the full RESEARCH→VALIDATE→EXECUTE→TEST sequence automatically with built-in gates.	P (phase steps) × A (agents per step) × I (iterations) = P × A × I; up to 1000 agents, 16 concurrent	>30: show breakdown; >100: ask confirmation	Full RIPER-5 automation, TDD fan-out loops, metric iteration, large sweeps (lint/test/migrate); unknown item count upfront; quality > cost
Agent team	Claude Code's built-in team feature: TeamCreate provisions named specialist teammates. Each teammate gets a TaskCreate assignment scoped to their specialty (e.g. one runs vc-research-agent, another runs vc-validate-agent, another runs vc-execute-agent). SendMessage enables mid-execution coordination. TaskList tracks all in-flight work.	M (members) × R (rounds) = M × R; keep M ≤ 6, R ≤ 3 unless scope demands it; typically 6–18 total	>6 members: show each member's role and ask explicit confirmation	2+ workstreams that must share findings mid-execution (e.g. a security reviewer feeds blockers to the implementer before the implementer finishes); named specialist roles known upfront; adversarial challenge tasks

Cost Guard Rules

• >30 agents total: show the full breakdown (strategy × count math) so the user can judge before proceeding.
• >100 agents total: show breakdown AND ask for explicit confirmation before spawning.
• >6 team members (vc-team only): show each member's role and ask for explicit confirmation.

Note: V5 "Accept" in the VALIDATE sequence satisfies both the cost-guard confirmation and the plan-approval confirmation in one gate. The cost guard is surfaced at V4 (Validate Menu) so the user sees it before deciding at V5. No separate yes/no prompt is required for the cost guard alone.

---

Recommendation Output

After computing the score and filling the table, output a single recommendation block. Use plain English labels alongside technical ones so readers unfamiliar with the system can follow along.

Score: [N]/7 — signals: [list present signal IDs]
Recommended strategy: [Sequential (one agent at a time) | Parallel subagents (independent work, no coordination) | Workflow (automated pipeline) | Agent team (specialists coordinating live)]
Agent count: [explicit math per row above]
Model: [sonnet for all spawned agents; opus ONLY for the code-execution leg — see §Model Selection Policy]
Cost guard: [triggered / not triggered]
Rationale: [one sentence on dominant signal and why this strategy fits]

Strategy-by-Fit Rules

Use these rules to select and justify the recommendation — not the threshold table alone:

• Sequential: right for trivial or single-file changes; right for /goal phase-program execution where each phase clearly depends on the previous. Hard limit: single context window per phase. Each vc-agent (vc-research-agent, vc-plan-agent, etc.) runs one at a time; orchestrator hands off between them.
• Parallel subagents: right when there are 5+ independent items in different file domains with no mid-task communication needed. Each spawned agent uses the same vc-system agents and skills but works on a scoped slice. Orchestrator must stay clean (parent context must not accumulate all output). Time savings: 50–70%. Cost: approximately N× linear token multiplier.
• Workflow: right for deterministic pipelines (full RIPER-5 automation, TDD loop, metric iteration, quality gate sequences), tasks too big for a single context window, or when the item count is unknown upfront. The workflow script calls vc-system agents as agent() calls in pipeline() or parallel() steps. Quality > cost priority. Up to 1000 agents, 16 concurrent. Total tokens roughly the same as sequential — most cost-effective for large volume.
• Agent team: right when 2+ specialist workstreams must share findings mid-execution (not just consume the same input), when named roles are known upfront (e.g. security reviewer + implementer + tester coordinating live), or when an adversarial challenge pattern is required. Uses Claude Code TeamCreate + TaskCreate + SendMessage. Each teammate runs its own vc-agent and skills. NOT for simple fan-out where agents work independently — use parallel subagents for that. Mechanism: a team shares a TaskList and uses SendMessage to coordinate mid-run; parallel subagents have NO inter-agent channel and CANNOT coordinate — so any task that needs mid-execution coordination (e.g. blast-radius non-overlap across phase plans) MUST be agent-team, never parallel subagents.

---

Phase Program Rule

When a plan describes a program with 3+ phases (phase program classification, signal S4 present):

• Sequential is NEVER valid for plan creation fan-out OR validate fan-out across the phases.
• 3+ phase-plan CREATION default: AGENT TEAM. Phase plans share files (CLAUDE.md, agent .md files) and MUST coordinate blast-radius non-overlap + dependency declarations — only an agent team can do this (TeamCreate + shared TaskList + SendMessage). Fire-and-forget subagents cannot communicate, so they cannot keep blast radii disjoint and are the WRONG strategy for plan creation. (Outer-PVL VALIDATE fan-out across already-written phase plans, where each validator reads one finished plan with no cross-talk, MAY use independent read-only subagents — see the reconciliation note below.)
• Reconciliation (CREATION vs read-only VALIDATE fan-out): validating N already-written plans needs no inter-agent talk, so bare parallel subagents are valid there; plan CREATION needs cross-talk, so it is agent-team. Note orchestration.md even describes Outer PVL as an agent-team — prefer agent-team for both and reserve bare parallel subagents only for truly independent read-only fan-out.
• If phases have complex interdependencies requiring mid-draft communication (e.g., phase 2 plan depends on design decisions surfaced during phase 1 planning): use agent team instead. Assign one teammate per phase, use SendMessage for cross-phase coordination.
• If the total phase count is unknown upfront (e.g., the program scope is discovered incrementally): use workflow so the pipeline can expand without re-spawning the orchestrator. Each agent() call in the workflow runs the appropriate vc-agent for that phase.

---

Strategy Reference

1 — Sequential (one vc-agent at a time)

The orchestrator runs one vc-agent, waits for it to complete, then routes to the next.

orchestrator → vc-research-agent → (result) → vc-innovate-agent → (result) → vc-plan-agent → ...

• Each agent invokes its own skills (vc-scout, vc-docs-seeker, vc-sequential-thinking, etc.) independently.
• Simplest option. No fan-out overhead. Single context window per phase.
• Hard limit: cannot parallelize. If a phase has 5 independent sections, all 5 run back-to-back.
• Best for: standard single-feature RIPER-5 runs, /goal phase-program execution, trivial fixes delegated directly to vc-execute-agent.

2 — Parallel Subagents (one agent per direction)

The orchestrator spawns multiple vc-agents simultaneously via the Agent tool. Each agent goes in one direction independently, invokes its own skills, and returns a result. The orchestrator merges all results before proceeding.

orchestrator ──► vc-research-agent (direction A)
             ──► vc-research-agent (direction B)   (all run simultaneously)
             ──► vc-research-agent (direction C)
             └── merge all results → route to vc-innovate-agent

• Parent context must stay clean — pass only scoped input to each agent; collect structured output.
• Time savings: 50–70% vs sequential for the fan-out step. Cost: approximately N× token multiplier.
• NOT appropriate when one agent's findings should influence another agent mid-run — use agent team for that.
• Best for: parallel RESEARCH across 5+ distinct codebase areas; parallel VALIDATE across 5+ phase plans; parallel dimension checks in PLAN.

3 — Dynamic Workflow (full RIPER-5 pipeline)

A deterministic Workflow script orchestrates the vc-system agents as programmatic steps. Each agent() call in the script corresponds to a vc-agent running its phase. pipeline() handles per-item fan-out without a barrier. parallel() handles all-results-needed barriers.

workflow script
  phase('Research')   → agent('run vc-research-agent for feature X', {agentType: 'vc-research-agent'})
  phase('Plan')       → pipeline(items, item => agent('write phase plan for ' + item))
  phase('Validate')   → parallel(plans.map(p => () => agent('validate plan ' + p)))
  phase('Execute')    → agent('run vc-execute-agent for plan path', {agentType: 'vc-execute-agent'})

• Supports loop-until-dry, budget-aware iteration, and unknown item counts.
• Each agent() call runs the appropriate vc-system agent and its skills.
• Up to 1000 agents / 16 concurrent. Total tokens roughly equal to sequential — work is distributed.
• Best for: full RIPER-5 automation across many items, TDD fan-out loops, lint/test sweeps, phase-program pipelines where count is unknown upfront.

4 — Agent Team (multiple specialist teammates)

Claude Code's built-in TeamCreate feature provisions named teammates. Each teammate is assigned a specialized role via TaskCreate. Teammates communicate via SendMessage. TaskList tracks in-flight work.

TeamCreate("security-review") → teammate A: runs vc-validate-agent (security dimension)
TeamCreate("implementation")  → teammate B: runs vc-execute-agent (implements)
TeamCreate("test-coverage")   → teammate C: runs vc-tester (writes/runs tests)
SendMessage: A → B (security findings mid-implementation, not after)

• Each teammate runs its own vc-agent (vc-research-agent, vc-plan-agent, vc-execute-agent, vc-tester, vc-debugger, etc.) and invokes the relevant skills for their specialty.
• Named roles known upfront. Mid-execution coordination via SendMessage.
• Highest cost — all teammates are active simultaneously.
• NOT appropriate for simple fan-out where agents work independently — use parallel subagents for that.
• Best for: security reviewer + implementer + tester coordinating live; adversarial plan challenge (one agent proposes, another attacks); multi-specialist investigation where findings from specialist A must reach specialist B before B finalizes.

---

Source References

• process/development-protocols/orchestration.md — Two-Tier Fan-Out Escalation, Parallel Fan-Out Checkpoints
• process/development-protocols/orchestration.md §VALIDATE Gate — skip conditions, gate verdicts, BLOCKED escalation path