企业官网建设流程全解析

agent-skills 的 /build 命令详解：单任务增量构建循环与 /build auto 自主执行模式

【免费下载链接】agent-skillsProduction-grade engineering skills for AI coding agents.项目地址: https://gitcode.com/GitHub_Trending/agentskill/agent-skills

在 agent-skills 仓库中，.claude/commands/build.md定义了一个面向 AI 编码代理的增量实现命令：/build以"一个任务一个提交"的闭环推进计划中的下一个任务，而/build auto则在一次人工批准后连续执行整个任务计划。读完本文，你能完整掌握该命令的两种运行模式、每一步的校验与停止条件，以及它如何组合调用仓库中的incremental-implementation、test-driven-development等技能来保证每个增量都可验证、可回滚。

命令定位：把"实现"约束成一条可验证的流水线

/build命令的定义位于 build.md。其 frontmatter 中的描述一句话概括了它的职责：

Implement tasks incrementally — build, test, verify, commit. Add "auto" to run the whole plan in one approved pass.

（增量实现任务——构建、测试、验证、提交；加上 "auto" 可以在一次批准的通过中跑完整个计划。）

命令的正文第一行就声明了它依赖的两个核心技能：

Invoke the agent-skills:incremental-implementation skill alongside agent-skills:test-driven-development.

即/build本身不是一个独立方法论文档，而是一个"调度器"：它把 incremental-implementation 的增量纪律与 test-driven-development 的 RED/GREEN 循环组合起来，作用于计划文件中的具体任务。

两种模式：由 $ARGUMENTS 决定

命令通过$ARGUMENTS变量选择运行模式：

• /build（默认，单任务模式）——实现计划中下一个待办任务，然后停止。谨慎地一次推进一个切片。
• /build auto（自主模式）——如需要先生成计划，获取一次批准后，连续实现所有任务，任务之间不再停下来等人。

原文对参数解析规则有明确定义：auto（标准写法）或all都视为自主模式；其余任何输入（包括空字符串）都落入默认的单任务模式。

原文还有一句值得单独强调的设计声明：自主模式在单任务粒度上并不更快——它执行的是同一套测试驱动循环；它只是移除了任务与任务之间的人工介入。换句话说，auto改变的是"人介入的频率"，而不是"验证的严格程度"。

默认模式：单个任务的 8 步闭环

/build默认模式从计划中挑选下一个 pending 任务，然后执行固定八步：

1. 读取该任务的验收标准（acceptance criteria）
2. 加载相关上下文（现有代码、模式、类型定义）
3. 为预期行为编写失败的测试（RED）
4. 编写使测试通过的最少代码（GREEN）
5. 运行完整测试套件检查回归
6. 运行构建验证可编译
7. 用描述性信息提交
8. 将任务标记为完成，然后停止

这条循环与两个底层技能严格对齐：

• incremental-implementation 中定义的增量循环（Implement → Test → Verify → Commit → Next slice，见该文件 L21-L42），并附有一份每个增量完成后的检查清单（L199-L211）：改动只做一件事、现有测试全部通过、构建成功、类型检查与 Lint 通过、提交信息具描述性。该技能还规定了五条实现规则：Rule 0 简单优先、Rule 0.5 范围纪律（不顺手"清理"任务外的代码）、Rule 1 一次只做一件事、Rule 2 保持可编译、Rule 5 可回滚友好（L91-L182）。
• test-driven-development 中的 RED/GREEN/REFACTOR 循环（L38-L94）。值得注意该技能开头的 "Discover the Stack First" 一节：循环是通用的，但命令不是——必须先发现当前仓库用什么跑测试（package.json、pyproject.toml、./gradlew、Makefile等），再决定 RED/GREEN 每一步实际执行的命令，绝不默认使用npm test。

因此，/build的"跑测试、跑构建"两步在真实项目中的具体命令，取决于目标仓库自身的工具链——这也是该命令可以跨语言复用的原因。

自主模式 /build auto：七步流程与三道"刹车"

/build auto适用于"规格已存在，希望把 plan + build 压缩成一次运行"的场景。原文开宗明义：它移除的是任务间的人工步进，不是验证——每个任务仍然必须挣到一个通过的测试和一个自己的提交。完整流程如下：

1. 规格硬门禁（Require a spec）

只在已知路径寻找 spec：仓库根目录的SPEC.md、docs/SPEC.md，或spec/目录下的文件。README 或任意文档不算数。找不到就停下，让用户先运行/spec（对应仓库中的 spec.md 命令，它会引导生成结构化规格并存为SPEC.md）——绝不自创需求。

2. 建立干净基线（Clean baseline）

