Multi-Agent Voting Skill

Execute multi-agent voting for critical decisions using MAKER-style first-to-ahead-by-k error correction.

When to Use

Use this skill when:

• Making critical decisions that benefit from consensus (code review, breaking changes, spec validation)
• Voting is enabled in .spec-flow/config/voting.yaml for the operation type
• High-stakes decisions where single-agent errors are unacceptable

Theoretical Foundation

Based on MAKER paper (arXiv:2511.09030):

• First-to-ahead-by-k voting: Candidate must be k votes ahead to win
• Formula: p_correct = p^k / (p^k + (1-p)^k)
• Scaling: Cost grows log-linearly O(s ln s) with decomposition

With k=2 and individual agent accuracy of 70%:

• Single agent: 70% accuracy
• 3 agents with k=2: ~84% accuracy
• 5 agents with k=3: ~91% accuracy

Prerequisites

Workflow

Implementation Patterns

Spawning Parallel Agents

Use Task tool with multiple parallel invocations:

<parallel_agents>
<agent id="1" temperature="0.5">
[Core prompt for operation]
</agent>
<agent id="2" temperature="0.7">
[Core prompt for operation]
</agent>
<agent id="3" temperature="0.9">
[Core prompt for operation]
</agent>
</parallel_agents>

Structured Output Parsing

Require agents to output in parseable format:

# Expected output structure
verdict: PASS  # or FAIL
confidence: 0.85
issues:
  - severity: HIGH
    description: "..."
  - severity: MEDIUM
    description: "..."

First-to-ahead-by-k Algorithm

function first_to_k_vote(votes, k):
    counts = count_each_candidate(votes)
    sorted_candidates = sort_by_count_desc(counts)

    if len(sorted_candidates) == 1:
        return sorted_candidates[0]

    leader = sorted_candidates[0]
    runner_up = sorted_candidates[1]

    if counts[leader] - counts[runner_up] >= k:
        return leader

    return NO_CONSENSUS

Red Flag Integration

Before counting votes:

1. Check each response against red-flags.yaml
2. Discard responses with red flags
3. Request replacement samples if below min_votes_required
4. Only count clean responses

Cost Optimization

Minimize c/p (cost per success), not just cost:

<cost_guidance> Use haiku for simple validation tasks (spec completeness) Use sonnet for complex analysis (code review, security) Reserve opus for architecture decisions (voting optional) Start with k=2; increase only if accuracy below threshold Track cost vs accuracy tradeoff in learnings </cost_guidance>

Example: Code Review Voting

Operation: code_review
Strategy: first_to_ahead_by_k
k: 2
Agents: 3
Model: sonnet

Agent 1 (temp 0.5): PASS, 2 issues
Agent 2 (temp 0.7): PASS, 3 issues
Agent 3 (temp 0.9): PASS, 2 issues

Vote count: PASS=3, FAIL=0
PASS leads by 3 (>= k=2) → Consensus: PASS

Aggregated issues (union): 4 unique issues
Final: PASS with 4 issues to address

Example: Breaking Change Detection

Operation: breaking_change_detection
Strategy: first_to_ahead_by_k
k: 2
Agents: 3
Tie-breaker: BREAKING (conservative)

Agent 1: NON_BREAKING
Agent 2: BREAKING
Agent 3: NON_BREAKING

Vote count: NON_BREAKING=2, BREAKING=1
NON_BREAKING leads by 1 (< k=2) → No consensus yet

Request 2 more samples:
Agent 4: NON_BREAKING
Agent 5: NON_BREAKING

New count: NON_BREAKING=4, BREAKING=1
NON_BREAKING leads by 3 (>= k=2) → Consensus: NON_BREAKING

Escalation

When voting cannot reach consensus:

References

• .spec-flow/config/voting.yaml — Voting configuration
• .spec-flow/config/red-flags.yaml — Red flag definitions
• docs/maker-integration.md — MAKER concepts documentation