| 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
- 是否继续等待确认，或在批量模式下说明下一项将继续执行