执行git status --porcelain。如果存在预期规划产物之外的未提交改动——白名单仅包括SPEC.md、docs/SPEC.md、spec/*、tasks/plan.md、tasks/todo.md——就停下来，请用户提交、stash 或确认处理方式。原文解释了动机：自主模式的逐任务提交绝不能吞并无关的本地工作，否则"干净回滚"（clean-rollback）保证会被打破。

3. 必要时生成计划（Plan if needed）

若不存在tasks/plan.md，则调用 planning-and-task-breakdown 技能生成一份。该技能约定计划文档固定落在tasks/plan.md、任务清单默认落在tasks/todo.md，并且有一条与/build直接相关的红线：永不覆盖仍含未完成任务的旧计划——未勾选的任务可能属于另一个正在构建中的会话，必须停下询问（该技能 L150-L155 有明确规定）。每个任务还带有描述、验收标准、验证步骤、依赖与预估规模的结构（L83-L104），这正是/build第 1 步"读取验收标准"的数据来源。

4. 单点检查（Single checkpoint）

呈现完整计划，等待一个无歧义的肯定（如 "approve"、"go"、"yes"）；含糊的回应（"looks reasonable"、"I guess"）一律视为未批准。这是自主模式下唯一的人工门禁——批准之后即全速运行。若计划文件是刚刚生成的，此时先把它作为一次独立的预备提交（preparatory commit）落盘，避免它混入第一个任务的提交。

5. 按依赖顺序执行全部任务

优先使用每个任务声明的依赖；若未显式声明，则按计划列出的顺序执行。对每个任务都完整跑一遍默认八步循环：RED → GREEN → 回归 → 构建 → 提交 → 标记完成。提交时有两条纪律：

• 只暂存该任务实际触碰的文件加上任务状态更新——绝不盲目git add -A；
• 每个任务一个提交，使任意时点都是一个干净的回滚点。

这两条共同支撑了原文所说的"clean-rollback guarantee"：出问题时git revert一个任务，不会牵连其他任务的代码或他人的本地改动。

6. 三类必须停下来询问的情形

自主模式不是"一路推到底"。遇到以下任一情况，命令要求停止并询问用户（而不是硬推）：

原文还定义了恢复机制：用户解决阻塞后重新调用/build auto，命令会从下一个 pending 任务续跑——这正是"每任务一提交 + 任务状态文件"设计带来的可恢复性。

7. 收尾总结

结束时输出：完成了哪些任务、新增了哪些测试、产生了哪些提交，以及任何被跳过、被标记或留给用户处理的事项。

原文最后一条兜底规则：任何一步失败，都遵循 debugging-and-error-recovery 技能处理。

用仓库自带示例理解这套机制

仓库在evals/下为这套流程提供了可执行的评测用例。incremental-implementation.json 定义了正反两端的触发提示与期望行为，例如评测 1 的提示"Implement CSV export for the reports page, working from the existing task plan"，期望输出是"以小的、经过验证的增量交付功能，每个切片一个提交"，检查点包括：工作以细窄的垂直切片推进而非一次大改动、每个切片在下一个开始之前经过验证、每个切片独立提交。

对应的 CSV 导出计划样例 展示了/build实际消费的任务粒度——纯格式化函数加单测、下载适配器、按钮接线共三个任务，并明确写下"每个任务必须在开始下一个之前独立验证并提交"；配套的 reports.js 则是一个最小被测对象（visibleReports过滤函数），演示了"第一个切片应该小到只需一个纯函数加测试"的尺度。

适用前提与使用边界

需要说明几点适用前提：

1. 宿主环境：该命令位于.claude/commands/目录，frontmatter 只含description字段并使用$ARGUMENTS变量，属于 Claude Code 斜杠命令的约定形态；仓库中 commands/ 目录还存放了面向其他工具的对应命令定义，两者是同一方法论在不同宿主上的映射。
2. 前置产物：/build auto依赖SPEC.md（或docs/SPEC.md、spec/下文件）与tasks/plan.md。规格由/spec命令（spec.md）生成，计划由/plan命令（plan.md）生成，/build负责在两者存在的前提下执行。
3. 自主不等于免验证：/build auto相对/build的唯一区别是"任务之间不再等人"，每个任务仍须通过完整测试驱动循环并产生独立提交；遇到规格歧义、高风险或不可逆操作时仍会强制停下。

理解了这个命令后，你可以把"规格 → 计划 → 构建"看成一条完整的链条：/spec固化需求边界，/plan把边界切成带验收标准的垂直任务，而/build（或/build auto）则保证每一刀切下去都带着失败的测试、通过的构建和一个可单独回滚的提交。

【免费下载链接】agent-skillsProduction-grade engineering skills for AI coding agents.项目地址: https://gitcode.com/GitHub_Trending/agentskill/agent-skills