/role-debate

Multi-role debate to explore trade-offs

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

Usage

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

Basic Examples

# 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

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

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 contro