implement

实现

此技能需要 tdd、babysit-specs 和 project-knowledge。开始任何工作之前，请确认这些技能均已安装。缺少某项技能时，请停止并报告该技能及其安装命令 npx skills@latest add toy-crane/skills --skill <name>；如果项目指定了包管理器运行器，则使用该运行器。

追踪器协调文件夹时认领该文件夹

输入始终是规格文件夹。如果仓库的 AGENTS.md 或 CLAUDE.md 中有 ## Issue tracker 部分，请阅读这两个文件，并在查找此文件夹的问题之前，使用第一个找到的文件及其链接的详细约定。spec.md 中的 Issue: <tracker>:<id> 行会标明该文件夹对应的唯一问题；按该 ID 获取问题，绝不要通过标题在追踪器中搜索。现有的内联约定仍然有效。使用约定中的 ID 格式、工具和认领操作，无需要求安装 setup-issue-tracker。 认领是本次运行的首次写入，必须先于源代码、任务或规格文件的任何编辑。 认领之前，请检查约定中的活跃工作标记：如果问题已在处理中，必须获得用户明确要求恢复的指示，即使当前账户就是受指派人。将符合条件的工作指派给当前追踪器账户，并应用约定中的活跃状态。如果其他账户已认领、存在未解决的阻塞项、无法读取链接的约定，或追踪器工具不可用，请停止、不更改源代码并报告；只有在用户明确指示时，才可不经认领继续执行。 没有 Issue: 行的文件夹无需认领；承载该文件夹的 PR 会创建对应问题。没有该部分时，本节规则均不适用。

每条提交消息的末尾都要添加 Spec-Folder: docs/specs/<slug>/ trailer，以便后续 PR 找到该文件夹并关闭对应问题；无论是否存在追踪器，此 trailer 都属于仓库信息，必须写入。

加载当前交接内容

将选定的规格文件夹视为一个以 spec.md 为核心的交接包。 在推导实现方案或修改源代码之前，先识别并加载当前必需的来源：规格；所有尚未完成的活动任务；当前证据所涉及的任何已完成或已被取代的任务；规格或活动任务明确链接的项目决策契约，以及仓库证据所涉及的任何其他当前决策契约；以及规格或活动任务指定为已批准或已选定实现参考的所有原型、屏幕、状态或其他参考产物。在开始工作之前，阅读文本来源，并渲染或以其他方式检查视觉产物，以便掌握其实际内容。文件夹中存在某项内容，并不代表它已获批准。已批准的视觉参考是其涵盖的具体屏幕和状态的必要补充契约；明确的产品契约仍保留其规定的含义。如果必需来源相互矛盾，应保留这些来源，记录确切来源以及受影响的行为或屏幕状态坐标，并在解决方案设计阶段将该结果及其依赖项保持为阻塞状态，而不是自行选择其中一方。

未被取代的已批准任务文件构成当前浅层交付地图：pending、in-progress 和 blocked 任务属于尚未完成的活动工作，而 completed 任务是当前证明。superseded 任务属于非活动恢复历史；将其排除在当前工作范围、阻塞项、协调和完成门槛之外，但如果当前证据涉及其先前实现，则应检查它。如果活动任务仍将已被取代的历史列为阻塞项，应先协调并清除这一过时引用，再继续。

在选择或开始每项成果之前，以及每次中断之后，都要根据必需的交接来源、代码、Git 状态、当前差异和验证证据，重建当前事实。仓库证据优先于记忆中的对话；如果验证早于相关代码，应重新运行验证。保留当前证据仍然通过验证的已完成成果，并在吸收归属不明的脏改动之前确认所有权。然后从当前未阻塞的工作范围按顺序推进；如果不存在任务文件，则直接实现 spec.md。

