executing-plans-conventions

该技能用于在开始执行一份已经写好的实现计划文档时提供约定层。其触发时机与 superpowers:executing-plans 相同，并明确要求调用 superpowers:executing-plans 作为实际执行与评审检查点流程的负责方；本技能是在其之上叠加的必需层，规定如何机械地信任计划，以及围绕提交应避免哪些行为。\n\n用途与定位：本技能不负责执行或评审流程本身，而是补充执行计划时的操作约定，帮助执行者按计划推进，避免偏离计划或擅自改动提交状态。\n\n主要规则：执行前必须重读计划，并检查计划与仓库当前状态是否存在矛盾，因为仓库可能在计划写成后已经发生变化。详细计划被视为可供机械执行的依据；当计划已经包含确切步骤和接口时，不应要求子代理重新设计方案，也不应让子代理自行重读整份计划，因为这等于重新争论计划阶段已经做出的决定。任务应按计划定义的顺序执行，不应为了方便而重排。所有任务完成后运行计划规定的单次最终验证，而不是每个任务后都运行，也不能跳过；该最终验证是完整的构建、类型检查、lint 与全量测试。它不同于 TDD 在每个任务内部进行的范围受限单测 verify-red/verify-green，后者在整个过程中都必须执行，不能推迟到最终验证。没有用户直接请求时，不得执行 git add、git commit 或创建 PR；一般规则参见 repo-workflow-conventions 技能。\n\n常见错误与修正：未重读计划就开始执行，应先重读，因为仓库可能已经漂移；要求实现子代理重新设计计划已明确规定的步骤，应信任计划，只有计划确实不适配当前仓库状态时才升级处理；每个任务后都运行完整构建、lint 与测试套件，应等待计划规定的单次最终验证，但任务内部仍要运行 TDD 的范围受限单测 verify-red/verify-green；完成所有任务后未经要求就提交，应保持改动未提交，由用户提交或明确要求后再提交。\n\n适用场景：已有一份详细实现计划文档，准备开始按计划执行时。限制：该技能依赖 superpowers:executing-plans 负责实际执行与评审检查点流程；关于仓库工作流的一般规则指向 repo-workflow-conventions 技能。