## Role Debate

A command that allows roles with different expertise to discuss and examine trade-offs to derive optimal solutions.

### Usage

```bash
/role-debate <Role 1>,<Role 2> [Topic]
/role-debate <Role 1>,<Role 2>,<Role 3> [Topic]
```

### Basic Examples

```bash
# Security vs Performance trade-off
/role-debate security,performance
"JWT Token Expiry Setting"

# Usability vs Security balance
/role-debate frontend,security
"2-Factor Authentication UX Optimization"

# Technology selection discussion
/role-debate architect,mobile
"React Native vs Flutter Selection"

# Three-party debate
/role-debate architect,security,performance
"Pros and Cons of Microservices"
```

### Basic Principles of Debate

#### Constructive Debate Guidelines

- **Mutual Respect**: Respect the expertise and perspectives of other roles
- **Fact-Based**: Debate based on data and evidence, not emotional reactions
- **Solution-Oriented**: Aim for better solutions rather than criticizing for criticism's sake
- **Implementation-Focused**: Consider feasibility rather than idealism

#### Quality Requirements for Arguments

- **Official Documentation**: Reference standards, guidelines, and official documentation
- **Empirical Cases**: Specific citations of success or failure cases
- **Quantitative Evaluation**: Comparisons using numbers and metrics whenever possible
- **Time-Series Consideration**: Evaluation of short-term, medium-term, and long-term impacts

#### Debate Ethics

- **Honesty**: Acknowledge the limits of your expertise
- **Openness**: Flexibility toward new information and perspectives
- **Transparency**: Explicitly state judgment grounds and assumptions
- **Accountability**: Mention implementation risks of proposals

### Debate Process

### Phase 1: Initial Position Statement

Each role independently expresses opinions from their professional perspective

- Presentation of recommendations
- Explicit citation of standards and documents as grounds
- Explanation of anticipated risks and issues
- Definition of success metrics

### Phase 2: Mutual Discussion & Rebuttal

Cross-discussion between roles

- Constructive rebuttal of other roles' proposals
- Identification of overlooked perspectives
- Clarification of trade-offs
- Presentation of alternatives

### Phase 3: Search for Compromises

Exploration of implementable solutions

- Evaluation of the importance of each perspective
- Consideration of win-win solutions
- Step-by-step implementation approach
- Consideration of risk mitigation measures

### Phase 4: Integrated Conclusion

Determining final recommendations

- Agreed-upon solution
- Implementation roadmap
- Success metrics and measurement methods
- Future review points

### Output Format Examples

### For 2-Role Debate

```text
Role Debate: Security vs Performance
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Topic: JWT Token Expiry Setting

Security Role's Argument:
"15-minute short expiry recommended"

Grounds:
- Compliance with OWASP JWT Security Cheat Sheet
- Minimizing damage window in case of token leakage
- Limiting attacker available time

Concerns:
- Long expiry exponentially increases attack risk
- Short expiry mandatory for financial compliance

Success Metrics:
- Security incident rate < 0.1%
- Average attack detection time < 5 minutes

Performance Role's Rebuttal:
"2-hour expiry recommended"

Grounds:
- Reference to Google OAuth 2.0 Best Practices
- Avoiding increased server load from frequent reauthentication
- Minimizing user experience disruption

Concerns:
- 15-minute reauthentication increases API load by 8x
- Frequent disconnections in mobile environments

Success Metrics:
- Maintain API response time < 200ms
- Server CPU usage < 60%

Mutual Discussion:
Security → Performance:
"Business losses from security breaches are greater than server load.
Example: Equifax breach cost $700 million"

Performance → Security:
"Both can be achieved with refresh token mechanism.
Background updates ensure security without compromising UX"

Security → Performance:
"Refresh tokens are also attack targets. Proper implementation is prerequisite"

Performance → Security:
"Propose phased approach. 30 minutes for normal operations, 15 minutes for sensitive operations"

Compromise Search:
Common Understanding:
- Need to balance user experience and security
- Flexible response based on risk level
- Practical consideration of implementation and operational costs

Win-Win Elements:
- Utilization of refresh token mechanism
- Phased introduction of risk-based authentication
- Complementation with auto-logout function

Integrated Conclusion:
"30-minute expiry + refresh token + risk-based authentication"

Implementation Details:
1. Access token: 30-minute expiry
2. Refresh token: 7-day expiry
3. High-risk operations: Enforce reauthentication every 15 minutes
4. Auto-logout after 30 minutes of inactivity

Phased Implementation:
Weeks 1-2: Basic 30-minute token implementation
Weeks 3-4: Add refresh token mechanism
Month 2: Introduce risk-based authentication

Success Metrics:
- Security: Incident rate < 0.1%
- Performance: API load increase < 20%
- UX: User satisfaction > 85%

Future Review:
- After 3 months: Evaluate actual attack patterns and load conditions
- After 6 months: Consider migration to more sophisticated risk-based authentication
```

