dev-builder

name: dev-builder description: Used when DEV-PLAN.md is ready and the user says to start coding or continue developing the next Phase. Sets up the skeleton for new projects, implements features by Phase for existing projects. version: 1.2.0 updated: 2026-06-27 requires: []

[Task] Initialization Mode (0-to-1): No code + has DEV-PLAN.md -> set up project skeleton according to tech stack, install dependencies, configure development environment, complete Phase 1. Phase 1 的核心不是"写功能"，是"放骨架": - 先写领域模型、核心类型定义、数据流接口 - 再写 Validator 模式、错误处理公约、中间件链 - 这些就是项目独有的"天理"——牛的骨节结构 - 后续所有 Phase 的代码都是从这些骨架生长出来的 - 所以 Phase 1 宁可慢一点把骨架放稳，也不要为了"快点看到功能"而跳过 - 骨架放好后，后续 Phase 的代码模型自然续写——因为"这个项目的代码长什么样"已经定了

**Continuous Development Mode**: Has code + has DEV-PLAN.md -> develop by Phase, **one Phase per /dev-builder invocation**. Each Phase: Plan Mode to plan implementation -> per-Task review + commit -> Phase four-step verification -> user confirmation -> **force stop** (suggests running **/code-review** for a holistic Phase-level review). User must call /dev-builder again for next Phase.

**Change-Scoped Mode**: Invoked from `/change-manager apply` with `change-name=<name>` -> read `changes/<name>/` (specs, design, tasks), execute **only** unchecked items in `changes/<name>/tasks.md`. Do not pull unrelated DEV-PLAN Phases. Still uses implementer + TDD + two-tier review per Task.

[Not For] - Fixing bugs in existing code -> use /bug-fixer instead - Reviewing code quality -> use /code-review instead - Planning development phases -> use /dev-planner instead - Gathering requirements -> use /product-spec-builder instead

[Dependency Check] Executed automatically as the first step when the Skill starts.

Required:
- Product-Spec.md -> if missing, prompt user to call /product-spec-builder first
- DEV-PLAN.md -> if missing, prompt user to call /dev-planner first
- All system tools and runtime environments listed in the DEV-PLAN tech stack table

Optional:
- Design-Brief.md -> if missing, mark as "no design specification mode"
- DESIGN.md -> if present, use frozen tokens for Tailwind/theme (priority over Brief for exact values)
- Design tool MCP -> if missing, mark as "no design draft mode"
- gh CLI -> if available, can automatically create GitHub repo and push
- playwright -> if available, can do UI automated testing
- **Dependency Graph** (`dep-graph`) -> if available, enables blast-radius analysis for impact assessment and risk-scored complexity gating

Installation Strategy:
- When required dependencies are missing or version requirements not met, the Agent autonomously determines the installation method and installs directly — no manual user operation needed
- If user permissions or interaction is needed, prompt the user to act
- When optional dependencies are missing, mark as degraded mode and continue working — do not block the workflow

[First Principles] 编码前必读 references/first-principles.md。TDD、implementer 隔离、验证即证据 — 非协商。

[Shared Discipline] Karpathy 四原则 → ../_shared/karpathy-discipline.md（全文 core/docs/behavior-rules.md） finding 的 action 三分（auto-fix/ask-user/no-op）驱动 Step 14.6 立即 escalate → ../_shared/finding-actions.md

[HARD-GATE] 主 Session MUST NOT 直接 Write/Edit 业务代码；每 Task dispatch implementer 并创建 .forge/implementer-session.json；首次改代码前 MUST git worktree。

**Exception 1 — UI / Integration Phase**: 主 session 可直接 Write/Edit，不强制 implementer 和 worktree。理由：UI 代码需要完整组件上下文，implementer 隔离得不偿失（Dogfood #2 验证）。

**Exception 2 — Small Phase (any Nature)**: 当 Phase 的 Key Files ≤3 且 Deliverables ≤5（即"Small Phase"），主 session 可直接 Write/Edit，不强制 implementer 和 worktree。理由：小型 Phase 的 implementer 冷启动开销 > 实际编码工作量（Dogfood #3 验证：Greenfield CLI 全部 5 Phase 均小到不值得隔离）。尺寸判定详见 `references/workflow.md` § Nature Gate Step 1.5。