메뉴
执行完成后对照原始 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/补做/后置 |
| "代码存在"即"能力生效" | 查集成测试证明运行时行为 |
| 偏差不记录理由 | 每个偏差必须解释为什么实际方案更优 |