القائمة
功能完整性审查。当需要验证代码是否实现了 spec 的所有需求，或提到"spec compliance""功能完整性""需求覆盖"
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
结构化脑暴——发散探索 + 收敛评估。当想法模糊、面临开放性问题或需要方案对比，或提到"脑暴""想法""方案对比""怎么办"
恢复保存的工作上下文。当新 session 需要继续之前的工作，或提到"恢复""restore""继续上次"
保存工作上下文。当需要保存当前工作状态供后续 session 恢复，或提到"保存""save""checkpoint""挂起"
架构决策记录（ADR）。当面临技术选型、架构决策、方案取舍需要记录，或提到"ADR""决策记录""为什么这样做"
发布或导出检查 → Go/No-Go → 归档。当审查通过后需要上线或交付最终产物，或提到"发布""上线""ship""Go/No-Go"
合并 PR → 等待 CI → 验证生产。当 PR 已创建需要合并到主分支并验证部署，或提到"合并""merge""PR""land"
| name | verify-workflow-spec-compliance |
| description | 功能完整性审查。当需要验证代码是否实现了 spec 的所有需求，或提到"spec compliance""功能完整性""需求覆盖" |
verify-quality-code-quality；不通过 → 退回 build 补齐功能docs/features/YYYYMMDD-<name>/04-review.md（合规性部分） → verify-quality-code-quality（通过时）或 build-workflow-execute（不通过时退回补齐）references/spec-compliance-examples.md（需求提取示例、验证标记示例、完整虚构报告、边界判断说明）每个 spec 需求必须建立 spec 行号 → 代码实现 → 测试 的可追溯链。
执行规则：
[spec:LXX] + 实现文件路径 + 测试文件路径references/spec-compliance-examples.md §1-2100% 覆盖是通过的唯一标准。任何缺口 = 不通过。
执行规则：
任何代码中实现但 spec 未提及的用户可见功能 = scope creep。
执行规则：
spec 明确要求的 = Spec Compliance（本技能）；spec 未提及但应该有的 = Code Quality（verify-quality-code-quality）。
执行规则：
标准路径：docs/features/YYYYMMDD-<name>/01-spec.md；Bug 修复：docs/bugs/<name>/01-root-cause.md + 02-fix-plan.md。找不到 spec 时询问用户或要求先创建 spec。
Checkpoint：spec 文档已定位。
逐行读取 spec，按四类提取所有需求，每条标记 [spec:LXX]。
Checkpoint：所有功能需求、边界条件、错误场景、验收标准已提取，无遗漏。
对每个需求在代码中查找对应实现。功能需求搜函数/组件/API；边界条件查 if/guard；错误场景查 try/catch；验收标准查测试。
Checkpoint：每条需求已标记 实现路径 + 测试路径。
检查代码中 spec 未提及的用户可见功能。
Checkpoint：每个 scope creep 项已标记 + 判断理由。
汇总覆盖率，按 Coverage-Gated Review 判定通过/不通过。
Checkpoint：报告已生成，判定结果明确，不通过时有遗漏清单和修复建议。
| 说辞 | 现实 | 后果 |
|---|---|---|
| "功能基本实现了，细节之后补" | "基本实现"= 不完整。spec 是契约。 | "之后补"平均 = 永不；用户遇到缺失功能时紧急修复成本 10x |
| "边界情况很少见，可以不处理" | 边界条件是 spec 明确要求的。 | "很少见"的边界在最糟时刻爆发（演示、发布） |
| "测试之后补，先合代码" | 没有测试 = 无法验证正确性。 | "之后补测试"的代码 90% 永远不会有测试 |
| "spec 没写但用户肯定需要" | 未经批准的功能 = scope creep。 | 可能与产品方向冲突；合入后移除成本远高于合入前讨论 |
| 失败场景 | 处理方式 |
|---|---|
| 功能需求覆盖率 < 100% | 退回 build，提供遗漏清单和修复建议 |
| 边界条件缺失 | Critical — 必须在合并前实现 |
| 验收标准缺少测试 | Critical — 补写测试后才可通过 |
| Scope Creep 未解释 | human partner 判断：收入 spec 或移除代码 |
| spec 描述模糊无法验证 | 暂停审查，澄清 spec 后再继续 |
| 实现方式与 spec 不一致 | 标记差异，human partner 判断 |
逐条提取 spec 需求，每条标注 spec 行号、代码实现位置、测试位置。覆盖率 100% 才通过；遗漏项有修复建议和影响说明。
跳过逐条对照，声称"功能基本实现"但实际有遗漏。无 spec→代码映射，无覆盖率计算，遗漏的边界条件和验收标准在生产以 bug 形式爆发。
完整虚构报告示例见 references/spec-compliance-examples.md §4。
### Spec Compliance — <feature-name>
**Spec**: [01-spec.md 路径] | **时间**: [YYYY-MM-DD] | **结果**: PASS / FAIL
**覆盖率**: 功能 [X/Y] | 边界 [X/Y] | 错误 [X/Y] | 验收 [X/Y] | **总 [X/Y]**
**遗漏（Critical）**:
| # | spec 行号 | 需求 | 状态 | 影响 | 建议 |
|---|----------|------|------|------|------|
| 1 | [L12] | [需求] | [缺失] | [影响] | [建议] |
**Scope Creep**: [列表 / 无] | **测试缺口**: [列表 / 无]
**下一步**: [通过 → code quality / 不通过 → 回 build 补齐]