### For 3-Role Debate

```text
Role Debate: Architect vs Security vs Performance
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Topic: Pros and Cons of Microservices

Architect Role's Argument:
"Phased microservices recommended"
Grounds: Clear domain boundaries, independent deployment, freedom in technology selection

Security Role's Concerns:
"Security complexity of inter-service communication"
Grounds: Management costs of API Gateway, mTLS, distributed authentication

Performance Role's Concerns:
"Latency increase due to network communication"
Grounds: N+1 problem from internal API calls, distributed transactions

Three-Party Discussion:
Architect → Security: "Can be controlled through centralized API Gateway management"
Security → Architect: "Risk of single point of failure"
Performance → Architect: "Service division granularity is important"
...(discussion continues)

Integrated Conclusion:
"Domain-driven design for phased division + security-first design"
```

### Effective Debate Patterns

### Technology Selection

```bash
/role-debate architect,performance
"Database Selection: PostgreSQL vs MongoDB"

/role-debate frontend,mobile
"UI Framework: React vs Vue"

/role-debate security,architect
"Authentication Method: JWT vs Session Cookie"
```

### Design Decisions

```bash
/role-debate security,frontend
"User Authentication UX Design"

/role-debate performance,mobile
"Data Synchronization Strategy Optimization"

/role-debate architect,qa
"Test Strategy and Architecture Design"
```

### Trade-off Issues

```bash
/role-debate security,performance
"Encryption Level vs Processing Speed"

/role-debate frontend,performance
"Rich UI vs Page Loading Speed"

/role-debate mobile,security
"Convenience vs Data Protection Level"
```

### Role-Specific Debate Characteristics

#### 🔒 Security Role

```yaml
debate_stance:
  - Conservative approach (risk minimization)
  - Compliance-focused (cautious about deviations from standards)
  - Worst-case scenario assumption (attacker perspective)
  - Long-term impact focus (security as technical debt)

typical_issues:
  - "Security vs Convenience" trade-offs
  - "Mandatory compliance requirements"
  - "Attack cost vs Defense cost comparison"
  - "Thorough privacy protection"

evidence_sources:
  - OWASP guidelines
  - NIST frameworks
  - Industry standards (ISO 27001, SOC 2)
  - Actual attack cases and statistics

debate_strengths:
  - Precision in risk assessment
  - Knowledge of regulatory requirements
  - Understanding of attack methods

potential_biases:
  - Excessive conservatism (inhibiting innovation)
  - Insufficient UX consideration
  - Downplaying implementation costs
```

#### ⚡ Performance Role

```yaml
debate_stance:
  - Data-driven decisions (measurement-based)
  - Efficiency-focused (optimizing cost-effectiveness)
  - User experience priority (perceived speed focus)
  - Continuous improvement (phased optimization)

typical_issues:
  - "Performance vs Security"
  - "Optimization cost vs effectiveness ROI"
  - "Current vs future scalability"
  - "User experience vs system efficiency"

evidence_sources:
  - Core Web Vitals metrics
  - Benchmark results and statistics
  - Impact data on user behavior
  - Industry performance standards

debate_strengths:
  - Quantitative evaluation ability
  - Bottleneck identification
  - Knowledge of optimization techniques

potential_biases:
  - Downplaying security
  - Insufficient maintainability consideration
  - Premature optimization
```

#### 🏗️ Architect Role

```yaml
debate_stance:
  - Long-term perspective (consideration for system evolution)
  - Balance pursuit (overall optimization)
  - Phased changes (risk management)
  - Standard compliance (preference for proven patterns)

typical_issues:
  - "Short-term efficiency vs long-term maintainability"
  - "Technical debt vs development speed"
  - "Microservices vs monolith"
  - "New technology adoption vs stability"

evidence_sources:
  - Architecture pattern collections
  - Design principles (SOLID, DDD)
  - Large-scale system cases
  - Technology evolution trends

debate_strengths:
  - Overall perspective ability
  - Knowledge of design patterns
  - Prediction of long-term impacts

potential_biases:
  - Excessive generalization
  - Conservatism toward new technologies
  - Insufficient understanding of implementation details
```

#### 🎨 Frontend Role

```yaml
debate_stance:
  - User-centered design (UX first priority)
  - Inclusive approach (diversity consideration)
  - Intuitiveness focus (minimizing learning costs)
  - Accessibility standards (WCAG compliance)

typical_issues:
  - "Usability vs Security"
  - "Design consistency vs platform optimization"
  - "Functionality vs simplicity"
  - "Performance vs rich experience"

evidence_sources:
  - UX research and usability test results
  - Accessibility guidelines
  - Design system standards
  - User behavior data

debate_strengths:
  - Representation of user perspective
  - Knowledge of design principles
  - Accessibility requirements

potential_biases:
  - Insufficient understanding of technical constraints
  - Downplaying security requirements
  - Underestimation of performance impact
```

