✨ Add active initialization, roadmap management, reference repos

Initialization now follows sequenced discovery:
- Vision doc first, roadmap last
- Active interviewing with assumption challenges
- Clone open source repos to ../reference/ for analysis

Roadmap section: AI-first framing where sequencing for usability
matters more than effort prioritization. Now-Next-Later format.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

Author: Nick Sullivan

.claude/commands/knowledge.md

@@ -122,6 +122,7 @@ Starting layout:
 - knowledge/product/ - Core identity: vision.md, personas.md, boundaries.md
 - knowledge/components/ - Feature-level: one file per capability
 - knowledge/competitors/ - One file per competitor
+- knowledge/roadmap.md - Milestones and sequencing
 
 This structure evolves. You have full autonomy to reorganize. Split files that grow too
 large. Create new folders when patterns emerge (integrations/, market/, experiments/).
@@ -136,18 +137,72 @@ in a decisions folder.
 </knowledge-structure>
 
 <initialization>
-When knowledge/ doesn't exist, build it through conversation.
+When knowledge/ doesn't exist, build it through active discovery. You interview the
+human, challenge assumptions, and extract understanding. This is not a form to fill out.
 
 If context/ exists, ask whether to use it as reference.
 
-Have a dialogue to understand the product. Ask about: What is this? Why does it exist?
-Who is it for and what do they need? What does it NOT do? What are the main
-capabilities? Who competes with it? What have you learned so far?
+Follow this sequence - each phase builds on the previous:
 
-Dig into rationale. Ask follow-ups. Build files as understanding develops - don't wait
-until the end. The goal is true understanding, not completed templates.
+Phase 1 - Vision document first: Start by creating knowledge/product/vision.md. Ask:
+What is this product? What problem does it solve? Why does this need to exist - what's
+broken today? Why will you win? Extract the core idea before expanding.
+
+Phase 2 - Understand the user: Create knowledge/product/personas.md. Ask: Who
+specifically is this for? What's their situation? What do they need that they can't get
+today? Challenge vague answers - "small businesses" isn't specific enough. Push for
+concrete examples of real people.
+
+Phase 3 - Define boundaries: Create knowledge/product/boundaries.md. Ask: What is this
+NOT? What will you refuse to build even if users ask? What's explicitly out of scope?
+Boundaries are as important as features.
+
+Phase 4 - Map the landscape: Create knowledge/competitors/. Ask: Who else is solving
+this problem? What do they do well? Where do they fall short? If relevant open source
+projects exist, suggest cloning them to ../reference/ for detailed analysis.
+
+Phase 5 - Define capabilities: Create knowledge/components/. For each major capability,
+ask: What does this do? Why is it needed? What are the key decisions? Build one file per
+significant feature or module.
+
+Phase 6 - Build the roadmap last: Only after features are defined, create
+knowledge/roadmap.md. Ask: What's the sequence for usability? What needs to exist before
+other things make sense? What milestones mark progress?
+
+Throughout: Challenge assumptions. Ask "why?" repeatedly. Push back on vague answers.
+Build files as understanding develops. The goal is true understanding, not completed
+templates.
 </initialization>
 
+<roadmap>
+You maintain the product roadmap at knowledge/roadmap.md.
+
+In an AI-first world, roadmaps are less about prioritizing scarce engineering time and
+more about sequencing for usability. Code is cheap. The question isn't "what can we
+afford to build?" but "what's the logical sequence for a coherent product?"
+
+Structure roadmaps around milestones, not features:
+- What needs to exist before this is usable for persona X?
+- What milestone marks "we can test hypothesis Y"?
+- What's the sequence that builds coherent functionality?
+
+Use Now-Next-Later over rigid timelines. Now is well-defined and in progress. Next is
+clear but not started. Later is directional but flexible.
+
+Roadmaps are living documents. As signals come in - user feedback, competitive moves,
+technical learnings - update the roadmap. New information changes sequencing.
+
+When updating the roadmap, think about dependencies and coherence. A feature that
+depends on another should come after. A capability that unlocks testing should come
+early.
+</roadmap>
+
+<reference-repos>
+When researching competitors or exploring approaches, look for relevant open source
+implementations. Clone useful repos to ../reference/ for detailed analysis. Walking
+through actual code provides deeper understanding than reading documentation.
+</reference-repos>
+
 <what-this-is-not>
 Not documentation - documentation is generated from this
 Not a filing system - you think and judge, not just organize