Announce: "I'm using the brainstorming skill to refine your idea into a design."

Check current state:

• Recent commits, existing docs, codebase structure
• Dispatch hyperpowers:codebase-investigator for existing patterns
• Dispatch hyperpowers:internet-researcher for external APIs/libraries

REQUIRED: Use AskUserQuestion tool for all questions

• One question at a time (don't batch multiple questions)
• Prefer multiple choice options (easier to answer)
• Wait for response before asking next question
• Focus on: purpose, constraints, success criteria
• Gather enough context to propose approaches

Do NOT just print questions and wait for "yes" - use the AskUserQuestion tool.

Example questions:

• "What problem does this solve for users?"
• "Are there existing implementations we should follow?"
• "What's the most important success criterion?"
• "Token storage: cookies, localStorage, or sessionStorage?"

2. Exploring Approaches

Research first:

• Similar feature exists → dispatch codebase-investigator
• New integration → dispatch internet-researcher
• Review findings before proposing

IMPORTANT: Capture research findings for Design Rationale As you research, note down:

• Codebase findings: file paths, patterns discovered, relevant code
• External findings: API capabilities, library constraints, doc URLs
• These will populate the "Research Findings" section of the epic

Propose 2-3 approaches with trade-offs:

Based on [research findings], I recommend:

1. **[Approach A]** (recommended)
   - Pros: [benefits, especially "matches existing pattern"]
   - Cons: [drawbacks]

2. **[Approach B]**
   - Pros: [benefits]
   - Cons: [drawbacks]

3. **[Approach C]**
   - Pros: [benefits]
   - Cons: [drawbacks]

I recommend option 1 because [specific reason, especially codebase consistency].

Lead with recommended option and explain why.

3. Presenting the Design

Once approach is chosen, present design in sections:

• Break into 200-300 word chunks
• Ask after each: "Does this look right so far?"
• Cover: architecture, components, data flow, error handling, testing
• Be ready to go back and clarify

Show research findings:

• "Based on codebase investigation: auth/ uses passport.js..."
• "API docs show OAuth flow requires..."
• Demonstrate how design builds on existing code

4. Creating the bd Epic

After design validated, create epic as immutable contract:

bd create "Feature: [Feature Name]" \
  --type epic \
  --priority [0-4] \
  --design "## Requirements (IMMUTABLE)
[What MUST be true when complete - specific, testable]
- Requirement 1: [concrete requirement]
- Requirement 2: [concrete requirement]
- Requirement 3: [concrete requirement]

## Success Criteria (MUST ALL BE TRUE)
- [ ] Criterion 1 (objective, testable - e.g., 'Integration tests pass')
- [ ] Criterion 2 (objective, testable - e.g., 'Works with existing User model')
- [ ] All tests passing
- [ ] Pre-commit hooks passing

## Anti-Patterns (FORBIDDEN)
- ❌ [Pattern] ([reasoning] - e.g., 'NO localStorage tokens (security: httpOnly prevents XSS token theft)')
- ❌ [Pattern] ([reasoning] - e.g., 'NO mocking OAuth in integration tests (validation: defeats purpose)')

## Approach
[2-3 paragraph summary of chosen approach]

## Architecture
[Key components, data flow, integration points]

## Design Rationale
### Problem
[1-2 sentences: what problem this solves, why status quo insufficient]

### Research Findings
**Codebase:**
- [file.ts:line] - [what it does, why relevant]
- [pattern discovered, implications]

**External:**
- [API/library] - [key capability, constraint discovered]
- [doc URL] - [relevant guidance found]

### Approaches Considered
1. **[Chosen Approach]** ✓
   - Pros: [benefits]
   - Cons: [drawbacks]
   - **Chosen because:** [specific reasoning, especially codebase consistency]

2. **[Rejected Approach A]**
   - Pros: [benefits]
   - Cons: [drawbacks]
   - **Rejected because:** [specific reasoning]

3. **[Rejected Approach B]** (if applicable)
   - Pros: [benefits]
   - Cons: [drawbacks]
   - **Rejected because:** [specific reasoning]

### Scope Boundaries
**In scope:**
- [explicit inclusions]

**Out of scope (deferred/never):**
- [explicit exclusions with reasoning]

### Open Questions
- [uncertainties to resolve during implementation]
- [decisions deferred to execution phase]"

Critical: Anti-patterns section prevents watering down requirements when blockers occur. Always include reasoning.

Example anti-patterns:

• ❌ NO localStorage tokens (security: httpOnly prevents XSS token theft)
• ❌ NO new user model (consistency: must integrate with existing db/models/user.ts)
• ❌ NO mocking OAuth in integration tests (validation: defeats purpose of testing real flow)
• ❌ NO TODO stubs for core authentication flow (completeness: core flow must be implemented)

5. Creating ONLY First Task

Create one task, not full tree:

bd create "Task 1: [Specific Deliverable]" \
  --type feature \
  --priority [match-epic] \
  --design "## Goal
[What this task delivers - one clear outcome]

## Implementation
[Detailed step-by-step for this task]

1. Study existing code
   [Point to 2-3 similar implementations: file.ts:line]

2. Write tests first (TDD)
   [Specific test cases for this task]

3. Implementation checklist
   - [ ] file.ts:line - function_name() - [exactly what it does]
   - [ ] test.ts:line - test_name() - [what scenario it tests]

## Success Criteria
- [ ] [Specific, measurable outcome]
- [ ] Tests passing
- [ ] Pre-commit hooks passing"

bd dep add bd-2 bd-1 --type parent-child  # Link to epic

Why only one task?

• Subsequent tasks created iteratively by executing-plans
• Each task reflects learnings from previous
• Avoids brittle task trees that break when assumptions change

6. SRE Refinement and Handoff

After epic and first task created:

REQUIRED: Run SRE refinement before handoff

Use Skill tool: hyperpowers:sre-task-refinement

SRE refinement will:

• Apply 7-category corner-case analysis (Opus 4.1)
• Strengthen success criteria
• Identify edge cases and failure modes
• Ensure task is ready for implementation

Do NOT skip SRE refinement. The first task sets the pattern for the entire epic.

After refinement approved, present handoff:

"Epic bd-1 is ready with immutable requirements and success criteria.
First task bd-2 has been refined and is ready to execute.

Ready to start implementation? I'll use executing-plans to work through this iteratively.

The executing-plans skill will:
1. Execute the current task
2. Review what was learned against epic requirements
3. Create next task based on current reality
4. Run SRE refinement on new tasks
5. Repeat until all epic success criteria met

This approach avoids brittle upfront planning - each task adapts to what we learn."