Brainstorm

Based on the answers and codebase research, present 2-3 approaches. For each:

• What it looks like — concrete enough to evaluate, not abstract handwaving
• What it touches — which parts of the codebase, which services, what data
• What it costs — complexity, migration risk, maintenance burden
• What it enables — future options this opens or closes

Reference existing patterns from kb/ if /explore has been run. If an approach aligns with or violates existing conventions in the codebase, say so.

Don't advocate for one approach. Present them neutrally and ask which direction resonates.

Phase 3: Converge

Once the user signals a direction, push on the edges:

• What's out of scope? Help define non-goals explicitly.
• What's the smallest useful version? Find the MVP cut.
• What are the open questions? Things that need answers but don't block starting the spec.
• What's the sequencing? Can this be shipped incrementally?

Phase 4: Write the spec draft

Create the file at specs/<slug>.md (create the specs/ directory if needed) and write the draft:

# <Title>

**Date**: <today>
**Status**: Draft

## Problem

[From Phase 1 — the actual problem, grounded in what exists today]

## Goals

[Numbered list of what this achieves]

## Non-Goals

[Explicit scope boundaries from Phase 3]

## Data Model

[If this introduces or modifies data models, define them explicitly here. Field names, types, relationships, constraints, migration considerations. This is the most critical section — models are where AI agents make the worst decisions without human guidance.]

## Changes

[Concrete changes from the chosen approach in Phase 2. For each change: what it is, where it goes, what it affects. Reference specific files/modules from the codebase.]

## Sequencing

[How to ship this incrementally, from Phase 3]

## Open Questions

[Unresolved items from Phase 3 that /enrich-spec should investigate]

Tell the user the file path and suggest running /enrich-spec <path> as the next step.

How this works in practice

• Phases 1-3 are conversational — back and forth with the user.
• Phase 4 is a single write once the conversation converges.
• The whole thing might take 10-20 minutes of discussion.
• If the idea is too vague to even start Phase 2, stay in Phase 1 longer. Don't force it.
• If the idea is already well-formed, skip quickly through Phase 1 and get to approaches.

What NOT to do

• Don't write the spec without the conversation. The exploration IS the value.
• Don't present 5+ approaches. 2-3 is the sweet spot.
• Don't research the codebase in silence and then present a wall of findings. Interleave research with questions.
• Don't skip non-goals. Every spec needs them.
• Don't skip the data model section. If the feature involves data, the schema must be defined here.