用途
retrofit 用于将已有工程改造为 keel 流程，或将旧版 keel 迁移到新规范。它不适合新项目（用 /pipeline init）或添加功能（用 /feature）。触发条件包括：用户希望将现有项目适配 keel 流程、需要标准化项目文档、要迁移或升级已有 keel 文档、项目缺少文档需要建立可维护的基线。
主要能力
- 项目状态检测：扫描项目结构，区分无 docs/devdocs/、基线已建（有 00-baseline.md 且无 01~04）、符合规范的 keel、旧版 keel 四种状态。
- 建立项目基线：在无 keel 文档时，通过调查、校验、推导、提问、落盘生成 docs/devdocs/00-baseline.md。
- 版本迁移：在已有 keel 但不符合规范时，执行规范检查、生成差异清单、用户确认、迁移执行（编号、重命名、追溯矩阵）。
- 规范升级回扫：通过 /retrofit --realign 对 00-baseline.md 按当前 baseline.v1 查漏补缺，只补结构，不改带来源标注的正文。
使用方式
最常见用法：/retrofit（自动检测项目状态）。
/retrofit --realign → 规范升级回扫，详见 references/realign.md；推荐用户入口 /pipeline realign。
工作流程：扫描项目结构 → 检测项目状态 → 呈现方案并用 AskUserQuestion 确认 → 执行（建立基线或版本迁移）→ 收尾。
版本迁移场景下，用户可选择完整迁移（推荐）、选择性迁移或仅生成差异报告。选择性迁移需用户指定具体迁移范围。
建立基线场景下，用户可确认调查结果开始建立基线、补充材料后再调查，或调整基线范围。
适用场景
- 已有项目缺少 keel 文档，需要建立可维护的基线。
- 已有旧版 keel 文档，需要迁移到新规范。
- 需要标准化项目文档。
限制
- 符合当前规范的项目直接告知无需改造并退出，不进入分支选择。
- 用户选择前只展示方案，不写入任何文件。
- 选择性迁移必须在用户指定迁移范围后才能执行，不可猜测范围。
- 基线草案落盘前必须展示带来源标注的草案供用户确认；用户未表态的条目保持“推导待确认”，不得升格。
- 00-baseline.md 不得出现模块表、接口表、数据对象表、依赖图、技术栈清单、目录结构树；不得出现当前分支、未提交改动、完成率、待办；不得出现没有来源标注的断言。
- 基线路径只产 00-baseline.md，不产 01~04。
- 文档阶段不得产出实现代码。
- Write 工具仅用于写入 docs/devdocs/ 下的 Markdown 文档，窄例外为委托 agent-memory 写其受管记忆文件。
与其他技能的边界
retrofit 与 realign 互补不重叠，以 frontmatter + spec_version 字段为主判据：文档顶部 YAML frontmatter 存在且含有效 spec_version → 归 realign；反之归 retrofit。
输出文件
基线路径：docs/devdocs/00-baseline.md（唯一产物）。附带由委托的 skill 各自产出 docs/codebase-insight.md、AGENTS.md 的领域术语与架构决策节。
版本迁移路径：docs/devdocs/00-retrofit-report.md 及按迁移范围更新的既有 01~04 文档。
协作技能
代码盘点委托 /codebase-insight；基线增量补全用 /requirements --context；需求审查用 /requirements；设计审查用 /system-design；测试用例用 /test-cases；新增功能用 /feature；Bug 修复用 /bugfix；测试质量用 /testing-guide；文件操作用 /git-safety。