在为某项成果修改源代码之前，应对照仓库自此以来的变化检查规格。将规格的假设、已确定的约束和验收标准，与当前代码以及自规格文件夹上次提交以来的 Git 历史进行比较；你自己的代码与任务检查点会推进这一基线，因此每次检查只需涵盖自上一项成果以来发生的变化。如果不匹配会改变已批准的成果、验收标准、禁止触及的区域或其他产品约束，则必须在进行任何源代码修改前停止该成果：指出过时之处及其证据，然后将其转交给 babysit-specs，且仅针对这个规格文件夹，并提供过时之处及其证据；它会返回修订后的 spec.md，本次运行应重新加载该文件后再继续。指定文件夹可确保修订仅针对选定的工作单元；你仍然不得读取任何同级规格文件夹。在此处发现规格过时不会造成任何损失；如果在实现过程中途才发现同样的问题，则已完成的工作将被丢弃。

仅在需要时推导当前活动成果的技术方案。任务边界要求重新加载，但这本身并不要求开启新会话、新工作者或新审查者。将规格文件夹保留为唯一交接内容，不要增加路线图、执行台账、持久化实现计划或运行状态文件。

修改源代码前完成外部设置

如果 spec.md 在 ## Setup before implementation 下列出了事项，请在认领任务后、首次修改源代码前完成这些事项。在当前工具和权限范围内，尽可能自行处理每一项，然后检查所有完成条件。如果仍有任何事项未完成，请一次性报告所有未完成事项、用户需要完成的内容及其完成条件，并停止，不要修改源代码。用户表示已完成且所有条件均满足后，再继续；只有在你无法自行观察某项条件时，才请用户确认。绝不要索取、在聊天中接收或打印秘密值：应由用户将其放在产品读取的位置，并通过可观察到的效果或用户确认来检查条件。如果该部分为 None.，或规范中没有此部分，则无需执行任何操作。

实施并核对一个结果

根据已商定的行为和现有接口，选择一个公开的测试接缝。 简要说明该接缝及其将验证的行为，然后将两者交给 tdd 技能。该技能通过此接缝一次实现一个从失败到通过的行为， 并交回通过的测试及其所确立的改动。 通过代码仓库中的证据解决技术上的不确定性； 只有在预期行为仍不明确，或继续操作会改变已商定的产品约定时， 才询问用户。

根据验收标准、受影响的界面、所声明的平台，以及有关更深层级的任何声明（例如网络、 原生集成、组件行为或性能），推导当前结果所需的运行时证据。针对每个受影响的界面， 使用与之匹配的可用专用运行时验证技能；该技能负责其框架特定的观察流程。

对于有获批视觉或状态参考的屏幕类结果，根据该参考推导适用的屏幕、 状态和视口坐标，并逐一对照运行中的实现。验证具体的构图、内容、 层级、容纳关系、位置和可见性，以及相关的转换和恢复能力；仅证明元素存在且导航成功， 不足以证明与参考一致。在参考明确的范围内应用该参考，并使用运行时证据验证其未涵盖的原生行为 或其他声明。结果中提及的每个平台，都必须针对相同的适用屏幕和状态进行实际屏幕对照， 并采用该平台预期的布局和原生规范；某个平台的证据不能证明另一平台也符合要求。

若无可用参考，请调查代码仓库和当前环境，并自行构建最强可用的运行时验证路径。若框架或工具的行为会影响验证， 请查阅当前权威指南。仅仅因为缺少技能，不要要求用户批准这种常规技术选择。

每次有意义的行为变更后，都要在运行中的产品里测试受影响的最小完整流程。确认当前变更已加载， 复现期间未出现相关运行时错误，并且准确的可观察结果符合预期。只有在结果涉及更深层级时， 才检查该层级。如果可用且在范围内的路径无法展现变更后的行为，则记录确切的失败关卡和前置条件， 并将该结果标记为未完成；构建、类型检查、测试、截图和代码检查都不能替代运行时证据。

通过有针对性的验证完成该结果及其验收标准。在标记为完成或开始依赖此结果的工作之前， 必须将观察到的行为与每个必需的交接来源以及适用的验收标准或参考逐一核对。即使在没有任务文件的情况下实施 spec.md，也必须通过此关卡。

对于保留产品约定的已验证发现：

• 修正当前结果中可随时调整的技术方案及任何已记录的技术假设。
• 在受影响的、仍未完成的任务边界、顺序、阻塞项、任务特定约束、验证要求或可观察等效的任务验收措辞中， 持久记录实际的下游影响。记录简明的修订证据，并保留不受影响的任务约定。

