Validate Designs with Multi-Agent Review
Sequential multi-agent design review skill that validates designs through enforced roles: one designer, multiple reviewers, explicit decision logging, and
Why it matters
Transform single-agent designs into robust, review-validated designs by simulating a formal peer-review process with multiple constrained agents.
Outcomes
What it gets done
Simulate a formal peer-review process using distinct agent roles.
Identify hidden assumptions, failure modes, and constraint violations early.
Stress-test designs before implementation to prevent costly errors.
Generate a Decision Log detailing all design choices and resolutions.
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/ag-multi-agent-brainstorming | bash Overview
Multi-Agent Brainstorming (Structured Design Review)
Multi-Agent Brainstorming (Structured Design Review) transforms single-agent designs through a formal peer-review process using multiple constrained agents. It surfaces hidden assumptions, identifies failure modes early, validates non-functional constraints, and stress-tests designs before implementation through sequential design review with enforced roles. Use this skill when you need to validate a design before implementation, especially for systems where failure modes must be caught early or when non-functional constraints (performance, scalability, security, maintainability) are critical. Apply it when you want to prevent idea swarm chaos and ensure decisions are explicit and logged. Do NOT use this for parallel brainstorming or when you need rapid iteration without formal review. This is not appropriate when requirements are still fluid or when you need creative exploration rather than validation.
What it does
Multi-Agent Brainstorming (Structured Design Review) transforms single-agent designs through a formal peer-review process using multiple constrained agents. It surfaces hidden assumptions, identifies failure modes early, validates non-functional constraints, and stress-tests designs before implementation through sequential design review with enforced roles.
When to use - and when NOT to
Use this skill when you need to validate a design before implementation, especially for systems where failure modes must be caught early or when non-functional constraints (performance, scalability, security, maintainability) are critical. Apply it when you want to prevent idea swarm chaos and ensure decisions are explicit and logged.
Do NOT use this for parallel brainstorming or when you need rapid iteration without formal review. This is not appropriate when requirements are still fluid or when you need creative exploration rather than validation.
Inputs and outputs
You provide an initial design concept and requirements. The Primary Designer runs the standard brainstorming skill and produces an initial design with a Decision Log.
You receive a completed Decision Log recording all decisions, alternatives considered, objections raised, and resolutions, and an explicit final disposition (APPROVED, REVISE, or REJECT) with rationale.
Who it's for
This skill serves AI system designers and architects who need to validate designs through structured critique before implementation. It's built for teams that want to prevent overconfident single-agent designs and ensure that the question "If this design fails, did we do everything reasonable to catch it early?" can be answered with confidence.
The process defines agent roles with hard scope limits:
- Primary Designer - owns the design, runs brainstorming, maintains the Decision Log
- Skeptic/Challenger - assumes the design will fail and identifies weaknesses using prompts like:
"Assume this design fails in production. Why?"
- Constraint Guardian - enforces non-functional constraints (performance, scalability, reliability, security, maintainability, operational cost)
- User Advocate - represents end users, focusing on cognitive load, usability, clarity, and error handling
- Integrator/Arbiter - resolves conflicts, finalizes decisions, enforces exit criteria
The operating model centralizes creativity in one designer while distributing critique across specialized reviewers. Each agent operates under hard scope limits: the Skeptic may NOT propose new features or redesign the system, the Constraint Guardian may NOT debate product goals, the User Advocate may NOT override stated user goals, and the Arbiter may NOT invent new ideas or add requirements.
The process is gated and terminates by design through three phases: single-agent design, structured review loop (invoking reviewers one at a time), and integration/arbitration. Exit criteria are explicit: Understanding Lock completed, all reviewers invoked, all objections resolved or rejected, Decision Log complete, and Arbiter approval declared.
This skill prevents idea swarm chaos, hallucinated consensus, overconfident single-agent designs, hidden assumptions, premature implementation, and endless debate.
Source README
This skill exists to:
- surface hidden assumptions
- identify failure modes early
- validate non-functional constraints
- stress-test designs before implementation
- prevent idea swarm chaos
FAQ
Common questions
Discussion
Questions & comments ยท 0
Sign In Sign in to leave a comment.