team-shinchan:debate
npx machina-cli add skill seokan-jeong/team-shinchan/debate --openclawEXECUTE IMMEDIATELY
Step 0: Validate Input
If args empty: ask user for topic and STOP. If args > 2000 chars: truncate + warn.
All debates invoke Midori via Task tool.
Auto-Trigger Conditions
| Trigger YES | Trigger NO |
|---|---|
| 2+ approaches, architecture change, pattern break, perf vs readability, security, tech stack | Simple CRUD, clear bug fix, user already decided |
On detection: announce "Design decision needed: [situation]", proceed Steps 1-3. Record decision in REQUESTS.md (Stage 1) or PROGRESS.md (Stage 2+).
Step 1: Invoke Midori
Task(subagent_type="team-shinchan:midori", model="sonnet",
prompt="Debate topic: {topic}\nPanel: {panel list}\nProcedure: Announce, collect opinions (parallel), Hiroshi derives consensus, report decision.")
Step 2: Deliver Results
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
💭 Debate Results
📋 Topic: {topic}
🎤 Opinions: [Agent]: {summary} ...
✅ Decision: {conclusion} | 📝 Rationale: {reasoning}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Step 3: Confirm + Finalize
Ask user if they agree. If yes: document and proceed. If no: revise reflecting concerns. Never proceed without confirmation.
Panel Selection
See agents/midori.md for full criteria. Quick reference:
| Topic | Panel |
|---|---|
| Frontend/UI | Aichan, Hiroshi |
| Backend/API | Bunta, Hiroshi |
| DevOps/Infra | Masao, Hiroshi |
| Architecture | Hiroshi, Nene, Misae |
| Security | Hiroshi, Bunta, Masao |
Auto-Detection Signals
Keywords: "A or B", "vs", "method1/method2", "schema change", "layer", "structure", "differs from existing pattern", "trade-off", "at the cost of", "auth", "encryption", "permission"
Source
git clone https://github.com/seokan-jeong/team-shinchan/blob/main/skills/debate/SKILL.mdView on GitHub Overview
team-shinchan:debate orchestrates specialized agents to debate a topic and surface an optimal solution. It is designed for debates, pros and cons, and gathering opinions, using a structured flow to collect insights and reach a consensus.
How This Skill Works
Input is validated and, if valid, the system triggers a Midori-based debate via a Task tool with a defined prompt and panel. Midori collects opinions in parallel, Hiroshi derives a consensus and reports a decision, and the outcome is documented. Final confirmation from the user is required before finalizing and the decision is recorded in REQUESTS.md (Stage 1) or PROGRESS.md (Stage 2+).
When to Use It
- Choosing between architectural patterns (e.g., microservices vs monolith)
- Evaluating competing design approaches (e.g., REST vs GraphQL)
- Assessing performance vs readability trade-offs
- Security vs usability trade-offs in a new feature
- Gathering diverse opinions to reach a documented decision
Quick Start
- Step 1: Validate topic, scope, and ensure multiple approaches are on the table
- Step 2: Invoke Midori via Task tool with the topic and panel list
- Step 3: Review the Debate Results, then obtain user confirmation before finalizing
Best Practices
- Define a clear topic and acceptance criteria before running the debate
- Ensure 2+ distinct approaches are on the table
- Leverage the Panel to gather diverse viewpoints and document reasoning
- Require user confirmation before finalizing the decision
- Record decisions in REQUESTS.md or PROGRESS.md with the rationale
Example Use Cases
- Frontend UI framework decision (React vs Vue) with Aichan and Hiroshi on the panel
- Backend API approach (REST vs GraphQL) with Bunta and Hiroshi on the panel
- DevOps/Infra strategy (Kubernetes vs serverless) with Masao and Hiroshi on the panel
- Security approach (OAuth vs SSO) with Hiroshi, Bunta, and Masao on the panel
- Architectural refactor (monolith to microservices) with Hiroshi, Nene, and Misae on the panel