菜单
当同一个活跃 Spec 在当前工作分支内需要小迭代、补充需求、修正方案或优化实现，且原 Spec 目录已有 writer/plan.html + executor/summary.html 时使用。默认复用 writer/plan.html 记录的 git_branch，不新建分支。不要用于新功能从零设计、已合并/已关闭分支上的后续需求，或需要独立 PR 的较大变更。
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/HHU3637kr/skills --skill spec-update命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
当用户开始新的开发任务、需要启动完整 Spec 流程（需求对齐→探索→设计→实现→测试→收尾）， 或需要为一个新 Spec 创建协作上下文和 GitHub Flow 工作分支时使用。 不要用于已有完成 Spec 的小迭代（用 spec-update）或项目首次初始化（用 spec-init）。
当用户要求以「Agent 主控 + 全程 spawn 子 Agent」的方式启动 R&K Flow 开发流程时使用： 当前 Agent 只做编排（账本、门禁代问、批次调度），七个角色的实质工作一律交子 Agent 执行。 典型信号：用户说"用 swarm 模式启动"/"蜂群模式"/"所有任务都 spawn 子 Agent 做"/"你只做主控不要自己写代码"。 本 Skill 只做前置校验、写入 execution 字段、声明编排硬约束，随后委派 spec-start 跑既有五阶段流程。 不要用于运行时不支持子 Agent 的环境（退回 spec-start 串行路径）、已有活跃 Spec 的小迭代（用 spec-update）， 也不要用它替代 spec-start —— 流程本体、账本模板、门禁定义仍由 spec-start 唯一承载。
当 spec-start 需要为新 Spec 创建 GitHub Flow 工作分支，spec-update 需要复用/校验当前 Spec 分支，或 spec-end/spec-update 需要提交、推送、创建 PR、合并后清理分支时使用。也用于发版管理：建立或维护 release 分支、打版本 tag、发补丁版本、把修复 cherry-pick 到多条发布线、核对 tag 与分支是否错位、对齐镜像标签与 git tag、清理带版本号的旧分支。不要用于单次查看 git 状态、普通 diff 查询，或用户明确要求不走 GitHub Flow 的临时操作。
基于 SOC 职业分类
正在显示 SKILL.md
| disable-model-invocation | true |
| name | spec-update |
| description | 当同一个活跃 Spec 在当前工作分支内需要小迭代、补充需求、修正方案或优化实现，且原 Spec 目录已有 writer/plan.html + executor/summary.html 时使用。默认复用 writer/plan.html 记录的 git_branch，不新建分支。不要用于新功能从零设计、已合并/已关闭分支上的后续需求，或需要独立 PR 的较大变更。 |
updater/ 下，禁止创建新的 Spec 根目录updater/update-001.html → updater/update-002.html → updater/update-003.html（三位数，不跳号）updater/update-xxx.html 定义的修改，不添加方案之外的内容git_branch，禁止为同一活跃 Spec 的小更新默认创建新分支data-rev 修订标记）；经验/知识记忆保持 Markdown（账本两种格式皆可）用户的期望是「还是那个 writer / tester 在跟我对话」，而不是每次 update 都换一批零历史的新实例。做法固定三步：
lead/team-context.md（或 .html）的「角色运行句柄」，取本 Spec 上次用的 agent_id 与状态。| 账本/实况状态 | 动作 |
|---|---|
running / idle / parked | 发消息给同一个 agent。parked 收到消息会自动复活且上下文完整，不需要任何额外操作 |
aborted | 只能重新 spawn 同一项目级角色，并让它先读账本与既有产物重建上下文 |
禁止用重新 spawn 代替续接。 运行时按 name 分配 agent id，同名再 spawn 会得到 spec-writer-2 这样的全新零历史实例——影子角色。续接成功后更新账本的「续接方式」与「累计参与 Spec 数」。
跨进程（omp 重启后）handle 可能已失效，此时账本与落盘产物是唯一恢复路径——这也是账本必须实时更新而非攒批的原因。
gated 模式下，以下三个节点必须使用当前运行环境的确认方式向用户确认。autopilot 模式下由各节点标注的机械证据替代，缺证据不得放行：
节点 1 — 更新方案确认（创建 updater/update-xxx.html 后）：
确认目标：updater/update-xxx.html 已创建完成，更新方案是否可以开始执行？
确认选项：
- 确认，开始执行
- 需要修改（请说明修改要求）
节点 2 — 审查报告确认（生成 reviewer/update-xxx-review.html 后）：
确认目标：reviewer/update-xxx-review.html 已创建完成，审查结果是否通过？
确认选项：
- 审查通过
- 需要修复（请说明问题）
节点 3 — 分支收尾确认（测试和审查通过后）：
确认目标：本次 update 已通过测试和审查。是否提交并推送当前 Spec 分支？如果该 Spec 已准备整体交付，是否创建/更新 PR？
确认选项：
- 确认，提交并推送
- 暂不提交
响应处理：选择确认选项 → 继续；选择修改/修复或"Other" → 根据用户反馈调整后重新确认。
两个模板的骨架、组件与修订标记规范由 html-report skill 定义；样式表相对路径按 updater/ 回到项目根的 4 层写作（../../../../html-report/assets/rk-report.css），项目层级不同需相应调整。
功能等价要求（不允许退化）：
<head> 里逐字段写 <meta name="rk:type|spec-dir|role|mode|update-number|status|update-type|created|updated|revision|git-branch|base-branch|pr-url|tags">，文档关联写 <link rel="rk-plan|rk-summary|rk-update|rk-update-summary|rk-review|rk-ledger" href="...">；.rk-meta 镜像同样字段（含基准分支与 PR）<ul class="rk-links"> + data-rk-link）与「引用本报告」（<ul class="rk-backlinks"> + data-rk-backlink）两个 h3；谁新建关联谁补对侧反链，对侧报告未产出时在 rk-links 标注（待创建）按 D-003（多实例部署需共享缓存）），纯笔误/措辞/补充直接写清原因，不编造编号；决策过程正文只留在 lead/team-context.md 的「决策记录」，不复制进报告writer/plan.html 和 executor/summary.html 都存在。若缺少 executor/summary.html，先用 spec-execute 完成原功能updater/ 下已有的 update-*.html，确定下一个编号；若 updater/ 不存在则创建writer/plan.html 头部 .rk-meta 的分支 / 基准分支 / PR 信息，调用 /git-work 的“复用 Spec 分支”模式，确认当前分支与 git_branch 一致updater/ 下创建；完整填写 rk:* meta 与 rk-* link，.rk-meta 镜像同样字段，并继承 writer/plan.html 的分支 / 基准分支 / PR 元信息/exp-search <关键词>updater/update-xxx.html 的"实现步骤"章节创建rk:* meta + rk-* link 双轨元信息、rk-verdict 结论块、rk-cal ok / rk-cal warn 组件、rk-links / rk-backlinks 双向关联，修订遵循 data-rev 规范；并继承 update 报告的 Git 元信息，同时在 update-xxx.html 的 rk-backlinks 补上本总结的反链reviewer/update-xxx-review.html；审查报告产出后，回到 update-xxx.html / update-xxx-summary.html 的 rk-backlinks 把「审查报告」反链补齐（原先标注「待创建」的条目同步去掉标注）/exp-reflect，并审查是否需要维护 AGENTS.md / .agents/rules/| 场景 | 解决方案 |
|---|---|
| 原 Spec 目录不存在 | 确认路径；若为新功能，用 spec-write + spec-execute |
缺少 executor/summary.html | 先用 spec-execute 完成原功能 |
| 回归测试失败 | 分析原因 → 修复回归代码 → 重新测试 → 全部通过后才能继续 |
当前分支不是 writer/plan.html 记录的 git_branch | 切回原 Spec 分支；若原分支已合并/删除，应新建 Spec 或询问用户是否创建独立分支 |
| 变更需要独立 PR | 不走默认 update 分支复用路径，询问用户是否新建 Spec 或显式创建独立分支 |
完成更新后：
/exp-reflect 进行经验反思AGENTS.md / .agents/rules/；只写长期规则，不写一次性实现细节updater/update-xxx-summary.html 添加经验引用（经验/知识文件本身保持 .md）/git-work 提交并推送当前 Spec 分支；只有当 Spec 准备整体交付时才创建/更新 PRwriter/plan.html / executor/summary.html / updater/update-xxx.html / updater/update-xxx-summary.html 并通过 amend + force-with-lease 并入同一次提交lead/team-context.md 的「任务进度」，必要时更新「问题闭环记录」和「决策记录」/git-work 的“完成 Spec 分支”模式，提交并推送；如果用户确认该 Spec 已准备整体交付，则创建/更新 PR；如获得 PR URL，写回 writer/plan.html / executor/summary.html / updater/update-xxx.html / updater/update-xxx-summary.html 的 .rk-meta（按修订规范递增修订号、追加修订历史行），并并入同一次提交（git commit --amend --no-edit + git push --force-with-lease），不产生第二次提交lead/team-context.md 的「任务进度」中追加或更新 spec-update 自己的更新任务行，「产物」指向 updater/update-xxx.html / updater/update-xxx-summary.html，「状态」标记为 done，填写 「完成时间」 和 updated_by: spec-update；若更新解决了问题，同步更新「问题闭环记录」（按性质填「分类」）；本次更新做的方案取舍（含是否仍在原 Spec 范围内的判断）在「决策记录」记一行