#### 📱 Mobile Role

```yaml
debate_stance:
  - Platform specialization (considering iOS/Android differences)
  - Context adaptation (on-the-go, one-handed operation)
  - Resource constraints (battery, memory, communication)
  - Store compliance (review guidelines)

typical_issues:
  - "Native vs cross-platform"
  - "Offline support vs real-time synchronization"
  - "Battery efficiency vs functionality"
  - "Platform unification vs optimization"

evidence_sources:
  - iOS HIG / Android Material Design
  - App Store / Google Play guidelines
  - Mobile UX research
  - Device performance statistics

debate_strengths:
  - Understanding of mobile-specific constraints
  - Knowledge of platform differences
  - Touch interface design

potential_biases:
  - Insufficient understanding of web platform
  - Downplaying server-side constraints
  - Insufficient consideration for desktop environment
```

#### 🔍 Analyzer Role

```yaml
debate_stance:
  - Evidence-focused (data-first)
  - Hypothesis verification (scientific approach)
  - Structural thinking (system thinking)
  - Bias elimination (objectivity pursuit)

typical_issues:
  - "Correlation vs causation"
  - "Symptomatic treatment vs root solution"
  - "Distinction between hypothesis and fact"
  - "Short-term symptoms vs structural problems"

evidence_sources:
  - Measured data and log analysis
  - Statistical methods and analysis results
  - System thinking theory
  - Cognitive bias research

debate_strengths:
  - Logical analysis ability
  - Objectivity in evidence evaluation
  - Discovery of structural problems

potential_biases:
  - Analysis paralysis (insufficient action)
  - Perfectionism (downplaying practicality)
  - Data absolutism
```

### Debate Progression Templates

#### Phase 1: Position Statement Template

```text
[Role Name]'s Recommendation:
"[Specific proposal]"

Grounds:
- [Reference to official documents/standards]
- [Empirical cases/data]
- [Professional field principles]

Expected Effects:
- [Short-term effects]
- [Medium to long-term effects]

Concerns/Risks:
- [Implementation risks]
- [Operational risks]
- [Impacts on other fields]

Success Metrics:
- [Measurable metric 1]
- [Measurable metric 2]
```

#### Phase 2: Rebuttal Template

```text
Rebuttal to [Target Role]:
"[Specific rebuttal to target proposal]"

Rebuttal Grounds:
- [Overlooked perspectives]
- [Contradictory evidence/cases]
- [Concerns from professional field]

Alternative Proposal:
"[Improved proposal]"

Compromise Points:
- [Acceptable conditions]
- [Possibility of phased implementation]
```

#### Phase 3: Integrated Solution Template

```text
Integrated Solution:
"[Final proposal considering all roles' concerns]"

Considerations for Each Role:
- [Security]: [How security requirements are met]
- [Performance]: [How performance requirements are met]
- [Others]: [How other requirements are met]

Implementation Roadmap:
- Phase 1 (Immediate): [Urgent response items]
- Phase 2 (Short-term): [Basic implementation]
- Phase 3 (Medium-term): [Complete implementation]

Success Metrics & Measurement Methods:
- [Integrated success metrics]
- [Measurement methods/frequency]
- [Review timing]
```

### Debate Quality Checklist

#### Evidence Quality

- [ ] References to official documents/standards
- [ ] Specific cases/data presented
- [ ] Distinction between speculation and fact
- [ ] Sources explicitly stated

#### Debate Constructiveness

- [ ] Accurate understanding of opponent's proposals
- [ ] Logical rather than emotional rebuttal
- [ ] Alternatives also presented
- [ ] Exploration of win-win possibilities

#### Implementation Feasibility

- [ ] Technical feasibility considered
- [ ] Implementation costs/duration estimated
- [ ] Phased implementation possibility considered
- [ ] Risk mitigation measures presented

#### Integration

- [ ] Impacts on other fields considered
- [ ] Pursuit of overall optimization
- [ ] Long-term perspective included
- [ ] Measurable success metrics set

### Collaboration with Claude

```bash
# Debate based on design documents
cat system-design.md
/role-debate architect,security
"Discuss security issues in this design"

# Solution debate based on problems
cat performance-issues.md
/role-debate performance,architect
"Discuss fundamental solutions to performance issues"

# Technology selection debate based on requirements
/role-debate mobile,frontend
"Discuss unified UI strategy for iOS, Android, and Web"
```

### Notes

- Debates may take time (longer for complex topics)
- With 3+ roles, discussions may diverge
- Final decisions should be made by users referencing debate results
- For urgent issues, consider single role or multi-role first