name: build description: Feature development pipeline - research, plan, track, and implement major features. argument-hint: [subcommand] [name] metadata: author: Shpigford version: "1.0"

• research [name]

  → Run the Research phase

• implementation [name]

  → Run the Implementation phase

• progress [name]

  → Run the Progress phase

• phase [n] [name]

  → Run Phase n of the implementation

• status [name]

  → Show current status and suggest next step
• (empty or unrecognized) → Show usage help

/build - Feature Development Pipeline

Subcommands:
  /build research [name]        Deep research on a feature idea
  /build implementation [name]  Create phased implementation plan
  /build progress [name]        Set up progress tracking
  /build phase [n] [name]       Execute implementation phase n
  /build status [name]          Show status and next steps

Example workflow:
  /build research chat-interface
  /build implementation chat-interface
  /build progress chat-interface
  /build phase 1 chat-interface

• question: "What would you like to do?"
• header: "Action"
• multiSelect: false
• options:
  • label: "Start new feature research" description: "Begin deep research on a new feature idea"
  • label: "Continue existing feature" description: "Work on a feature already in progress"
  • label: "Check status" description: "See what step to do next for a feature"

• question: "What's a short identifier for this feature? (lowercase, hyphens ok - e.g., 'chat-interface', 'user-auth', 'data-export'). Use 'Other' to type it."
• header: "Feature name"
• multiSelect: false
• options:
  • label: "I'll type the name" description: "Enter a short, kebab-case identifier for the feature"

docs/{name}/RESEARCH.md

• question: "A RESEARCH.md already exists for this feature. What would you like to do?"
• header: "Existing doc"
• multiSelect: false
• options:
  • label: "Overwrite" description: "Replace existing research with fresh exploration"
  • label: "Append" description: "Add new research below existing content"
  • label: "Skip" description: "Keep existing research, suggest next step"

/build implementation {name}

• question: "Describe the feature you want to build. What problem does it solve? What should it do? (Use 'Other' to describe)"
• header: "Description"
• multiSelect: false
• options:
  • label: "I'll describe it" description: "Provide a detailed description of the feature"

• question: "What aspects should the research focus on?"
• header: "Focus areas"
• multiSelect: true
• options:
  • label: "Technical implementation" description: "APIs, libraries, architecture patterns"
  • label: "UI/UX design" description: "Interface design, user flows, interactions"
  • label: "Data requirements" description: "What data to store, schemas, privacy"
  • label: "Platform capabilities" description: "OS APIs, system integrations, permissions"

1. Codebase exploration: Understand existing patterns, similar features, relevant code
2. Web search: Research best practices, similar implementations, relevant APIs
3. Technical deep-dive: Explore specific technologies, libraries, frameworks
4. Use AskUserQuestion FREQUENTLY: Validate assumptions, clarify requirements, get input on decisions

• Problem definition and user needs
• Technical approaches and trade-offs
• Required data models and storage
• UI/UX considerations
• Integration points with existing code
• Potential challenges and risks
• Recommended approach with rationale

docs/{name}/RESEARCH.md

• Inform user: "No research document found at

  docs/{name}/RESEARCH.md

  "
• Suggest: "Run

  /build research {name}

  first to create the research document."
• Exit

docs/{name}/IMPLEMENTATION.md

• question: "An IMPLEMENTATION.md already exists. What would you like to do?"
• header: "Existing doc"
• multiSelect: false
• options:
  • label: "Overwrite" description: "Create a fresh implementation plan"
  • label: "Append" description: "Add new phases below existing content"
  • label: "Skip" description: "Keep existing plan, suggest next step"

/build progress {name}

docs/{name}/RESEARCH.md

• The recommended approach
• Technical requirements
• Data models needed
• UI/UX design
• Integration points

• Be independently valuable (deliver something usable)
• Be small enough to complete in a focused session
• Build on previous phases
• Have clear success criteria

• question: "How granular should the implementation phases be?"
• header: "Phase size"
• multiSelect: false
• options:
  • label: "Small phases (1-2 hours)" description: "Many focused phases, easier to track progress"
  • label: "Medium phases (half day)" description: "Balanced approach, moderate number of phases"
  • label: "Large phases (full day)" description: "Fewer phases, each delivering significant functionality"

• Web search for implementation specifics
• Review relevant code in the codebase
• Identify dependencies between phases

• Task 1
• Task 2
• Task 3

• Documentation updates
• Testing strategy
• Performance validation

docs/{name}/IMPLEMENTATION.md

• Inform user: "No implementation document found at

  docs/{name}/IMPLEMENTATION.md

  "
• Suggest: "Run

  /build implementation {name}

  first."
• Exit

docs/{name}/PROGRESS.md

• question: "A PROGRESS.md already exists. What would you like to do?"
• header: "Existing doc"
• multiSelect: false
• options:
  • label: "Overwrite" description: "Start fresh progress tracking"
  • label: "Keep existing" description: "Keep current progress, suggest next step"

docs/{name}/IMPLEMENTATION.md

• All phase titles
• Tasks within each phase
• Success criteria

• Research:

  docs/{name}/RESEARCH.md

• Implementation:

  docs/{name}/IMPLEMENTATION.md

• (none yet)

• (none yet)

• (none)

• Work completed
• Decisions made
• Notes for next session

• Phase number (if provided)
• Feature name (if provided)

• docs/{name}/RESEARCH.md

• docs/{name}/IMPLEMENTATION.md

• docs/{name}/PROGRESS.md

/build

docs/{name}/IMPLEMENTATION.md

• question: "Which phase would you like to work on?"
• header: "Phase"
• multiSelect: false
• options: [dynamically generated from phases found in IMPLEMENTATION.md, marking completed ones]

• The research and rationale (RESEARCH.md)
• The specific phase tasks and success criteria (IMPLEMENTATION.md)
• Current progress and decisions made (PROGRESS.md)

1. Web search for specific implementation details relevant to this phase
2. Codebase exploration for relevant existing code
3. Use AskUserQuestion to clarify any ambiguities about the phase requirements

1. Work through each task in the phase
2. Use AskUserQuestion frequently for implementation decisions
3. Follow the "Always Works" philosophy - test as you go
4. Document decisions in PROGRESS.md as you make them

docs/{name}/PROGRESS.md

• Mark tasks as completed
• Record decisions made and why
• Note any blockers encountered
• List files changed
• Add architectural decisions
• Update the session log with today's work

• "In Progress" when starting
• "Completed" when all tasks done and success criteria met

1. Read PROGRESS.md to determine next incomplete phase
2. Inform user of completion and suggest next action:

docs/{name}/PROGRESS.md

/build phase {n+1} {name}

• Running tests to verify everything works
• Updating documentation
• Creating a PR for review"

• docs/{name}/RESEARCH.md

• docs/{name}/IMPLEMENTATION.md

• docs/{name}/PROGRESS.md

• There's ambiguity in requirements
• Multiple approaches are possible
• You need to validate an assumption
• A decision will significantly impact the implementation
• You're unsure about scope or priority

• Multiple web searches on different aspects
• Thorough codebase exploration
• Reading relevant documentation
• Considering multiple approaches
• Understanding trade-offs

• Don't wait until the end to update
• Record decisions as they're made
• Note blockers immediately
• This creates valuable context for future sessions

• Each phase should have clear boundaries
• If new requirements emerge, note them for future phases
• Don't expand the current phase's scope mid-implementation
• Use AskUserQuestion to validate if something is in/out of scope

• Test changes as you make them
• Don't assume code works - verify it
• If something doesn't work, fix it before moving on
• The goal is working software, not just written code