Multi Agent Brainstorming
Stress-test a design with role-bound reviewer agents before you commit to implementation, using a gated sequential review—not parallel idea spam.
Overview
Multi-agent-brainstorming is a journey-wide agent skill that runs structured, role-gated multi-agent design review—usable whenever a solo builder needs to validate a design and log decisions before committing to implemen
Install
npx skills add https://github.com/sickn33/antigravity-awesome-skills --skill multi-agent-brainstormingWhat is this skill?
- Sequential design review with enforced agent roles—not parallel brainstorming swarms
- Primary Designer runs the standard brainstorming skill and maintains a Decision Log; reviewers cannot expand mandate
- Surfaces hidden assumptions, failure modes, and non-functional constraint violations before code
- Hard-gated process that terminates by design with explicit logged decisions
- Lead designer may not self-approve or invent requirements after lock
Adoption & trust: 966 installs on skills.sh; 40.1k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have a design from one agent session but no disciplined peer review to catch assumptions, failure modes, or constraint violations before you build.
Who is it for?
Solo builders designing systems or features who want adversarial, role-separated critique without uncontrolled multi-agent brainstorming.
Skip if: Quick edits when the spec is already approved and locked, or when you only need a single casual ideation pass without formal reviewer roles.
When should I use this skill?
Before implementation when you need structured peer-review simulation to validate designs, surface assumptions, and identify failure modes.
What do I get? / Deliverables
You exit with a review-validated design, explicit Decision Log entries, and reviewer objections resolved or deferred—then proceed to implementation or invoke writing-plans when the stack calls for it.
- Review-validated design narrative
- Decision Log with explicit approvals and deferred objections
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Compare two hosting architectures with security and ops reviewers before you pick a stack.
Lock API boundaries after reviewers challenge auth assumptions and data retention risks.
Re-review a milestone design when scope creeps so the Decision Log captures explicit tradeoffs.
Stress-test a deployment design for failure modes before enabling production traffic.
Validate an observability redesign with performance reviewers before rolling it out fleet-wide.
How it compares
Structured sequential design review with mandated roles—not unconstrained parallel agent brainstorming or a one-shot chat opinion.
Common Questions / FAQ
Who is multi-agent-brainstorming for?
Indie builders and agent users who need formalized design review—assumptions, failure modes, and NFR checks—before implementation, especially without human teammates.
When should I use multi-agent-brainstorming?
Use it during validate scoping before build, at idea-stage when choosing architecture, pre-ship when revisiting risky designs, and anytime you need gated reviewer agents instead of idea swarm chaos.
Is multi-agent-brainstorming safe to install?
It orchestrates review roles in prompt space only; check the Security Audits panel on this page and avoid piping untrusted reviewer outputs directly into production changes without human verification.
Workflow Chain
Requires first: brainstorming
Then invoke: writing plans
SKILL.md
READMESKILL.md - Multi Agent Brainstorming
# 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 recor