/project-brainstorming

name: project-brainstorming
description: Guides project ideation via Socratic questioning to produce a validated brief. Use before specification when requirements are unclear.
alwaysApply: false
# Custom metadata (not used by Claude for matching):
category: workflow
tags: [brainstorming, ideation, planning, requirements, socratic-method]
complexity: intermediate
estimated_tokens: 2800
progressive_loading: true
dependencies:
  modules:
    - modules/spec-review-loop.md
    - modules/deferred-capture.md
role: library

When To Use

• Starting a new project without clear requirements
• Exploring problem space before specification
• Need to compare multiple approaches systematically
• Validating project feasibility and scope
• Documenting decision rationale for stakeholders
• Need to clarify the core problem being solved

When NOT To Use

• Requirements and specification already exist (use `Skill(attune:project-planning)` instead)
• Refining existing specs (use `Skill(attune:project-specification)` instead)
• Project scope is well-defined (jump to `/attune:project-init`)
• Mid-project pivots (use `Skill(attune:war-room)` for strategic decisions)

Integration

**With superpowers**:

• Delegates to `Skill(superpowers:brainstorming)` for Socratic method
• Augments with project-specific patterns
• Uses project brainstorm templates

**Without superpowers**:

• Standalone questioning framework
• Project-focused ideation patterns
• Structured output templates

**War Room Integration (REQUIRED)**:

• After Phase 3 (Approach Generation), automatically invokes `Skill(attune:war-room)`
• All brainstorming context passed to War Room for expert deliberation
• War Room provides multi-LLM pressure testing and synthesis
• Only bypassed for Type 2 decisions (RS ≤ 0.40) with explicit user confirmation

Brainstorming Framework

Phase 1: Problem Definition

**Socratic Questions**: 1. What problem are you solving? 2. Who experiences this problem? 3. What makes this problem worth solving now? 4. What happens if this problem isn't solved? 5. What existing solutions have been tried? 6. Who reads what this project produces, and what do they already know? Name a role specific enough to point at someone who holds it.

Question 6 sets the audience tier that every document this project generates inherits: `newcomer`, `practitioner`, `expert`, or a one-line `persona`. Ask it here rather than at drafting time, where the answer gets guessed to keep the draft moving. Tier table and follow-up questions: `scribe:slop-detector` module `audience-targeting.md`.

**Output**: Problem statement in docs/project-brief.md

**Template**:

## Problem Statement

**Who**: [Target users/stakeholders]
**What**: [The problem they face]
**Where**: [Context where problem occurs]
**When**: [Frequency/timing of problem]
**Why**: [Impact of the problem]
**Current State**: [Existing solutions and limitations]
**Doc audience**: [newcomer | practitioner | expert | persona: <one line>]

**Verification:** Run the command with `--help` flag to verify availability.

Phase 2: Constraint Discovery

**Questions**: 1. What are non-negotiable technical constraints? 2. What are resource constraints (time, budget, team)? 3. What integration points are required? 4. What compliance/regulatory requirements apply? 5. What are success criteria and failure modes?

**Output**: Constraints matrix

**Template**:

## Constraints

### Technical
- [Constraint 1 with rationale]
- [Constraint 2 with rationale]

### Resources
- **Timeline**: [Duration with milestones]
- **Team**: [Size and skills]
- **Budget**: [If applicable]

### Integration
- [Required system 1]
- [Required system 2]

### Compliance
- [Requirement 1]
- [Requirement 2]

### Success Criteria
- [ ] [Measurable criterion 1]
- [ ] [Measurable criterion 2]

**Verification:** Run the command with `--help` flag to verify availability.

Phase 3: Approach Generation

**Technique**: Generate 3-5 distinct approaches

**For each approach**:

• Clear description (1-2 sentences)
• Technology stack
• Pros (3-5 points)
• Cons (3-5 points)
• Risks (2-3 points)
• Estimated effort
• Trade-offs

**Template**:

## Approach [N]: [Name]

**Description**: [Clear 1-2 sentence description]

**Stack**: [Technologies and tools]

**Pros**:
- [Advantage 1]
- [Advantage 2]
- [Advantage 3]

**Cons**:
- [Disadvantage 1]
- [Disadvantage 2]
- [Disadvantage 3]

**Risks**:
- [Risk 1 with likelihood]
- [Risk 2 with likelihood]

**Effort**: [S/M/L/XL or time estimate]

**Trade-offs**:
- [Trade-off 1 with mitigation]
- [Trade-off 2 with mitigation]

**Verification:** Run the command with `--help` flag to verify availability.

**Design for Isolation**:

When generating approaches, evaluate each against two isolation tests:

1. **Comprehension test**: Can someone understand what each unit does without reading its internals? If a unit requires reading implementation details to understand its purpose, the boundary is wrong. 2. **Change test**: Can you change a unit's internals without breaking its consumers? If changing implementation details forces changes elsewhere, the interface is leaking.

**File size as design signal**: Files exceeding 500 lines (Python/Go) or 300 lines (JavaScript/TypeScript) often indicate a unit is doing too much. This is a design smell, not just a style issue. When flagging large files, suggest extracting specific concerns (e.g., "Extract validation logic into a separate module to improve testability").

**Verification:** Run the command with `--help` flag to verify availability.

Phase 3.5: War Room Deliberation (REQUIRED)

**Automatic Trigger**: After generating approaches, MUST invoke `Skill(attune:war-room)` for expert deliberation

**When War Room is invoked**:

• All brainstorming context (problem, constraints, approaches) automatically passed to War Room
• Expert panel reviews, challenges, and pressures each approach
• Re