[HINT] Download the complete skill directory including SKILL.md and all related files
| name | build |
| description | build |
| risk | unknown |
| source | community |
Feature development pipeline - research, plan, track, and implement major features.
research, implementation, progress, or phase.This command manages a 4-phase feature development workflow for building major features. Parse $ARGUMENTS to determine which subcommand to run.
Arguments provided: $ARGUMENTS
Parse the first word of $ARGUMENTS to determine the subcommand:
research [name] → Run the Research phaseimplementation [name] → Run the Implementation phaseprogress [name] → Run the Progress phasephase [n] [name] → Run Phase n of the implementationstatus [name] → Show current status and suggest next stepIf the feature name is not provided in arguments, you MUST use AskUserQuestion to prompt for it.
If no arguments provided, display this 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
Then use AskUserQuestion to ask what they'd like to do:
If feature name not in arguments, use AskUserQuestion:
Check if docs/{name}/RESEARCH.md already exists.
If it exists, use AskUserQuestion:
If "Skip" selected, suggest running /build implementation {name} and exit.
Use AskUserQuestion to understand the feature:
Use AskUserQuestion:
Now conduct DEEP research on the feature:
Research should cover:
Create the directory if needed: docs/{name}/
Write findings to docs/{name}/RESEARCH.md with this structure:
# {Feature Name} Research
## Overview
[Brief description of the feature and its purpose]
## Problem Statement
[What problem this solves, why it matters]
## User Stories / Use Cases
[Concrete examples of how users will use this]
## Technical Research
### Approach Options
[Different ways to implement this, with pros/cons]
### Recommended Approach
[The approach you recommend and why]
### Required Technologies
[APIs, libraries, frameworks needed]
### Data Requirements
[What data needs to be stored/tracked]
## UI/UX Considerations
[Interface design thoughts, user flows]
## Integration Points
[How this connects to existing code/features]
## Risks and Challenges
[Potential issues and mitigation strategies]
## Open Questions
[Things that still need to be decided]
## References
[Links to relevant documentation, examples, articles]
After writing the research doc, inform the user:
"Research complete! Document saved to docs/{name}/RESEARCH.md
Next step: Run /build implementation {name} to create a phased implementation plan."
If feature name not in arguments, use AskUserQuestion to prompt for it (same as research phase).
Check if docs/{name}/RESEARCH.md exists.
If it does NOT exist:
docs/{name}/RESEARCH.md"/build research {name} first to create the research document."Check if docs/{name}/IMPLEMENTATION.md already exists.
If it exists, use AskUserQuestion:
If "Skip" selected, suggest running /build progress {name} and exit.
Read docs/{name}/RESEARCH.md to understand:
Break the research into practical implementation phases. Each phase should:
Use AskUserQuestion to validate phase breakdown:
For each phase you're planning, do targeted research:
Use AskUserQuestion for any uncertainties about phase ordering or scope.
Write to docs/{name}/IMPLEMENTATION.md with this structure:
# {Feature Name} Implementation Plan
## Overview
[Brief recap of what we're building and the approach from research]
## Prerequisites
[What needs to be in place before starting]
## Phase Summary
[Quick overview of all phases]
---
## Phase 1: [Phase Title]
### Objective
[What this phase accomplishes]
### Rationale
[Why this phase comes first, what it enables]
### Tasks
- [ ] Task 1
- [ ] Task 2
- [ ] Task 3
### Success Criteria
[How to verify this phase is complete]
### Files Likely Affected
[List of files that will probably need changes]
---
## Phase 2: [Phase Title]
[Same structure as Phase 1]
---
[Continue for all phases]
---
## Post-Implementation
- [ ] Documentation updates
- [ ] Testing strategy
- [ ] Performance validation
## Notes
[Any additional context or decisions made during planning]
After writing the implementation doc, inform the user:
"Implementation plan complete! Document saved to docs/{name}/IMPLEMENTATION.md
Next step: Run /build progress {name} to set up progress tracking."
If feature name not in arguments, use AskUserQuestion to prompt for it.
Check if docs/{name}/IMPLEMENTATION.md exists.
If it does NOT exist:
docs/{name}/IMPLEMENTATION.md"/build implementation {name} first."Check if docs/{name}/PROGRESS.md already exists.
If it exists, use AskUserQuestion:
If "Keep existing" selected, read the progress doc and suggest the next incomplete phase.
Read docs/{name}/IMPLEMENTATION.md to extract:
Write to docs/{name}/PROGRESS.md with this structure:
# {Feature Name} Progress
## Status: Phase 1 - Not Started
## Quick Reference
- Research: `docs/{name}/RESEARCH.md`
- Implementation: `docs/{name}/IMPLEMENTATION.md`
---
## Phase Progress
### Phase 1: [Title from Implementation]
**Status:** Not Started
#### Tasks Completed
- (none yet)
#### Decisions Made
- (none yet)
#### Blockers
- (none)
---
### Phase 2: [Title]
**Status:** Not Started
[Same structure]
---
[Continue for all phases]
---
## Session Log
### [Date will be added as work happens]
- Work completed
- Decisions made
- Notes for next session
---
## Files Changed
(Will be updated as implementation progresses)
## Architectural Decisions
(Major technical decisions and rationale)
## Lessons Learned
(What worked, what didn't, what to do differently)
After creating progress doc:
"Progress tracking set up! Document saved to docs/{name}/PROGRESS.md
Next step: Run /build phase 1 {name} to begin implementation."
Parse arguments to extract:
If neither provided, prompt for both using AskUserQuestion.
If feature name not determined, use AskUserQuestion to prompt for it.
Check that all three docs exist:
docs/{name}/RESEARCH.mddocs/{name}/IMPLEMENTATION.mddocs/{name}/PROGRESS.mdIf any missing, inform user which doc is missing and suggest the appropriate /build command to create it.
If phase number not in arguments:
Read docs/{name}/IMPLEMENTATION.md to extract available phases.
Use AskUserQuestion to let user select:
Read all three documents to fully understand:
Before starting implementation:
Begin implementing the phase:
As you work, update docs/{name}/PROGRESS.md:
Update the phase status:
After completing the phase:
"Phase {n} complete! Progress updated in docs/{name}/PROGRESS.md
Next step: Run /build phase {n+1} {name} to continue with [next phase title]."
Or if all phases complete:
"All phases complete! The {feature name} feature implementation is done.
Consider:
If feature name not in arguments, use AskUserQuestion to prompt for it.
Check for existence of:
docs/{name}/RESEARCH.mddocs/{name}/IMPLEMENTATION.mddocs/{name}/PROGRESS.mdBased on which docs exist:
No docs exist:
"No documents found for feature '{name}'.
Next step: Run /build research {name} to start."
Only RESEARCH.md exists:
"Research complete for '{name}'.
Next step: Run /build implementation {name} to create implementation plan."
RESEARCH.md and IMPLEMENTATION.md exist:
"Research and implementation plan complete for '{name}'.
Next step: Run /build progress {name} to set up progress tracking."
All three exist:
Read PROGRESS.md to find current phase status.
"Feature '{name}' is in progress.
Current status: [Phase X - status]
Next step: Run /build phase {next incomplete phase} {name} to continue."
If all phases complete: "Feature '{name}' implementation is complete!"
Throughout all phases, use AskUserQuestion whenever:
"Deep research" means:
Don't rush through research - it's the foundation for good implementation.
Keep PROGRESS.md updated in real-time during phase work:
A key purpose of this workflow is preventing scope creep:
When implementing phases: