---
title: "Brainstorm: Rules"
description: "4 rules for the Brainstorm skill: Limit parallel brainstorm agents to 5 maximum to avoid diminishing returns and context waste; Flag ideas that exceed current team or infrastructure capacity using tier-based complexity ceilings; Brainstorm must converge to actionable recommendations with clear next steps, not just list ideas; Each idea must have a feasibility score (1-5) before synthesis; flag unfeasible ideas explicitly"
canonical: "https://orchestkit.yonyon.ai/docs/reference/skills/brainstorm/rules"
---

# Brainstorm: Rules

4 rules for the Brainstorm skill: Limit parallel brainstorm agents to 5 maximum to avoid diminishing returns and context waste; Flag ideas that exceed current team or infrastructure capacity using tier-based complexity ceilings; Brainstorm must converge to actionable recommendations with clear next steps, not just list ideas; Each idea must have a feasibility score (1-5) before synthesis; flag unfeasible ideas explicitly

> Part of the [Brainstorm](/docs/reference/skills/brainstorm) skill reference. The main page carries the skill itself; this page holds material that used to sit at the bottom of it.

## Rules (4)

### Limit parallel brainstorm agents to 5 maximum to avoid diminishing returns and context waste — MEDIUM


# Agent Count Limit

Never spawn more than 5 parallel brainstorm agents (Task tool or Agent Teams). Beyond 5, each additional agent produces diminishing returns while consuming significant tokens, and the synthesis phase struggles to meaningfully integrate outputs from too many sources.

## Problem

The brainstorm skill dynamically selects agents based on topic keywords (Step 0). Without a hard cap, broad topics like "brainstorm full-stack architecture" can trigger 7-8 agents (workflow-architect, backend, frontend, security, data, devops, test-generator, performance). Each agent consumes 40-80K tokens. The synthesis phase then receives 400K+ tokens of input, leading to shallow integration, missed contradictions, and context exhaustion before the design presentation completes.

## Token Budget by Agent Count

| Agents | Est. Tokens (Task) | Est. Tokens (Teams) | Synthesis Quality |
|--------|--------------------|--------------------|-------------------|
| 2-3 | ~100-150K | ~200-300K | Excellent |
| 4-5 | ~150-250K | ~300-500K | Good |
| 6-7 | ~250-350K | ~500-700K | Degraded |
| 8+ | ~350K+ | ~700K+ | Poor -- context exhaustion likely |

## Rules

- Maximum 5 agents in any brainstorm session (including the mandatory `workflow-architect` and `test-generator`)
- This leaves 3 slots for domain-specific agents selected by topic analysis
- If topic analysis suggests more than 5 agents, prioritize by relevance and merge overlapping roles
- Document which agents were excluded and why in `00-topic-analysis.json`

**Incorrect -- spawning too many agents for a broad topic:**
```python
# Topic: "brainstorm e-commerce platform architecture"
# 8 agents spawned -- exceeds limit
TaskCreate(subject="workflow-architect: system design")
TaskCreate(subject="backend-system-architect: API design")
TaskCreate(subject="frontend-ui-developer: UI patterns")
TaskCreate(subject="security-auditor: auth + payments")
TaskCreate(subject="data-pipeline-engineer: analytics")
TaskCreate(subject="devops-engineer: deployment")
TaskCreate(subject="test-generator: test strategy")
TaskCreate(subject="performance-engineer: load testing")
# Synthesis receives 8 agent outputs (~400K tokens)
# Context exhaustion before design presentation completes
```

**Correct -- capping at 5, merging overlapping roles:**
```python
# Topic: "brainstorm e-commerce platform architecture"
# 8 candidates identified, capped to 5 by priority
selected = [
    "workflow-architect",          # Always included (system design lead)
    "backend-system-architect",    # Core: API + data model
    "security-auditor",            # Critical: payments require security focus
    "frontend-ui-developer",       # User-facing: checkout + catalog UX
    "test-generator",              # Always included (testability)
]
excluded = [
    {"agent": "data-pipeline-engineer", "reason": "Merged into backend scope"},
    {"agent": "devops-engineer", "reason": "Deferred to implementation phase"},
    {"agent": "performance-engineer", "reason": "Merged into backend scope"},
]

Write(".claude/chain/00-topic-analysis.json", {
    "agents_selected": selected,
    "agents_excluded": excluded,
    "agent_count": len(selected),
    "cap_applied": True
})

for agent in selected:
    TaskCreate(subject=f"{agent}: brainstorm e-commerce architecture")
```

## Exceptions

- If the user explicitly requests more agents ("use all available agents"), allow up to 7 with a warning about token cost and synthesis quality
- Agent Teams mode has a stricter effective limit of 4-5 due to higher per-agent token cost from cross-agent communication


### Flag ideas that exceed current team or infrastructure capacity using tier-based complexity ceilings — HIGH


# Complexity Ceiling

