Multi Agent Brainstorming

Iron Law

NO IMPLEMENTATION UNTIL ARBITER DECLARES APPROVED — a design not reviewed by all 5 roles may proceed to brainstorming but NEVER to code

Explanation: Single-agent designs have blind spots. Without adversarial validation, hidden assumptions become production failures. The 5-role review exists specifically to find these before a line is written.

Multi-Agent Brainstorming (Structured Design Review)

Transform a single-agent design into a review-validated design by simulating a formal peer-review process using 5 constrained agent roles invoked sequentially.

This is not parallel brainstorming. It is sequential design review with enforced scope limits.

When to Use

• Validating a system architecture before committing to implementation
• Stress-testing a major feature design (multi-service, schema change, auth flow)
• Reviewing any irreversible decision (public API contract, DB migration, auth architecture)
• After /brainstorm produces a preferred option — before /plan-review locks the plan
• When the-fool single-agent critique is not sufficient for high-stakes decisions

Relationship to other skills:

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 role operates under a hard scope limit. Load references/agent-role-scripts.md for detailed prompting guidance per role.

Process

Phase 1 — Single-Agent Design

1. Primary Designer runs /brainstorm or defines the initial design independently
2. Understanding Lock is completed and confirmed (restate goal, constraints, and assumptions)
3. Initial design is produced
4. Decision Log is started (load references/decision-log-template.md)

No other roles participate in Phase 1.

Phase 2 — Structured Review Loop

Roles are invoked one at a time, in this order:

1. Skeptic / Challenger
2. Constraint Guardian
3. User Advocate

For each reviewer:

• Feedback must be explicit and scoped to the role's mandate
• Objections must reference specific assumptions or decisions
• No new features may be introduced

Primary Designer must respond to each objection, revise if required, and update the Decision Log.

Phase 3 — Integration & Arbitration

Integrator / Arbiter reviews:

• The final design
• The completed Decision Log
• Any unresolved objections

The Arbiter must explicitly decide which objections are accepted (with revisions) and which are rejected (with rationale).

Final verdict must be one of: APPROVED | REVISE | REJECT

Exit Criteria (Hard Stop)

You may exit only when all of these are true:

• Understanding Lock was completed
• All 3 reviewer roles have been invoked (Skeptic, Constraint Guardian, User Advocate)
• All objections are resolved or explicitly rejected with rationale
• Decision Log is complete
• Arbiter has declared APPROVED, REVISE, or REJECT

If any criterion is unmet — continue review. Do NOT proceed to implementation.

Reference Files

Constraints

MUST DO

• Run Phase 1 fully before invoking any reviewer
• Invoke reviewers in order: Skeptic → Constraint Guardian → User Advocate
• Log every objection and its resolution in the Decision Log
• Produce a final Arbiter verdict before reporting done

MUST NOT DO

• Allow reviewers to introduce new features or redesign the system
• Skip any reviewer role, even if the design seems solid
• Declare the design approved without completing the Decision Log
• Proceed to implementation on REVISE or REJECT verdict

Output Format

## Design Review: [design name]

### Understanding Lock
- Goal: [what we're building]
- Constraints: [technical, resource, time]
- Assumptions: [what we're taking for granted]

### Initial Design
[Description + diagram if applicable]

### Skeptic Review
**Objections raised:**
- [objection 1]
**Resolution:** [how it was addressed]

### Constraint Guardian Review
**Objections raised:**
- [objection 1]
**Resolution:** [how it was addressed]

### User Advocate Review
**Objections raised:**
- [objection 1]
**Resolution:** [how it was addressed]

### Decision Log
[Summary of all decisions, alternatives considered, and rationale]

### Arbiter Verdict
**APPROVED / REVISE / REJECT**
**Rationale:** [one paragraph]
**Next step:** [proceed to /plan-review | revise design and re-review | abandon]

Failure Modes This Skill Prevents

• Idea swarm chaos (reviewers proposing new features instead of critiquing)
• Hallucinated consensus (agreeing without adversarial challenge)
• Overconfident single-agent designs (no external critique)
• Hidden assumptions running unchecked into implementation
• Premature implementation (building before validation)
• Endless debate (hard exit criteria force resolution)

Knowledge Reference

Pre-mortem analysis, red-team adversarial review, structured debate, adversarial collaboration, design review, decision log, consensus mechanisms, YAGNI, non-functional requirements