菜单
执行完成后对照原始 RFC/Plan 检查遗漏和偏差。 触发场景：(1) 用户说"gap analysis"、"对照方案检查"、"完成度评估"、"遗漏检查"； (2) TDD 执行完成后需要系统化验证覆盖度； (3) 发布前确认所有承诺的能力都已兑现。 不适用于：代码级 review（用 requesting-code-review）、测试验证（用 verification-before-completion）。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work. In this repository, package or lane branches must close through package-first evidence and integration handoff rather than the generic local merge or PR menu.
Use when executing repo-wide or lane-scoped SDK changes in this repository that must follow bounded change packages, qiniu-ai worktree/package commands, evidence bundles, review packets, promotion decisions, and integration-branch handoff. Trigger on requests to open a phase package, spawn or integrate a lane, prepare a review handoff, or land multi-subsystem SDK work without widening scope.
Four-phase debugging framework that ensures root cause investigation before attempting fixes. Never jump to solutions.
Use when starting feature work that needs isolation from the current workspace or before executing implementation plans. In this repository, prefer qiniu-ai worktree commands for lane or package-first delivery; fall back to generic git worktree flows only for non-package branches.
Run verification commands and confirm output before claiming success
Use when you have a spec or requirements for a multi-step task, before touching code. In this repository, multi-subsystem or lane-scoped work must create the package brief first and keep the plan aligned with the bounded package contract.
基于 SOC 职业分类
| name | gap-analysis |
| description | 执行完成后对照原始 RFC/Plan 检查遗漏和偏差。 触发场景：(1) 用户说"gap analysis"、"对照方案检查"、"完成度评估"、"遗漏检查"； (2) TDD 执行完成后需要系统化验证覆盖度； (3) 发布前确认所有承诺的能力都已兑现。 不适用于：代码级 review（用 requesting-code-review）、测试验证（用 verification-before-completion）。 |
对照原始 RFC/Plan 系统化检查实现完整度。
读取原始 RFC/implementation_plan，提取所有可交付项：
对每项输出分类：
| 状态 | 含义 | 要求 |
|---|---|---|
| ✅ 完成 | 实现 + 测试均到位 | 标注验证方式 |
| ⚠️ 偏差 | 实现了但和 RFC 不完全一致 | 标注偏差原因 |
| ❌ 遗漏 | RFC 承诺但未实现 | 判断是 bug 还是需补做 |
| ⏭️ 有意后置 | 确认不在本轮范围 | 标注后置原因和触发条件 |
## Gap Analysis: [RFC/Plan 名称]
### 总览
- 总承诺项：N
- ✅ 完成：X / ⚠️ 偏差：Y / ❌ 遗漏：Z / ⏭️ 后置：W
### 详细对比
| # | RFC 承诺 | 状态 | 证据/说明 |
|---|---------|------|---------|
| 1 | ... | ✅ | 测试: xxx.test.ts |
| 2 | ... | ❌ | 需要补做 |
| 3 | ... | ⏭️ | 依赖后端 API，Phase 5 |
### 行动项
- [ ] 补做项 1：...
- [ ] 补做项 2：...
### 结论
[ ] Phase X 完整闭合，可发布
[ ] 有 N 项需补做，完成后可发布
| 反模式 | 正确做法 |
|---|---|
| 只检查"做了什么" | 必须检查"RFC 说了什么但没做" |
| 遗漏项默认后置 | 每个遗漏必须显式判断是 bug/补做/后置 |
| "代码存在"即"能力生效" | 查集成测试证明运行时行为 |
| 偏差不记录理由 | 每个偏差必须解释为什么实际方案更优 |