存在任务时，记录当前状态，以及适用的验证、阻塞或修订证据。若要求提交， 将代码、测试和任务更新作为一个有意义的检查点一并提交。仅运行任务明确规定的中间评审检查点， 每个检查点都只对其声明的范围和风险执行一轮，并按以下规则进行分类；核对过程不增加检查点。

保留权威依据和持久发现

实施权威仅涵盖技术路径和当前未完成任务图，且前提是已批准的产品契约保持不变。如果某项发现会改变已批准的结果、范围、可观察的规范验收标准、禁止触碰的区域或其他产品约束，则保留当前工件和证据，将受影响的结果及其依赖项保持为阻塞状态，并在吸收变更之前停止。如果已批准的参考资料与明确的产品契约不一致，也应遵守同一边界：报告两者的确切差异，而不是默默将其中一方视为覆盖另一方。通过 shaping 将确切的决策提交给用户定夺。

如果后续代码、集成、验证或审查使已完成的任务失效，则保留其先前证据，并将其恢复为 in-progress 或 blocked。在该任务的验收标准和针对性验证再次通过之前，保持依赖任务和最终工作处于阻塞状态。completed 表示当前有证据支持，而非历史上曾经成功。

在当前工作中解决范围内的差异及受影响的任务。对于根因仍未解决的变通方案，或有证据支持的范围外缺陷，应在发现时通过 project-knowledge 跟进，并提供症状、观察到的证据、推测的原因、已尝试的措施和建议的下一步；同时保留其报告的 docs/follow-ups/<slug>.md 路径以便交接。

在审查前完成确定性验证

在所有结果通过针对性验证和协调后，重新运行完整的确定性验证。保留可供审查的针对性运行时证据；在审查和必须修复的问题完成后，再运行最终的变更流程和核心循环门禁，确保该门禁检查的是即将交付的修订版本。

完成一次完整差异审查，然后分类处理

在所有结果通过协调和完整的确定性验证后，针对整个实现差异与规范及其验收标准进行一次完整的自动化代码审查。只有当审查者完成预期范围的检查，并返回发现或明确表示未发现问题时，才算通过。调用、部分输出或静默退出都不算通过。只有用户明确豁免时才跳过必需的审查，并记录豁免范围。

使用当前运行环境允许你调用的审查者。先前会话中的仅限用户使用的限制，并不能证明当前不可用；请重新检查。根据你能自行调用的模式，权衡变更涉及的内容与现有验证已能确认的事项，选择适当的审查深度并明确说明，因为未指定模式的运行环境可能会沿用之前的模式。保留给用户的更深入模式只能作为选项提供，不可自行选择。如果没有特别理由，使用运行环境的标准模式：在 Claude Code 中为 code-review medium，而 Codex 没有可调节的深度。无论审查者是否接受上下文，都应提供所需的交接来源或其仓库路径：规范中已批准的范围、禁止触碰的区域和剩余风险、当前任务契约、关联的项目决策、适用于该差异的已批准参考工件，以及已收集的针对性验证证据。将审查者报告的范围与交接内容及你打算审查的差异核对。针对其他目标的发现需要重新指定审查目标，而不是修复；该次审查不计入次数。

对于由模型服务支持的审查，说明实际使用的服务，以及该服务将接收的差异、规范和相关源上下文。将适用的用户授权纳入执行请求，并在后续执行中复用，无需再次询问。只读描述的是文件访问方式，并不代表上下文不会离开本机。如果服务或源范围超出该授权，只请求缺失的授权；技能指令本身不构成许可。 在授权范围内恢复命令、兼容性、环境和暂时性故障，并重试。失败或目标错误的尝试不会消耗次数。明确区分显式策略拒绝与这些执行错误：保留拒绝理由，只寻求实质上更安全且获准的替代方案，或在重试前请求所需的具体授权。不得通过改用其他工具或服务来绕过对同一操作的拒绝。 对于因缺少用户权限而受阻、可由模型调用的审查者，先确认实际服务和来源范围，再请求该权限。已确认的手动命令不能替代对缺失授权的解决。

