vc-predict

vc-predict — Multi-Persona Pre-Analysis

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

Five expert personas independently analyze a proposed change, then debate conflicts to produce a consensus verdict before a single line of code is written.

When to Use

• Before implementing a major or high-risk feature
• Before a significant refactor or architecture change
• Evaluating competing technical approaches
• Stress-testing assumptions in a proposed design

When NOT to Use

• Trivial or low-risk changes (use debugger for bugs, generate-plan / plan-agent for already-decided tasks)
• Already-approved work with no open design questions
• Pure dependency upgrades with no API changes

---

Mode Selection

vc-predict runs in Simple or Deep mode. Choose based on the conditions below.

| | Simple | Deep |

|---|---|---|

| Context source | Approach description already in context | Approach description + historical research subagent |

| Subagent spawned | No | Yes — reads git log, prior reports, test failure history |

| Persona debate quality | Reasons from first principles | "We tried this 3 months ago and hit X" |

| When to use | Contained feature, clear scope, no prior attempts | See trigger conditions below |

Deep Mode — Trigger Conditions (any one is sufficient)

• The approach involves a pattern previously attempted in this codebase (git history may show prior attempts)
• The approach touches a surface with known failure history: auth, billing, container lifecycle, streaming, or WebSocket reconnect
• Caller explicitly requests deep mode (--deep flag or "use deep predict")
• The plan is COMPLEX shape and this is the pre-checklist predict call

Simple Mode — Trigger Conditions (default)

• Approach is a contained feature with clear scope
• No prior attempts at this surface area are likely
• Plan is SIMPLE shape and the design is not controversial

---

Deep Mode — Research Subagent Protocol

Before the 5-persona debate, spawn a research subagent that performs the following steps in order:

1. Git history scan — run git log --oneline --all -- [relevant files] for each file or directory the approach touches. Flag any commits within the last 6 months that suggest a prior attempt, revert, or known fix.
2. Prior phase reports — search task folders under process/features/{feature}/active/ and process/features/{feature}/completed/ for _REPORT_ files mentioning this surface (pattern: active/{slug}_{date}/{slug}_REPORT_{date}.md). Read any that contain keywords from the approach (e.g. "streaming", "SSE", "auth", "billing", "container lifecycle"). Legacy sibling reports/ dir may also exist — scan it too if present.
3. Test failure history — grep test output files and CI logs for FAIL or Error patterns on relevant module names. Note recurring failures.
4. Return a Historical Context block containing:

• What was tried before (commit refs, dates, brief description)
• What failed and why
• Current state of the surface (is it stable, under active churn, recently refactored?)
• Known landmines (specific lines, patterns, or edge cases that broke before)

The 5 personas then receive this Historical Context block before their independent analysis phase. Each persona incorporates it when relevant.

Output Quality Difference

Simple predict (no research):

> "Senior dev: this streaming approach could cause a memory leak in the SSE proxy."

Deep predict (with historical research):

> "Senior dev: we tried this exact streaming approach in commit a3f921 (2026-03-15) — it caused a memory leak in the SSE proxy because the Bun response body was never released on client disconnect. The current proposal has the same pattern in packages/api/src/routes/gateway-proxy.ts line 84. The fix at the time was adding an AbortController listener; verify that is still present or re-apply."

---

The 5 Personas

| Persona | Focus | Core Questions |

|---------|-------|----------------|

| Architect | System design, scalability, coupling | Does this fit the architecture? Will it scale? What new coupling does it introduce? |

| Security | Attack surface, data protection, auth | What can be abused? Where is data exposed? Are auth boundaries respected? |

| Performance | Latency, memory, queries, bundle size | What is the latency impact? N+1 queries? Memory leaks? Bundle bloat? |

| UX | User experience, accessibility, error states | Is this intuitive? What does the error state look like? Accessible on mobile? |

| Devil's Advocate | Hidden assumptions, simpler alternatives | Why not do nothing? What is the simplest alternative? Which assumption could be wrong? |

---

Debate Protocol

1. Read the proposed change/feature description from the argument
2. Read relevant code if file paths are provided (grep for affected areas)
3. Each persona analyzes independently — do not let personas influence each other during this phase
4. Identify agreements — points where all (or 4+) personas align
5. Identify conflicts — points where personas meaningfully disagree
6. Weigh tradeoffs — for each conflict, evaluate which concern has higher impact
7. Produce verdict — GO / CAUTION / STOP with actionable recommendations

---

Output Format

## Prediction Report: [proposal title]

## Verdict: GO | CAUTION | STOP

### Agreements (all personas align)
- [Point 1 — what they all agree on]
- [Point 2]

### Conflicts & Resolutions

| Topic | Architect | Security | Performance | UX | Devil's Advocate | Resolution |
|-------|-----------|----------|-------------|-----|-----------------|------------|
| [Issue] | [View] | [View] | [View] | [View] | [View] | [Recommendation] |

### Risk Summary

| Risk | Severity | Mitigation |
|------|----------|------------|
| [Risk description] | Critical/High/Medium/Low | [Concrete action] |

### Recommendations
1. [Action item — rationale]
2. [Action item — rationale]
3. [Action item — rationale]

---

Verdict Levels

| Verdict | Meaning |

|---------|---------|

| GO | All personas aligned, no critical risks, proceed with confidence |

| CAUTION | Concerns exist but are manageable — mitigations identified, proceed carefully |

| STOP | Critical unresolved issue found — needs redesign or more information before proceeding |

STOP Triggers (any one is sufficient)

• Security persona identifies auth bypass or data exposure with no viable mitigation
• Architect identifies fundamental design incompatibility requiring significant rework
• Performance persona identifies unacceptable latency or query explosion with no workaround
• Devil's Advocate exposes a false assumption that invalidates the entire approach

---

Integration with Other Skills

| Workflow Step | Skill | How |

|---------------|-------|-----|

| Deepen risk scenarios | vc-scenario | Feed Risk Summary rows as feature description |

| Create implementation plan | generate-plan / plan-agent | Attach Recommendations as constraints to the canonical planning path |

| High-risk feature implementation | execute-agent | Reference CAUTION/STOP items as acceptance gates |

---

Example Invocations

Simple Mode (default)

/vc-predict "Add WebSocket support for real-time notifications"
/vc-predict "Migrate authentication from JWT to session cookies"
/vc-predict "Add multi-tenancy to the database layer"
/vc-predict "Replace REST API with GraphQL" --files src/api/**/*.ts

Deep Mode

/vc-predict "Rework SSE streaming for chat responses" --deep
/vc-predict "Change container lifecycle on instance stop" --deep --files packages/api/src/infra/**/*.ts
/vc-predict "Refactor billing credit deduction" --deep

Deep mode is also auto-triggered (no flag needed) when the plan is COMPLEX shape or the approach touches auth, billing, container lifecycle, or streaming surfaces.