构建
根据自然语言描述构建一个项目。自动统筹设置、规划和实现。
所有面向用户的输出必须使用简洁易懂的中文。避免专业术语：不要出现"TDD"、"冲刺"、"PR"、"压缩合并"、"CI/CD"、"ORM"、"中间件"等。如果不可避免地要使用技术术语，请在其后用括号加以解释。
参数
$ARGUMENTS — 用简洁中文描述要构建的内容（例如：“一个带用户账户和截止日期的任务管理应用”）。
阶段0：检查设置
从 CLAUDE.md 中读取当前配置文件。如果不是精简配置，则记录该配置但继续执行——/build 内部始终使用精简风格执行，无论项目配置文件如何。
阶段1：分解
显示：“正在规划需要构建的内容...”
内部使用 /ideate 逻辑将描述分解为有序的任务：
- 识别描述中的核心实体和功能
- 分解为依赖有序的实现步骤
- 将每个步骤分类为功能特性、基础设施或测试
- 估算每个步骤的大小（目标是每个步骤涉及 ≤5 个文件）
不要向用户透露以上任何内容。 不显示故事类型、SPIDR、优先级标签、方法术语。将分解过程保持为内部操作。
创建一个简单的内部计划（不向用户显示）：
steps:
- summary: "设置数据库表"
type: infrastructure
files: [...]
- summary: "构建 API 端点"
type: feature
files: [...]
- summary: "添加用户身份验证"
type: feature
files: [...]
- summary: "编写测试"
type: testing
files: [...]
发现捕获（回溯式）
静默捕获发现上下文，供后续阶段审查使用——用户不会看到此部分：
- 从描述中推断项目原型（根据
.claude/skills/discover/references/scale-guide.md中的10种原型进行分类） - 将规模设置为快速构建
- 自动生成一个最小的
docs/reference/DECISION_LOG.md（从.claude/skills/discover/assets/decision-log.md复制模板），将所有技术决策记录为置信度：假定 - 包含阶段过渡故事（E0N-审查：3故事快速变体——E0N-001、E0N-004、E0N-006）作为最后一个内部步骤
- 将分类保存到
vision/classification.md
这确保了 /build 用户无需前期摩擦即可获得审查循环。
阶段2：执行
按依赖顺序对每个步骤执行：
-
用简洁中文显示进度：
- "正在设置数据库..." / "正在构建 API..." / "正在添加用户登录..." / "正在编写测试以确保一切正常工作..."
- 使用用户能理解的语言。切勿说：“正在执行故事E01-003（类型：功能特性，大小：标准）”
-
使用故事循环的精简行为执行：
- 规划（轻量级——无置信度评分）
- 在非平凡代码上使用 TDD 构建（运行测试，不解释 TDD 方法论）
- 验证测试是否通过
- 使用常规格式提交（不解释提交规范）
-
静默做出所有技术决策：
- 框架/库选择：选择最合适的，在最终摘要中记录
- 架构：遵循检测到的技术栈的标准模式
- 文件结构：遵循现有项目约定或检测到的技术栈默认值
- 仅在遇到真正的产品歧义时停止：“这里有两种设计方案：[A] 或 [B]，您更喜欢哪一种？”
- 绝不为以下问题停止：数据库选择、API 风格、文件命名、测试框架、文件夹结构
-
优雅处理失败：
- 如果某个步骤在尝试2次后失败，跳过该步骤并附上提示：“我无法自动使 [X] 正常工作。以下是需要手动完成的操作：[描述]”
- 继续执行剩余步骤——不要阻塞整个构建过程
阶段3：完成
3A. 启动并验证（如适用）
检查 CLAUDE.md 命令中是否有 dev: 命令。如果已配置：
- 显示：“正在启动您的项目...”
- 使用 Bash 的
run_in_background: true在后台运行开发命令 - 等待几秒钟。读取任何输出——查找 URL、端口、文件路径或状态消息。
- 显示命令产生的任何内容。如果输出了 URL，则高亮显示。如果是 CLI，则显示帮助输出。如果启动了服务器，则显示地址。
- 询问：“请查看并告诉我您的想法！”
- 等待反馈。正面反馈 → 进入完成报告。存在问题 → 修复并重新运行。
如果没有配置 dev 命令（对于库、包、流水线等）→ 跳过此步骤。测试已验证构建。
不要假定 localhost 或任何特定 URL。 读取实际的命令输出。不同的项目会产生不同的结果。
3B. 完成报告
用简洁中文显示完成报告：
## 完成！
### 已构建的内容
- [功能特性1]: [简洁中文描述其功能]
- [功能特性2]: [描述]
- ...
### 创建/修改的文件
- `src/models/user.ts` — 用户数据模型
- `src/api/auth.ts` — 登录和注册端点
- ...
### 测试
- 编写了 [N] 个测试，全部通过
### 做出的技术决策
- **数据库：** PostgreSQL（可靠、免费、与 [框架] 配合良好）
- **身份验证：** [选择的方法] — [一行理由]
- ...
### 尝试运行
[如果开发命令已运行：“您的项目正在运行——见上方”]
[如果开发命令存在但未启动：“运行 `[dev command]` 以启动”]
[如果没有开发命令：省略此部分]
### 后续步骤
- [建议1，例如：“使用 /build 'Stripe 支付集成' 添加支付系统”]
- [建议2]
规则
- 仅使用简洁易懂的中文 — 每条面向用户的消息都必须让从未编写过代码的人能够理解
- 静默做出技术决策 — 选择良好的默认值，在完成报告中记录，绝不询问用户
- 仅针对产品问题停下 — “用户应该能够删除自己的账户吗？” 是有效问题。“REST 还是 GraphQL？” 则不是
- 安全挂钩仍会运行 — 秘密检测、git 保护和测试执行在后台静默进行
- 精益执行 — 不调度质量 Agent、不生成冲刺规范、不进行回顾、不生成超出工作需求的文档
- 优雅跳过 — 失败的步骤会被记录，但不会致命。构建过程继续
- 单次会话 —
/build的第一个版本在单次会话中完成。多会话构建是未来的工作