如果因权限、仅供用户使用或不存在的审查者，或尚未解决的执行故障而无法完成审查，则整体完成状态保持待定。保留已验证的结果，提供相应证据和可运行的交接信息，并明确指出具体阻碍及下一步所需操作。仅当当前运行环境确认可用时，才提供用户命令。对于已声明的中间检查点，依赖它的工作也必须等待其审查或明确豁免。

只有当某项发现违反已批准的验收标准，或是你通过在普通使用可到达的路径上复现而确认的缺陷或回归时，才修复该发现；审查者的断言本身不构成确认。修复后，重新运行受影响的验证。不得让审查者对同一范围审查两次，包括修复内容在内。每个范围只能审查一次：先审查已声明检查点的累计范围，再审查整个差异。任何人要求再次审查时，应告知其使用已确认的用户命令，而不是再次调用审查者。

记录所有其他发现，而不要修复：有证据支持的缺陷或尚未解决的变通方案，通过 project-knowledge 按相同的五个字段记录，并保留其报告的后续处理路径；规范或决策合同已解决的权衡，记录为已解决；范围外、风格方面或未经确认的发现，记录在交接信息中；规范未解决的重大后果（例如安全权衡或对病态输入的处理失败），记录为由用户负责决策的事项。

审查和修复后验证最终产品

整个差异的审查完成并完成分类，且任何必须修复的问题都已修复并通过受影响的验证后，应在运行中的产品里重新执行已更改的流程，以及依据根目录 PRODUCT.md 核心循环确定的代表性用户旅程。明确的审查豁免也会进入此验证关卡。结果中提及的每个平台都必须提供针对交接版本的运行时证据；绝不能用一个平台的证据推断另一个平台的情况。

如果缺少 PRODUCT.md 或其中的核心循环，则验证已更改的流程，并报告缺失的回归覆盖，不要自行编造用户旅程，也不要编辑该文件。如果核心循环允许存在实质不同的用户旅程，则保留当前证据，并将产品解读问题交由用户澄清；这不同于对验证方法的批准。

如果最终验证发现范围内的缺陷，则修复该缺陷，重新运行受影响的检查，然后针对修复后的版本重复此关卡，不再进行第二次审查。可执行的修复会使此前的最终运行时证据失效，包括审查前验证运行所产生的证据。如果必需的运行时检查受阻，完成状态保持待定，并明确指出未通过的具体关卡及其前置条件。

只有满足以下条件才能视为完成：已检查所有必需的交接来源；所有适用的验收标准和已批准的参考标准均已与待交接的可执行版本核对；每项必需审查均已完成或由用户明确豁免；所有必须修复的问题均已修复并重新验证。未检查的必需来源或未比较的适用标准都会使结果保持未完成。审查完成后仍可保留已记录的发现；通过关卡并不要求零发现。报告用于支持结论的来源和审查范围、审查结果或明确豁免、所做更改，以及仍未解决的事项。

让交付的更改变得可直接审查

在完成报告结尾展示交付的产品更改，让用户可以直接从自己的视角进行审查。实现完成后，用户不应还需要询问改了什么，或要求查看重要界面。

选择当前可执行版本所能提供的最有力证据，并提供足够的信息，让用户了解最终体验、追踪重要的后续影响，并发现与已批准意图不符之处。如果更改最好通过视觉效果来评判，就使用实际产品界面；如果交互很重要，就展示观察到的行为；对于无法直观看到的规则，则用简洁的说明阐释。

不要围绕文件或测试来组织这份说明，但应另行报告相关验证情况。不要把原型或过时的截图当作交付版本的证明，并指出任何未能展示的重要内容。

移交可运行的产品

完成上述报告后，如果仓库通过用户可审查的本地服务器提供实际结果，就按受支持的开发或预览流程运行它。验证已更改的路由和关键状态，提供可访问的地址，并说明应审查哪些内容。复用由当前检出目录拥有且运行正常的服务器，或者启动一个隔离的服务器，同时保留其他检出目录和无关进程。让该服务器持续运行，直至审查完成，或经授权的交付清理将其停止。如果环境无法提供可访问的地址，请报告准确的启动命令和阻碍因素，不要声称 URL 可用。如果仓库没有这类服务器，请移交经过验证的结果，不要凭空编造地址。能够访问运行中的结果只是交付证据，不代表获得了人工批准。