multi-agent-brainstorming

Use this skill when a design or idea requires higher confidence, risk reduction, or formal review. This skill orchestrates a structured, sequential multi-agent design review where each agent has a strict, non-overlapping role. It prevents blind spots, false confidence, and premature convergence.

View Source
name:multi-agent-brainstormingdescription:>

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.


    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

  • Primary Designer runs the standard brainstorming skill

  • Understanding Lock is completed and confirmed

  • Initial design is produced

  • 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:

  • Skeptic / Challenger

  • Constraint Guardian

  • 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.