brainstorming

name	brainstorming
description	Structured ideation skill for the planner agent. Explores alternative architectures, surfaces tradeoffs, and identifies constraints before committing to a decomposition. Invoked in standard/prod tiers; skipped in fast tier.

Brainstorming

Your job: before the planner commits to an architecture, systematically explore the solution space. You produce a Brainstorm Summary block that gets embedded in PLAN.md between the Overview and Architecture Decisions sections.

This skill is invoked by the planner agent in standard and prod tiers. Fast tier skips it entirely.

When to Invoke

The planner invokes this skill after Step 2 (Research the Codebase) and before architecture decisions are finalized. The planner passes you:

• The restated task objective
• The codebase research findings (project structure, conventions, existing patterns)
• Any constraints from the user or orchestrator

The Brainstorming Process

Phase 1: Generate Alternatives (diverge)

Produce at least 3 distinct approaches to the task. Each alternative must be structurally different, not a minor variation. For each alternative, state:

• Name: a short label (e.g. "Monolithic service", "Event-driven pipeline", "Thin adapter layer")
• Description: 2-3 sentences on how it works
• Fits well when: conditions under which this approach shines
• Breaks down when: conditions under which this approach fails

If fewer than 3 meaningful alternatives exist, explain why and proceed with what you have.

Phase 2: Surface Tradeoffs (compare)

Build a tradeoff matrix across the alternatives. Dimensions to consider (pick the relevant ones):

• Complexity (implementation effort, cognitive load)
• Testability (how easy to write deterministic tests)
• Extensibility (how well it handles future changes)
• Performance (latency, memory, throughput)
• Consistency (does it follow existing codebase patterns)
• Risk (what can go wrong, blast radius)

Don't force-fit every dimension. If performance is irrelevant to the task, skip it.

Phase 3: Identify Constraints (narrow)

List hard constraints that eliminate alternatives or force specific choices:

• Codebase constraints: existing patterns that must be followed, types that must be extended
• User constraints: explicit requirements from the task description
• Technical constraints: language/framework limitations, dependency restrictions
• Temporal constraints: deadlines, migration windows, backward compatibility

Each constraint must reference its source (user request, codebase convention, framework limitation).

Phase 4: Recommend (converge)

State the recommended approach with a one-paragraph rationale. Reference which constraints drove the decision and which tradeoffs were accepted.

If two approaches are genuinely equal, say so and flag it as a question for the user.

Output Format

The brainstorming output is a markdown block that the planner embeds in PLAN.md:

## Brainstorm Summary

### Alternatives Considered

**1. [Name]**
[Description]
- Fits well when: [conditions]
- Breaks down when: [conditions]

**2. [Name]**
[Description]
- Fits well when: [conditions]
- Breaks down when: [conditions]

**3. [Name]**
[Description]
- Fits well when: [conditions]
- Breaks down when: [conditions]

### Tradeoffs

| Dimension     | Alternative 1 | Alternative 2 | Alternative 3 |
|---------------|---------------|---------------|---------------|
| [Dimension]   | [assessment]  | [assessment]  | [assessment]  |
| ...           | ...           | ...           | ...           |

### Constraints

- **[Source]**: [constraint description] — eliminates [Alternative N] / forces [choice]
- ...

### Recommended Approach

[Name]: [one-paragraph rationale referencing constraints and accepted tradeoffs]

Anti-patterns

• Rubber-stamping the obvious choice: if the first approach that comes to mind is clearly right, at least articulate WHY by generating alternatives that fail. The alternatives-that-don't-work ARE the rationale.
• Analysis paralysis: 3-5 alternatives is the sweet spot. If you're generating 10+, you're slicing too thin.
• Vague tradeoffs: "more complex" is not a tradeoff. "Requires adding a new abstraction layer with ~3 interfaces" is.
• Ignoring codebase conventions: the best architecture in a vacuum is the wrong one if the codebase does things differently. Consistency is a valid reason to pick a suboptimal pattern.
• Skipping constraints: constraints are what make the brainstorm actionable. Without them, you're just listing options.