先看看示例
作者提供的示例，实际效果取决于你的输入和使用工具。
输入
评审一个新功能设计方案，让质疑者假设其上线失败并列出风险，再由仲裁者裁定异议。
输出
预期交付：决策日志、逐条异议处理记录及APPROVED/REVISE/REJECT结论。（编辑说明，非实际运行结果）
方法说明
--- name: multi-agent-brainstorming description: "Simulate a structured peer-review process using multiple specialized agents to validate designs, surface hidden assumptions, and identify failure modes before implementation." risk: none source: community date_added: "2026-02-27" --- # Multi-Agent Brainstorming (Structured Design Review) ## Purpose Transform a single-agent design into a **robust, review-validated design** by simulating a formal peer-review process using multiple constrained agents. This skill exists to: - surface hidden assumptions - identify failure modes early - validate non-functional constraints - stress-test designs before implementation - prevent idea swarm chaos This is **not parallel brainstorming**. It is **sequential design review with enforced roles**. --- Distinguish actual independently invoked reviewers from one model simulating roles; never claim independent consensus from a role-play. Use only available host agents within authorized delegation scope. Set a maximum review/revision budget and end with APPROVED, REVISE or REJECT plus unresolved issues if convergence fails; missing reviewers cannot be counted as invoked. This review does not authorize implementation or safety certification. ## Operating Model - One agent designs. - Other agents review. - No agent may exceed its mandate. - Creativity is centralized; critique is distributed. - Decisions are explicit and logged. The process is **gated** and **terminates by design**. --- ## Agent Roles (Non-Negotiable) Each agent operates under a **hard scope limit**. ### 1️⃣ Primary Designer (Lead Agent) **Role:** - Owns the design - Runs the standard `brainstorming` skill - Maintains the Decision Log **May:** - Ask clarification questions - Propose designs and alternatives - Revise designs based on feedback **May NOT:** - Self-approve the final design - Ignore reviewer objections - Invent requirements post-lock --- ### 2️⃣ Skeptic / Challenger Agent **Role:** - Assume the design will fail - Identify weaknesses and risks **May:** - Question assumptions - Identify edge cases - Highlight ambiguity or overconfidence - Flag YAGNI violations **May NOT:** - Propose new features - Redesign the system - Offer alternative architectures Prompting guidance: > “Assume this design fails in production. Why?” --- ### 3️⃣ Constraint Guardian Agent **Role:** - Enforce non-functional and real-world constraints Focus areas: - performance - scalability - reliability - security & privacy - maintainability - operational cost **May:** - Reject designs that violate constraints - Request clarification of limits **May NOT:** - Debate product goals - Suggest feature changes - Optimize beyond stated requirements --- ### 4️⃣ User Advocate Agent **Role:** - Represent the end user Focus areas: - cognitive load - usability - clarity of flows - error handling from user perspective - mismatch between intent and experience **May:** - Identify confusing or misleading aspects - Flag poor defaults or unclear behavior **May NOT:** - Redesign architecture - Add features - Override stated user goals --- ### 5️⃣ Integrator / Arbiter Agent **Role:** - Resolve conflicts - Finalize decisions - Enforce exit criteria **May:** - Accept or reject objections - Require design revisions - Declare the design complete **May NOT:** - Invent new ideas - Add requirements - Reopen locked decisions without cause --- ## The Process ### Phase 1 — Single-Agent Design 1. Primary Designer runs the **standard `brainstorming` skill** 2. Understanding Lock is completed and confirmed 3. Initial design is produced 4. Decision Log is started No other agents participate yet. --- ### Phase 2 — Structured Review Loop Agents are invoked **one at a time**, in the following order: 1. Skeptic / Challenger 2. Constraint Guardian 3. User Advocate For each reviewer: - Feedback must be explicit and scoped - Objections must reference assumptions or decisions - No new features may be introduced Primary Designer must: - Respond to each objection - Revise the design if required - Update the Decision Log --- ### Phase 3 — Integration & Arbitration The Integrator / Arbiter reviews: - the final design - the Decision Log - unresolved objections The Arbiter must explicitly decide: - which objections are accepted - which are rejected (with rationale) --- ## Decision Log (Mandatory Artifact) The Decision Log must record: - Decision made - Alternatives considered - Objections raised - Resolution and rationale No design is considered valid without a completed log. --- ## Exit Criteria (Hard Stop) You may exit multi-agent brainstorming **only when all are true**: - Understanding Lock was completed - All reviewer agents have been invoked - All objections are resolved or explicitly rejected - Decision Log is complete - Arbiter has declared the design acceptable If any criterion is unmet: - Continue review - Do NOT proceed to implementation If this skill was invoked by a routing or orchestration layer, you MUST report the final disposition explicitly as one of: APPROVED, REVISE, or REJECT, with a brief rationale. --- ## Failure Modes This Skill Prevents - Idea swarm chaos - Hallucinated consensus - Overconfident single-agent designs - Hidden assumptions - Premature implementation - Endless debate --- ## Key Principles - One designer, many reviewers - Creativity is centralized - Critique is constrained - Decisions are explicit - Process must terminate --- ## Final Reminder This skill exists to answer one question with confidence: > “If this design fails, did we do everything reasonable to catch it early?” If the answer is unclear, **do not exit this skill**. ## When to Use This skill is applicable to execute the workflow or actions described in the overview. ## Example **User request:** > Use @multi-agent-brainstorming for this task: Simulate a structured peer-review process using multiple specialized agents to validate designs, surface hidden assumptions, and identify failure modes before implementation. ## Limitations - Use this skill only when the task clearly matches the scope described above. - Do not treat the output as a substitute for environment-specific validation, testing, or expert review. - Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.