📦 spec-executor

Spec Executor 以状态导航与状态保障为核心的执行工作流。随时知道：当前在哪、下一步是什么、中断后如何恢复。

⚠️ 依赖提示 本技能不能独立使用。必须先由 spec-workflow 生成 plan 与 tasks.md 追踪器，方可执行。

技能阶段职责 spec-workflow 规划：需求 → 设计 → 任务拆分 spec-executor 执行：状态导航 → 任务执行 → 状态恢复

交接示例 spec-workflow 输出： docs/login-feature/tasks.md docs/login-feature/requirements.md docs/login-feature/design.md

spec-executor 输入：

• 读取 docs/login-feature/tasks.md
• 按序执行任务
• 每完成一项，更新 tasks.md
• 禁止对未经 spec-workflow 规划的工作使用本技能

校验 执行前确认 tasks.md 存在且含有效任务条目（Scope + Verification 字段）。缺失或格式错误即停止并询问用户。

快速开始 首次使用且 tasks.md 已确认：

• 读 tasks.md → 找首个 [ ] 任务
• 标为 [~] → 按 Scope 执行
• 完成：标 [✓]，填 Verification，暂存变更
• 展示 diff → 等待用户显式确认提交
• 用户说“next” → 回到步骤 1

会话压缩？跳至“会话恢复”。

状态导航 Where Am I? 收到用户指令 │ ├─ 范围清晰且小？─→ 是 → 直接执行（简单任务） │ 否 ├─ 需设计/架构？─→ 是 → 先规划 → 写 tasks.md → 执行 │ 否（不清） └─ 调研 → 重新分类

当前状态 → 下一步 → 关键输出 刚收到指令 → 分类任务 → 决定直接干 or 规划 规划中 → 写设计+tasks.md → 等用户确认 tasks.md 已确认 → 读文件，标首个待办 [~] 执行中 → 完成任务 → 更新 [✓] → 提交 → 下一项 更新追踪器 → 遇错 → 停 → 诊断 → 修复 → 继续 会话中断 → 读 tasks.md → 校验末项 → 恢复 用户插无关查询 → 处理 → 回到原位

状态迁移规则 [已分类] --(简单)--> [执行中] --(完成)--> [更新追踪器] --(还有)--> [执行中] │ └─(全完)--> [完成] └─(复杂)--> [规划中]--(确认)--> [执行中] └─(拒)--> [修订计划] [执行中]--(出错)-->[诊断中]--(修复)-->[更新追踪器]--> [执行中] └─(卡)--> [问用户] [任意状态]--(无关查询)-->[处理查询]--> [回原状态]

铁律：未更新 tracker 不得进入下一任务；tasks.md 更新即任务完成定义。

任务分类 动手前先分类：

类型 标准 需规划？ Complex 新功能、架构变更、多文件重构、API 设计 是 → 用 spec-workflow Simple 单文件、配置微调、已知范围 bug 否 → 简要说明后直接干 Exploratory 范围不清，需调研 先调研，再重分类

边界规则：若“简单”任务需设计决策、接口改动、跨文件协调，立即升级“复杂”并规划。

任务类型速查 用户意图 类型 动作 新功能/大重构 Complex 触发 spec-workflow 有票据的 bug/接口对齐 Fix/Complex 触发 spec-workflow（阶段1-2可简化） 单文件/配置/小修 Simple 简要说明 → 直接干 解释代码/查日志/信息查询 Routine 直接执行，无需 Spec

会话拆分 tasks.md 待办 >8 项或预估工时>2h，建议 /clean 并新开会话。

必须问用户 以下情况须停问：

• 需求背景不清：“这段代码要解决什么问题？”
• 设计冲突：“A/B 两种方案，优先级？”
• 删代码：“X 处似乎在用，确定删？”
• 删代码—验证：先 grep 确认无下游引用
• 范围扩大：“比原请求宽，是否重设计？”
• 发现更好方案：“原设计意图？”