Every brainstorm idea must be checked against the project's detected tier (Step 0) to ensure it does not exceed the team's capacity. Ideas that exceed the complexity ceiling must be flagged before reaching synthesis.

## Problem

Brainstorm agents optimize for technical elegance, not team reality. Without a complexity ceiling, a Tier 2 hackathon project receives recommendations for event-driven microservices, and a Tier 3 MVP gets suggestions requiring dedicated SRE. The user implements the recommendation, then fails because they lack the operational capacity.

## Tier Complexity Ceilings

| Tier | Max Complexity | Forbidden Patterns |
|------|---------------|-------------------|
| 1. Interview | Level 2 | No abstractions beyond simple modules |
| 2. Hackathon | Level 2 | No CI/CD, no Docker, no external services |
| 3. MVP | Level 3 | No K8s, no CQRS, no custom orchestration |
| 4. Growth | Level 4 | No multi-region, no custom service mesh |
| 5. Enterprise | Level 5 | Full range available |
| 6. Open Source | Level 3 | No infrastructure assumptions |

These ceilings align with the `scope-appropriate-architecture` skill and `assess` skill complexity scoring (Level 1-5).

## Rules

- Detect project tier in Step 0 before generating ideas
- During Phase 3 feasibility check, compare each idea's complexity level against the tier ceiling
- Ideas exceeding the ceiling get `"exceeds_ceiling": true` with a `"ceiling_reason"` field
- If ALL generated ideas exceed the ceiling, generate simpler alternatives before proceeding
- Never present a ceiling-exceeding idea as the top recommendation

**Incorrect -- recommending enterprise patterns for a hackathon:**
```python
# Tier 2 hackathon, but agents suggest enterprise architecture
TaskCreate(
    subject="Brainstorm: API for todo app",
    description="Explore CQRS + event sourcing + saga pattern for todo CRUD"
)
# Agent recommends:
# - Event-driven microservices (Level 5)
# - Saga orchestration (Level 5)
# - Custom API gateway (Level 4)
# User cannot implement any of these in a hackathon
```

**Correct -- constraining recommendations to tier ceiling:**
```python
# Tier 2 hackathon detected, ceiling = Level 2
ideas_with_ceiling = []
for idea in raw_ideas:
    complexity = assess_complexity(idea)  # Uses assess skill scoring
    exceeds = complexity.level > TIER_CEILINGS[detected_tier]
    ideas_with_ceiling.append({
        **idea,
        "complexity_level": complexity.level,
        "exceeds_ceiling": exceeds,
        "ceiling_reason": f"Level {complexity.level} exceeds Tier {detected_tier} "
                          f"ceiling of Level {TIER_CEILINGS[detected_tier]}"
                          if exceeds else None
    })

# Filter for synthesis: only ideas within ceiling
viable = [i for i in ideas_with_ceiling if not i["exceeds_ceiling"]]
if not viable:
    # Generate simpler alternatives before proceeding
    TaskCreate(subject="Generate simpler alternatives within Level 2 ceiling")
```

## When to Override

The user can explicitly override the ceiling by saying things like "I want enterprise-grade" or "ignore the project tier." When overriding:
1. Acknowledge the override in the handoff file
2. Warn about operational requirements the higher complexity demands
3. Include a "Simplified alternative" alongside each ceiling-exceeding recommendation


### Brainstorm must converge to actionable recommendations with clear next steps, not just list ideas — HIGH


# Convergence Requirement

Every brainstorm session must converge from divergent idea generation to a concrete set of actionable recommendations. The final output must include ranked options, a trade-off table, and explicit next steps. A brainstorm that ends with just a list of ideas is a failed brainstorm.

## Problem

The divergent phase (Phase 2) is designed to generate 10+ ideas without filtering. Without a strict convergence requirement, the skill can exhaust its context budget during ideation and never reach synthesis. The user receives a wall of possibilities with no guidance on which to pursue, how they compare, or what to do next.

## Convergence Checkpoints

| Phase | Convergence Gate | Action if Failed |
|-------|-----------------|------------------|
| Phase 2 -> 3 | Ideas generated (>= 5) | Stop generating, proceed with what exists |
| Phase 3 -> 4 | Feasible ideas filtered (<= 8) | Tighten feasibility criteria |
| Phase 4 -> 5 | Ideas rated and ranked | Skip devil's advocate, proceed to synthesis |
| Phase 5 -> 6 | Top 2-3 approaches selected | Force-rank by highest dimension scores |
| Phase 6 (final) | Actionable output delivered | Must include next steps table |

## Required Final Output Structure

The Phase 6 design presentation must include all of these sections:

1. **Recommended approach** -- single top pick with justification
2. **Runner-up(s)** -- 1-2 alternatives with trade-off comparison
3. **Trade-off table** -- dimensions (cost, complexity, testability, time-to-ship, scalability, maintainability)
4. **Next steps** -- concrete actions to begin implementation
5. **Considered but excluded** -- ideas that were explored and why they were dropped

