spec-apply

name	spec-apply
description	在需求已确认并进入执行阶段后，严格依据对应需求目录中的 `spec.md`、`tasks.md`、`log.md` 逐项实施任务、展示可验证证据并同步执行记录。当用户要求进入 apply 阶段、根据已确认 spec 开始编码、按 tasks 逐条落实实现、默认一次做一项后等待确认，或明确要求“全部完成”后顺序批量执行时使用。

spec-apply

协同技能

在执行本 skill 时，同时遵守 ../../references/full-sdd-lifecycle.md 中 spec-apply 阶段的协同规则。

• 实现粒度遵循本插件 skills/incremental-implementation/SKILL.md
• 行为验证遵循本插件 skills/test-driven-development/SKILL.md
• 上下文装载遵循本插件 skills/context-engineering/SKILL.md
• 分支与提交边界遵循本插件 skills/git-workflow-and-versioning/SKILL.md

目标

在提案确认后进入实施阶段，严格执行已确认文档，而不是重新定义需求。

• 将 spec.md 视为行为合同
• 将 tasks.md 视为执行顺序和状态来源
• 将 log.md 视为实时同步记录
• 默认一次只推进一个 task，完成后汇报并等待用户确认

进入条件

执行前先确认以下条件全部满足：

• 对应需求目录已存在，并且包含 spec.md、tasks.md、log.md
• 用户已显式确认进入 Apply，或明确要求根据已确认提案开始实施
• spec.md 中不存在会阻断实现的待澄清项
• tasks.md 中存在当前可执行的任务

若任一条件不满足，立即停止，不要开始编码或修改实现。

• 查看分支是否正确，不允许在 main/master 分支进行开发，必须创建一个新的 feature 分支进行开发，命名格式为 feature/<需求目录>。

执行顺序

按下面顺序执行，不要跳步。

1. 锁定执行合同

先读取对应需求目录中的 spec.md、tasks.md、log.md。

• 将需求范围、非目标、风险和验收点整理成当前任务的边界
• 只执行文档中已经确认的内容，不擅自扩展需求
• 若代码现状与 spec.md 冲突，先停止并汇报，不要私自选择新方案

2. 判断执行模式

默认采用逐步执行模式。

• 若用户没有明确说“全部完成”，只执行一个 task
• 若用户明确说“全部完成”，按 tasks.md 中的顺序连续执行所有可执行任务
• 若某任务依赖前置任务，先完成依赖，再继续下游任务

3. 执行当前 task

围绕当前 task 收集最小必要上下文，然后实施变更。

• 只读取与当前 task 直接相关的代码、测试、文档和配置
• 先改最小闭环，再补测试、校验和文档同步
• 若 tasks.md 的拆分过粗，允许在脑内细化步骤，但不要改写任务目标
• 若发现实现需要突破 spec.md、仓库规则或既有接口契约，立即停止并回报
• 单个 task 内优先保持 S/M 级改动；若需要跨多个系统大范围展开，先回退更新 tasks.md

4. 展示验证证据

每完成一个 task 后，必须给出至少一种可验证证据。

• 优先展示编译、测试、lint、类型检查、接口调用或页面行为验证结果
• 不要使用“应该没问题”“理论上可行”这类无证据结论
• 若受环境限制无法验证，明确说明未验证项、阻塞原因和剩余风险
• 若当前 task 涉及行为变更，优先展示由本插件 skills/test-driven-development/SKILL.md 驱动出的测试证据

5. 同步执行记录

每完成一个 task 后立即同步文档。

• 更新 tasks.md 中对应任务状态
• 将实施过程、验证结果、踩坑点、隐含规则和新增发现写入 log.md
• 若发现长期有效的新规则或背景知识，先记入 log.md，再提示后续是否需要沉淀到 docs/rules/ 或 docs/knowledge/

6. 汇报并等待下一步

在逐步执行模式下，完成一个 task 后立即停下。

• 汇报已完成项
• 展示验证证据
• 说明 tasks.md 和 log.md 已同步
• 等待用户确认后再继续下一项

在批量执行模式下，仍然要对每个 task 产生独立证据和日志，只是不在 task 之间停下等待。

紧急停车

遇到以下情况时立即停止，并执行 Reverse Sync：

• spec.md、tasks.md、log.md 缺失
• 当前代码与已确认 spec 明显冲突
• tasks.md 中的任务描述不足以指导实现
• 实施中发现新的接口、数据结构或行为变化超出既有范围
• 验证结果表明当前实现无法满足验收标准

Reverse Sync 时必须明确说明：

• 停止原因
• 受影响的 task
• 发现的冲突或缺失信息
• 建议回写到 spec.md 或 log.md 的内容

硬门控

始终执行下面约束：

• 默认一次只完成一个 task，然后汇报并等待确认
• 只有用户明确说“全部完成”时，才允许顺序批量执行
• 将 Plan 视为合同，不擅自改需求、改边界、改验收标准
• 每个 task 都必须有验证证据
• 每个 task 完成后都必须更新 log.md
• 没有证据时，不宣称任务已经完成
• 不要把多个 task 混成一次大提交，除非用户明确要求批量执行

质量检查

交付前自行检查：

• 当前实现是否严格落在 spec.md 已确认范围内
• 当前 task 是否已经在 tasks.md 中同步状态
• log.md 是否记录了本次实施、验证结果和新增发现
• 是否为每个已完成 task 提供了可核验的证据
• 是否在需要时及时触发了紧急停车，而不是带着冲突继续写代码

输出要求

向用户汇报时至少包含：

• 当前完成的 task
• 对应的验证证据
• 已同步的 tasks.md 和 log.md
• 是否继续等待确认，或在批量模式下说明下一项将继续执行