wasabeef 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 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
/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
/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
/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
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
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
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
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
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
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
[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
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
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
# 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