Consensus Voting

Consensus Voting Skill

Purpose

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.

Key Insight from Pattern Analysis

From .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.

When to Use This Skill

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

Configuration

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

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)

Execution Process

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:

## Decision Required: [TITLE]

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

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:

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:

## Consensus Voting Result

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

## Consensus Voting Result

**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

Trade-Offs

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

Examples

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

Integration with Other Workflows

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