262 lines
5.6 KiB
Markdown
262 lines
5.6 KiB
Markdown
---
|
|
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: unknown
|
|
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**.
|
|
|
|
---
|
|
|
|
## 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.
|
|
|
|
## 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.
|