## Rules

- Phase 2 has a hard cap: stop after 15 ideas regardless of agent output
- Each phase transition must produce a handoff file before proceeding
- If context is running low (> 70% consumed), skip remaining phases and synthesize from available data
- The final output must ALWAYS include a "Next steps" section with actionable items
- Never end a brainstorm with "Here are some ideas to consider" without ranking and recommending

**Incorrect -- ending with an unranked idea list:**
```python
# Phase 6 output: just a list, no convergence
TaskUpdate(subject="Brainstorm: caching strategy", status="completed")
# Output to user:
"""
## Ideas Generated
1. Redis caching with TTL
2. CDN edge caching
3. Application-level memoization
4. Database query caching
5. GraphQL persisted queries
6. Service worker caching
7. Varnish reverse proxy

Let me know which approach interests you!
"""
# User has 7 options, no ranking, no trade-offs, no next steps
```

**Correct -- converged to actionable recommendations:**
```python
# Phase 6 output: ranked, compared, actionable
Write(".claude/chain/05-synthesis.json", {
    "recommended": "Redis caching with TTL",
    "runner_ups": ["Application-level memoization"],
    "excluded": ["Varnish reverse proxy", "CDN edge caching",
                 "Service worker caching", "GraphQL persisted queries",
                 "Database query caching"],
    "next_steps": [
        "Add redis dependency to docker-compose.yml",
        "Implement cache-aside pattern in UserService",
        "Add cache invalidation on write paths",
        "Write integration test with testcontainers Redis"
    ]
})
# Output includes: Recommendation + trade-off table + Next Steps + Excluded
# User gets a single recommended approach, a runner-up with dimension
# comparison, concrete implementation steps, and rationale for exclusions
```


### Each idea must have a feasibility score (1-5) before synthesis; flag unfeasible ideas explicitly — HIGH


# Feasibility Filter

Every idea generated in Phase 2 (Divergent Exploration) must receive a feasibility score (1-5) during Phase 3 (Feasibility Fast-Check) before advancing to synthesis. Ideas scoring 1-2 must be explicitly flagged as low-feasibility rather than silently dropped or presented alongside viable options.

## Problem

When brainstorm agents generate 10+ ideas but skip feasibility scoring, the evaluation phase (Phase 4) wastes context rating ideas that were never buildable. Worse, unfeasible ideas can survive to the final presentation, undermining trust in the brainstorm output.

## Feasibility Scale

| Score | Label | Meaning |
|-------|-------|---------|
| 5 | Ready | Can implement with current stack and team |
| 4 | Likely | Minor unknowns, resolvable with a spike |
| 3 | Possible | Requires new dependency or skill acquisition |
| 2 | Stretch | Significant unknowns, timeline risk > 50% |
| 1 | Impractical | Blocked by hard constraints (budget, infra, time) |

## Rules

- Every idea in `03-feasibility.json` must include a `feasibility_score` field (1-5)
- Ideas scoring 1-2 are kept in the output but marked `"flagged": true` with a `reason` field
- Flagged ideas must NOT appear in the top recommendations unless the user explicitly asks for moonshots
- The feasibility check must consider the detected project tier from Step 0

**Incorrect -- presenting ideas without feasibility scores:**
```python
# Phase 3 output: no scoring, all ideas pass through
Write(".claude/chain/03-feasibility.json", {
    "ideas": [
        {"title": "Build custom ML pipeline", "description": "..."},
        {"title": "Add caching layer", "description": "..."},
        {"title": "Rewrite in Rust", "description": "..."}
    ]
})
# Phase 5 wastes tokens evaluating "Rewrite in Rust" for a Tier 2 hackathon
```

**Correct -- every idea scored, unfeasible ones flagged:**
```python
# Phase 3 output: each idea scored, low-feasibility flagged with reason
Write(".claude/chain/03-feasibility.json", {
    "tier": 2,
    "ideas": [
        {"title": "Add caching layer", "feasibility_score": 5,
         "flagged": False},
        {"title": "Build custom ML pipeline", "feasibility_score": 2,
         "flagged": True, "reason": "Requires GPU infra not available at Tier 2"},
        {"title": "Rewrite in Rust", "feasibility_score": 1,
         "flagged": True, "reason": "Complete rewrite exceeds project scope and timeline"}
    ],
    "viable_count": 1,
    "flagged_count": 2
})
# Phase 4 focuses evaluation on viable ideas; flagged ideas shown separately
```

## Integration with Phase Workflow

- Phase 2 generates ideas freely (no filtering)
- Phase 3 applies this feasibility filter -- every idea gets a score
- Phase 4 evaluates only ideas with `feasibility_score >= 3` in detail
- Phase 5 synthesis references flagged ideas in a "Considered but excluded" section