consensus-voting

Execute weighted multi-agent voting for critical decisions where domain expertise matters. Unlike debate (collaborative synthesis) or n-version (parallel generation), this skill focuses on structured voting with expertise weighting for security, authentication, and data-handling changes.

From ~/.amplihack/.claude/context/DISCOVERIES.md (Pattern Applicability Analysis):

> Voting vs Expert Judgment Selection Criteria

>

> When Voting Works:

>

> - Adversarial environment (can't trust individual nodes)

> - Binary or simple discrete choices

> - No objective quality metric available

> - Consensus more valuable than correctness

>

> When Expert Judgment Works:

>

> - Cooperative environment (honest actors)

> - Complex quality dimensions

> - Objective evaluation criteria exist

> - Correctness more valuable than consensus

This skill uses BOTH strategically: Expert judgment to evaluate, weighted voting to decide.

AUTO-TRIGGERS (high-risk domains):

• Security implementations (authentication, authorization)
• Encryption and cryptographic code
• Sensitive data handling (PII, credentials)
• Permission and access control changes
• Critical algorithm implementations

EXPLICIT TRIGGERS:

• Major design decisions with competing approaches
• When stakeholder buy-in matters
• Binary or discrete choices needing validation
• Risk-mitigating decisions for production code

AVOID FOR:

• Complex trade-off analysis (use debate-workflow instead)
• Code generation (use n-version-workflow instead)
• Simple implementation choices
• Subjective quality assessments

Voting Configuration

Voting Mode:

• simple-majority - 50%+ votes to pass
• supermajority - 66%+ votes to pass (DEFAULT for security)
• unanimous - 100% agreement required

Agent Selection:

• auto - Select agents based on detected domain (DEFAULT)
• manual - Specify agents explicitly
• comprehensive - All relevant agents vote

Weight Calibration:

• static - Fixed weights per domain (DEFAULT)

Domain Expertise Weights

| Agent | Security | Auth | Data | Algorithm | General |

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

| security | 3.0 | 2.5 | 2.5 | 1.5 | 1.0 |

| reviewer | 1.5 | 1.5 | 1.5 | 2.0 | 2.0 |

| architect | 1.5 | 2.0 | 2.0 | 2.5 | 2.0 |

| tester | 1.0 | 1.5 | 1.5 | 2.0 | 1.5 |

| optimizer | 0.5 | 0.5 | 0.5 | 2.5 | 1.0 |

| cleanup | 0.5 | 0.5 | 0.5 | 1.0 | 1.5 |

Weight Interpretation:

• 3.0 = Domain expert (vote counts triple)
• 2.0 = Significant expertise (vote counts double)
• 1.0 = General competence (standard vote)
• 0.5 = Peripheral relevance (half vote)

Step 1: Detect Decision Domain

Analyze the change or decision to determine primary domain:

• Use analyzer agent to examine code/proposal
• Detect keywords: auth, encrypt, password, token, permission, credential
• Identify file paths: auth/, security/, crypto/
• Classify: SECURITY | AUTH | DATA | ALGORITHM | GENERAL

Domain Detection Triggers:

```

SECURITY: encrypt, decrypt, hash, salt, vulnerability, CVE, injection

AUTH: login, logout, session, token, jwt, oauth, password, credential

DATA: pii, gdpr, sensitive, personal, private, secret, key

ALGORITHM: sort, search, calculate, compute, process, transform

```

Step 2: Select Voting Agents

Based on detected domain, select relevant agents with weights:

For SECURITY domain:

• security agent (weight: 3.0) - Primary expert
• architect agent (weight: 1.5) - System design perspective
• reviewer agent (weight: 1.5) - Code quality check
• tester agent (weight: 1.0) - Testability assessment

For AUTH domain:

• security agent (weight: 2.5) - Security implications
• architect agent (weight: 2.0) - Integration patterns
• reviewer agent (weight: 1.5) - Implementation quality
• tester agent (weight: 1.5) - Auth flow testing

For DATA domain:

• security agent (weight: 2.5) - Data protection
• architect agent (weight: 2.0) - Data architecture
• reviewer agent (weight: 1.5) - Handling patterns
• tester agent (weight: 1.5) - Data validation

For ALGORITHM domain:

• optimizer agent (weight: 2.5) - Performance analysis
• architect agent (weight: 2.5) - Design patterns
• tester agent (weight: 2.0) - Correctness testing
• reviewer agent (weight: 2.0) - Code quality

Step 3: Present Decision to Agents

Each selected agent receives:

• Clear decision statement
• Available options (if applicable)
• Relevant context and constraints
• Evaluation criteria

Decision Prompt Template:

```markdown

Domain: [SECURITY | AUTH | DATA | ALGORITHM]

Your Weight: [X.X] (based on domain expertise)

Context

[Relevant background and constraints]

Options

1. [Option A]: [Description]
2. [Option B]: [Description]
3. [Reject Both]: Propose alternative

Evaluation Criteria

• Security implications
• Implementation complexity
• Maintainability
• Risk assessment

Your Vote

Provide:

1. Your vote (Option 1, 2, or Reject)
2. Confidence level (HIGH, MEDIUM, LOW)
3. Key reasoning (2-3 sentences max)
4. Any conditions or caveats

```

Step 4: Collect Votes

For each agent, collect structured vote:

```yaml

agent: security

weight: 3.0

vote: Option 1

confidence: HIGH

reasoning: "Option 1 follows OWASP best practices for credential storage. Option 2 uses deprecated hashing algorithm."

conditions: ["Ensure salt length >= 16 bytes", "Use constant-time comparison"]

```

Step 5: Calculate Weighted Result

Weighted Vote Calculation:

```

For each option:

weighted_score = sum(agent_weight * confidence_multiplier)

Where confidence_multiplier:

HIGH = 1.0

MEDIUM = 0.7

LOW = 0.4

```

Example Calculation:

| Agent | Weight | Vote | Confidence | Score |

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

| security | 3.0 | A | HIGH | 3.0 |

| architect | 1.5 | A | MEDIUM | 1.05 |

| reviewer | 1.5 | B | HIGH | 1.5 |

| tester | 1.0 | A | LOW | 0.4 |

```

Option A Score: 3.0 + 1.05 + 0.4 = 4.45

Option B Score: 1.5

Total Weighted Votes: 5.95

Option A Percentage: 74.8% (SUPERMAJORITY)

```

Step 6: Apply Voting Threshold

Based on configured voting mode:

simple-majority (50%+):

• Option with highest weighted score wins if > 50%
• If no option > 50%, proceed to debate or reject

supermajority (66%+): (DEFAULT for security)

• Winning option must have > 66% weighted votes
• Provides stronger validation for high-risk decisions

unanimous (100%):

• All agents must agree (rare, highest bar)
• Any dissent blocks decision

Step 7: Report Consensus Result

If Consensus Reached:

```markdown

Decision: [Selected Option]

Domain: SECURITY

Threshold: Supermajority (66%+)

Result: PASSED (74.8%)

Vote Summary

| Agent | Weight | Vote | Confidence |

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

| security | 3.0 | A | HIGH |

| architect | 1.5 | A | MEDIUM |

| reviewer | 1.5 | B | HIGH |

| tester | 1.0 | A | LOW |

Key Reasoning (from highest-weighted agents)

• security (3.0): "Option 1 follows OWASP best practices..."

Conditions/Caveats

• Ensure salt length >= 16 bytes
• Use constant-time comparison

Dissenting View

• reviewer (1.5): "Option B has simpler implementation..."

```

If No Consensus:

```markdown

Decision: NO CONSENSUS

Domain: AUTH

Threshold: Supermajority (66%+)

Result: FAILED (52.3%)

Recommendation

• Escalate to /amplihack:debate for structured trade-off analysis
• OR: Gather more information and re-vote
• OR: Accept simple majority with documented risk

```

Step 8: Record Decision

• Log voting result to session decisions
• Document vote reasoning for future reference

Benefits:

• Structured decision-making for high-risk domains
• Domain expertise appropriately weighted
• Clear audit trail with reasoning
• Faster than full debate for binary/discrete choices

Costs:

• Less nuanced than debate (no synthesis)
• Requires clear options (not generative)
• Weight calibration needs real data
• May miss creative alternatives

Use When: Decision is discrete, domain expertise matters, audit trail needed

Example 1: Password Hashing Implementation

Context: Choosing between bcrypt, argon2id, and PBKDF2 for new auth system

Domain Detection: AUTH (password, hash)

Agents Selected:

• security (2.5), architect (2.0), reviewer (1.5), tester (1.5)

Votes:

• security: argon2id (HIGH) - "OWASP current recommendation, memory-hard"
• architect: argon2id (MEDIUM) - "Good library support, modern design"
• reviewer: bcrypt (HIGH) - "More battle-tested in production"
• tester: argon2id (MEDIUM) - "Easier to test with configurable params"

Result: argon2id wins with 68.2% (supermajority passed)

Example 2: API Rate Limiting Approach

Context: Token bucket vs sliding window vs fixed window

Domain Detection: SECURITY (rate limit, protection)

Agents Selected:

• security (3.0), optimizer (1.5), architect (1.5), reviewer (1.5)

Votes:

• security: token bucket (HIGH) - "Best protection against burst attacks"
• optimizer: sliding window (MEDIUM) - "Better resource utilization"
• architect: token bucket (MEDIUM) - "Industry standard, well-understood"
• reviewer: sliding window (LOW) - "Simpler implementation"

Result: token bucket wins with 69.4% (supermajority passed)

Example 3: No Consensus Scenario

Context: Microservices vs monolith for new feature

Domain Detection: ALGORITHM (general architecture)

Agents Selected:

• architect (2.5), optimizer (2.5), reviewer (2.0), tester (2.0)

Votes:

• architect: microservices (MEDIUM) - "Better long-term scalability"
• optimizer: monolith (HIGH) - "Simpler operations, less overhead"
• reviewer: monolith (MEDIUM) - "Easier to maintain initially"
• tester: microservices (LOW) - "Harder to test but more isolated"

Result: No consensus (52.1%) - Escalate to /amplihack:debate

Handoff to Debate

When voting fails to reach consensus:

1. Document vote results and reasoning
2. Invoke Skill(debate-workflow) with vote context
3. Use voting insights to frame debate perspectives

After N-Version Implementation

Use consensus voting to select between N-version implementations:

1. N-version generates 3+ implementations
2. Consensus voting selects winner
3. Domain experts have weighted influence on selection

Philosophy Alignment

This skill enforces:

• Evidence-Based Decisions: Votes require reasoning
• Domain Expertise: Weights reflect competence
• Transparent Trade-offs: Dissent documented
• Audit Trail: Full voting record preserved
• Appropriate Rigor: Auto-triggers for high-risk domains