project-brainstorming

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?

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]

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.

1. 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
• Reversibility assessment conducted
• Multi-LLM deliberation identifies blind spots
• Supreme Commander provides synthesis with rationale

Command:

# Automatically invoked from brainstorm - DO NOT SKIP
/attune:war-room --from-brainstorm

War Room Output:

• Reversibility Score (RS) and decision type
• Red Team challenges for each approach
• Premortem analysis on selected approach
• Supreme Commander Decision document
• Implementation orders and watch points

Bypass Conditions (ONLY skip war room if ALL true):

• [ ] RS ≤ 0.40 (Type 2 decision - clearly reversible)
• [ ] Single obvious approach with no meaningful trade-offs
• [ ] Low complexity with well-documented pattern
• [ ] User explicitly declines after being shown RS assessment

Proceed to Phase 4 only after War Room completes

Phase 4: Approach Comparison

Comparison Matrix:

| Criterion | Approach 1 | Approach 2 | Approach 3 | Approach 4 | |-----------|------------|------------|------------|------------| | Technical Fit | 🟢 High | 🟡 Medium | 🟡 Medium | 🔴 Low | | Resource Efficiency | 🟡 Medium | 🟢 High | 🔴 Low | 🟡 Medium | | Time to Value | 🟢 Fast | 🟡 Medium | 🔴 Slow | 🟢 Fast | | Risk Level | 🟡 Medium | 🟢 Low | 🔴 High | 🟡 Medium | | Maintainability | 🟢 High | 🟡 Medium | 🟢 High | 🔴 Low |

Scoring: 🟢 = Good, 🟡 = Acceptable, 🔴 = Concern

Phase 5: Decision & Rationale

Selection Criteria:

1. Alignment with constraints (must satisfy all)
2. Risk vs. reward balance
3. Team capability and experience
4. Time to value
5. Long-term maintainability

Template:

## Selected Approach: [Approach Name] ⭐

### Rationale
[2-3 paragraphs explaining why this approach was selected]

Key decision factors:
- [Factor 1]
- [Factor 2]
- [Factor 3]

### Trade-offs Accepted
- **Trade-off 1**: [Description] → Mitigation: [Strategy]
- **Trade-off 2**: [Description] → Mitigation: [Strategy]

### Rejected Approaches
- **Approach X**: Rejected because [reason]
- **Approach Y**: Rejected because [reason]

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

Output: Project Brief

Final output saved to docs/project-brief.md:

# [Project Name] - Project Brief

**Date**: [YYYY-MM-DD]
**Author**: [Name]
**Status**: Draft | Approved

## Problem Statement
[From Phase 1]

## Goals
1. [Primary goal]
2. [Secondary goal]
3. [Tertiary goal]

## Constraints
[From Phase 2]

## Approach Comparison
[From Phase 3 & 4]

## War Room Decision
[From Phase 3.5 - includes RS assessment, Red Team challenges, premortem]

## Selected Approach
[From Phase 5, informed by War Room synthesis]

## Next Steps
1. `/attune:specify` - Create detailed specification
2. `/attune:blueprint` - Plan architecture and tasks
3. `/attune:project-init` - Initialize project structure

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

Questioning Patterns

Socratic Method

Clarification:

• "What do you mean by [term]?"
• "Can you give an example?"
• "What is the difference between X and