--- name: consensus-voting description: | Multi-agent voting protocol for high-stakes decisions. Spawns 3+ specialist agents in parallel, each evaluates the question through their domain lens, then their verdicts are aggregated into a consensus recommendation. Eliminates single-perspective bias on architecture, security, performance, or cost decisions where reasonable engineers might disagree. Use when: - Architecture choice with significant blast radius (DB selection, framework swap) - Security-vs-velocity tradeoff (e.g., adopting new auth scheme) - Performance-vs-cost tradeoff (e.g., caching strategy) - Refactor scope decision (do it all vs incremental) - Tech stack pick that team will live with for years - Anything where you catch yourself going "well, on one hand…" --- # Consensus Voting — Decisions by Triangulation When ONE expert opinion isn't enough. This skill orchestrates multiple specialist agents to debate a question in parallel, then synthesizes their output into a single decision with explicit reasoning. ## When to Invoke Trigger consensus-voting when AT LEAST ONE is true: - Decision is hard to reverse (one-way door per Bezos taxonomy) - Decision affects > 1 team or > 1 service - Annualized cost / risk impact > meaningful threshold (project-dependent) - You're tempted to flip a coin - Stakeholder asks "have you considered X angle?" and you weren't sure ## Voter Panels (pick the relevant 3-5 for the question) ``` ARCHITECTURE QUESTION - architect (system design lens) - performance-analyzer (latency / throughput / scale lens) - cost-watchdog ($ lens) - db-doctor (data layer lens — if persistence involved) - security-auditor (threat model lens) SECURITY QUESTION - security-auditor (vulnerability + compliance) - architect (architectural soundness) - code-reviewer (implementation correctness) - cost-watchdog (cost of mitigation) PERFORMANCE QUESTION - performance-analyzer (profile-driven view) - db-doctor (if DB-bound) - architect (caching / partitioning options) - cost-watchdog (cost of perf gains) REFACTOR / CLEANUP QUESTION - refactor-master (debt impact) - code-reviewer (correctness preservation) - test-generator (safety net) - architect (scope discipline) ``` ## Protocol ``` STEP 1 — FRAME the question (5 min) - One sentence: what are we deciding? - Hard constraints (numbers, deadlines, compliance) - Options under consideration (≥ 2; if 1, you're not voting, you're justifying) - Decision deadline STEP 2 — DISPATCH voters in parallel Use the Task tool to spawn each voter agent with the SAME framing prompt. Each voter must produce structured output: VOTER: LENS: PREFERRED OPTION: CONFIDENCE: <0.0-1.0> KEY REASONS (top 3): 1. 2. 3. DEALBREAKERS: RISKS THEY ACCEPT: STEP 3 — AGGREGATE - Tally votes - Identify majority option - Identify CONFLICTS: where voters disagree, document the explicit tradeoff being made - Identify DEALBREAKER OVERLAPS: if 2+ voters share a dealbreaker, surface it loudly STEP 4 — DECIDE Default rule: highest weighted-confidence option wins, where weights are domain-relevant (e.g., security vetoes are stronger on a security question). But: if any voter raises a SAFETY or LEGAL dealbreaker, that becomes binding regardless of vote count. STEP 5 — DOCUMENT Produce a CONSENSUS RECORD: DECISION: