build

name	build
version	1.0.1
description	Build a project from a plain-English description. Handles all technical decisions automatically. Designed for non-technical users but useful for anyone who wants fast results.
trigger	manual
depends-on	["bootstrap","ideate","story-cycle"]
references	[]
micro-components	{"setup":["discover-commands"]}
disable-model-invocation	true
user-invocable	true
allowed-tools	Read, Glob, Grep, Bash, Edit, Write, Agent
argument-hint	<description of what to build>

---

build

Build a project from a natural-language description. Orchestrates setup, planning, and implementation automatically.

All user-facing output MUST use plain English. No jargon: no "TDD", "sprint", "PR", "squash merge", "CI/CD", "ORM", "middleware". If a technical term is unavoidable, explain it in parentheses.

Arguments

$ARGUMENTS — a plain-English description of what to build (e.g., "a task management app with user accounts and due dates").

Ask: "What would you like me to build? Describe it in your own words — as much or as little detail as you like." Wait for response before proceeding.

Phase 0: Check Setup

Run a silent minimal bootstrap: 1. Detect stack (languages, package manager, test framework, formatter, linter) 2. Configure CLAUDE.md commands 3. Set profile to **lean** (unless already set) 4. Skip: architecture docs, coding standards, ground rules, readiness report, foundation backlog 5. Show: "Setting up the project..." (nothing more) Show: "Project already set up. Starting build..."

Read the current profile from CLAUDE.md. If not lean, note the profile but proceed — /build always uses lean-style execution internally regardless of project profile.

Phase 1: Decompose

Show: "Planning what needs to be built..."

Internally decompose the description into ordered stories using /ideate logic:

1. Identify the core entities and features described
2. Break into dependency-ordered implementation steps
3. Classify each as feature, infrastructure, or testing
4. Size each step by conceptual cohesion (canonical policy: .claude/skills/ideate/references/story-template.md) — one coherent, independently verifiable unit per step; file count informs judgement but is never a threshold

Do NOT surface any of this to the user. No story types, no SPIDR, no priority labels, no methodology terminology. Keep the decomposition internal.

Create a simple internal plan (not shown to user):

steps:
  - summary: "Set up the database tables"
    type: infrastructure
    files: [...]
  - summary: "Build the API endpoints"
    type: 
     []
    
     
     []
    
     
     []