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 任务然后执行固定八步读取该任务的验收标准acceptance criteria加载相关上下文现有代码、模式、类型定义为预期行为编写失败的测试RED编写使测试通过的最少代码GREEN运行完整测试套件检查回归运行构建验证可编译用描述性信息提交将任务标记为完成然后停止这条循环与两个底层技能严格对齐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. 三类必须停下来询问的情形自主模式不是一路推到底。遇到以下任一情况命令要求停止并询问用户而不是硬推触发条件处置方式测试无法通过、或构建被破坏且没有显而易见的修复转入 debugging-and-error-recovery 技能规格存在歧义或某任务需要规格未覆盖的决策向用户要决策任务高风险或不可逆——认证/权限变更、破坏性数据迁移、支付、删除、部署、任何触碰 secrets 的操作或任何无法用git revert撤销的东西转入 doubt-driven-development 技能继续前获取显式签核原文还定义了恢复机制用户解决阻塞后重新调用/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过滤函数演示了第一个切片应该小到只需一个纯函数加测试的尺度。适用前提与使用边界需要说明几点适用前提宿主环境该命令位于.claude/commands/目录frontmatter 只含description字段并使用$ARGUMENTS变量属于 Claude Code 斜杠命令的约定形态仓库中 commands/ 目录还存放了面向其他工具的对应命令定义两者是同一方法论在不同宿主上的映射。前置产物/build auto依赖SPEC.md或docs/SPEC.md、spec/下文件与tasks/plan.md。规格由/spec命令spec.md生成计划由/plan命令plan.md生成/build负责在两者存在的前提下执行。自主不等于免验证/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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
agent-skills 的 /build 命令详解：单任务增量构建循环与 /build auto 自主执行模式
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 任务然后执行固定八步读取该任务的验收标准acceptance criteria加载相关上下文现有代码、模式、类型定义为预期行为编写失败的测试RED编写使测试通过的最少代码GREEN运行完整测试套件检查回归运行构建验证可编译用描述性信息提交将任务标记为完成然后停止这条循环与两个底层技能严格对齐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. 三类必须停下来询问的情形自主模式不是一路推到底。遇到以下任一情况命令要求停止并询问用户而不是硬推触发条件处置方式测试无法通过、或构建被破坏且没有显而易见的修复转入 debugging-and-error-recovery 技能规格存在歧义或某任务需要规格未覆盖的决策向用户要决策任务高风险或不可逆——认证/权限变更、破坏性数据迁移、支付、删除、部署、任何触碰 secrets 的操作或任何无法用git revert撤销的东西转入 doubt-driven-development 技能继续前获取显式签核原文还定义了恢复机制用户解决阻塞后重新调用/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过滤函数演示了第一个切片应该小到只需一个纯函数加测试的尺度。适用前提与使用边界需要说明几点适用前提宿主环境该命令位于.claude/commands/目录frontmatter 只含description字段并使用$ARGUMENTS变量属于 Claude Code 斜杠命令的约定形态仓库中 commands/ 目录还存放了面向其他工具的对应命令定义两者是同一方法论在不同宿主上的映射。前置产物/build auto依赖SPEC.md或docs/SPEC.md、spec/下文件与tasks/plan.md。规格由/spec命令spec.md生成计划由/plan命令plan.md生成/build负责在两者存在的前提下执行。自主不等于免验证/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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
