Get the FREE Ultimate OpenClaw Setup Guide →

team-shinchan:debate

npx machina-cli add skill seokan-jeong/team-shinchan/debate --openclaw
Files (1)
SKILL.md
2.0 KB

EXECUTE 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 YESTrigger NO
2+ approaches, architecture change, pattern break, perf vs readability, security, tech stackSimple 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:

TopicPanel
Frontend/UIAichan, Hiroshi
Backend/APIBunta, Hiroshi
DevOps/InfraMasao, Hiroshi
ArchitectureHiroshi, Nene, Misae
SecurityHiroshi, 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

  1. Step 1: Validate topic, scope, and ensure multiple approaches are on the table
  2. Step 2: Invoke Midori via Task tool with the topic and panel list
  3. 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

Frequently Asked Questions

Add this skill to your agents
Sponsor this space

Reach thousands of developers