Skill

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


90
Spark score
out of 100
Updated 16 days ago
Version 14.4.0

Add to Favorites

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

01

Simulate a formal peer-review process using distinct agent roles.

02

Identify hidden assumptions, failure modes, and constraint violations early.

03

Stress-test designs before implementation to prevent costly errors.

04

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:

  1. Primary Designer - owns the design, runs brainstorming, maintains the Decision Log
  2. Skeptic/Challenger - assumes the design will fail and identifies weaknesses using prompts like:
"Assume this design fails in production. Why?"
  1. Constraint Guardian - enforces non-functional constraints (performance, scalability, reliability, security, maintainability, operational cost)
  2. User Advocate - represents end users, focusing on cognitive load, usability, clarity, and error handling
  3. 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.