Build Features Through Research and Implementation

Implements a /build slash command that runs a 4-document feature-development pipeline across five subcommands: research [name] conducts deep research (codebase exploration, web search, frequent clarifying questions via AskUserQuestion) and writes docs/{name}/RESEARCH.md covering the problem statement, technical approach options with a recommendation, data requirements, UI/UX considerations, and risks; implementation [name] reads that research and breaks it into independently valuable, session-sized phases, asking the user to choose small (1-2hr), medium (half-day), or large (full-day) granularity, written to docs/{name}/IMPLEMENTATION.md with per-phase objective, tasks, success criteria, and affected files; progress [name] reads the implementation plan and scaffolds docs/{name}/PROGRESS.md tracking each phase's status, completed tasks, decisions, blockers, and a running session log; phase [n] [name] reads all three documents, does phase-specific research, executes the phase's tasks with a test-as-you-go discipline, and updates PROGRESS.md in real time; and status [name] inspects which of the three docs exist and reports exactly which command to run next.

/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

Use it for building a major feature that benefits from a structured research-plan-track-implement pipeline with resumable state across sessions - not for a quick fix or small change, where the four-document overhead would be pure friction. Each subcommand enforces prerequisites: implementation refuses to run without an existing RESEARCH.md, progress refuses without an IMPLEMENTATION.md, and phase refuses until all three docs exist, each time naming the exact command to run first instead of silently proceeding. Running a subcommand against a document that already exists triggers an explicit Overwrite/Append/Skip choice rather than silently clobbering prior work.

Input is a feature name, kebab-case, prompted for via AskUserQuestion if not supplied as an argument, plus, for research, a description of the problem and a multi-select of focus areas (technical implementation, UI/UX, data requirements, platform capabilities). Output is a fixed three-document set under docs/{name}/: RESEARCH.md, IMPLEMENTATION.md, and PROGRESS.md, each following a specific Markdown template baked into the skill, such as IMPLEMENTATION.md's per-phase Objective/Rationale/Tasks/Success-Criteria/Files-Affected structure. Every subcommand ends by naming the literal next /build command to run, and phase additionally reports which phase number comes next or that the feature is fully complete.

Depends entirely on the Claude Code AskUserQuestion tool, used liberally throughout every subcommand for ambiguity, scope validation, and phase-granularity choices, plus standard web search and codebase exploration for the deep-research steps. It has no external API or library dependency - it is a pure documentation-and-process skill operating on the local docs/ directory.

Developers using Claude Code to build a substantial feature who want enforced research-before-planning-before-implementation discipline, resumable multi-session progress tracking, and built-in scope-creep prevention, rather than jumping straight into code.