yisean 校验阶段：spec 产出物一致性体检
当前年份 2026。
这是横切流水线的只读校验 skill。它不产出新文档、不改任何产出物，只把同一特性（同一 NNN）的 PRD / 原型 / 设计 / plan 摆在一起，沿可追溯链逐项核对，输出一份带定位与修法的体检报告。类比 spec-kit 的 /analyze。
铁律：只读。 spec-check 只报告问题、指出该跑哪个 skill 修，绝不自己改 PRD/原型/设计/plan/代码——保持「先文档后实现、改动走对应 skill」的单一事实源纪律。需求层面的修复回
/spec-prd或/spec-change，设计层面的回/spec-design，实现层面的回/spec-plan。
术语提示
功能需求用 R/F 编号、验收用 AE/AC 编号、计划里的实现单元用 U 编号（详见 /spec-prd、/spec-plan）。可追溯链：R/F（要做什么）→ U（怎么做）→ AE/AC（怎么算做对了）。本 skill 校验的就是这条链有没有断、有没有悬空。
核心原则
- 只读不改 — 见上铁律。
- 沿同一 NNN 横切 —
prd/…-NNN-*↔prototype/*↔design/…-NNN-*↔plans/…-NNN-*↔migration-*必须对得上。 - 覆盖矩阵是判据 — 校验直接复用 PRD/plan 里已落盘的覆盖矩阵；矩阵缺失也照样从正文现抽一份来对。
- 定位 + 修法 — 每个问题都给「在哪、为什么是问题、怎么修、该跑哪个 skill」，不只说"有问题"。
- 右尺寸 — 没有 plan/原型的早期特性，只校验已存在的产出物，缺的阶段标"未到"而非报错。
- 只管文档一致性，不查代码规约 — 本 skill 校验的是 spec 产出物（PRD/原型/设计/plan/migration）之间对不对得上。命名/注释/分层/前后端编码规约属编码期，由
/code-review·/ce-code-review对照constitution「工程基线」与项目CLAUDE.md把关，不在 spec-check 范围（它也读不到业务代码）。
执行流程
Phase 0 · 定位特性与产出物
- 由
$ARGUMENTS确定目标：可以是NNN、PRD 路径、或特性名；留空则取docs/product/prd/中最近status: active的一份，回显「正在体检 NNN-，对不对？」。 - 沿同一
NNN找齐（存在才纳入，不存在标记「未到/不适用」）：docs/product/prd/…-NNN-*.md（必需，找不到则停下报错）docs/engineering/prototype/（涉及界面的页面 +index.html）docs/engineering/design/…-NNN-*.md（技术设计：架构/接口/ER/详细设计）docs/engineering/plans/…-NNN-*.mddocs/ops/install/migration-*.sql
- 读
docs/engineering/constitution.md（工程宪法 / 原则）与docs/engineering/workflow.md（命名与追溯约定）作为最高判据（存在则覆盖下面的内置默认）；读docs/engineering/registry.md（NNN 取号登记表，供 C8b 核对）。 - 体检以本特性单一 NNN 为主；唯有 C16「跨特性引用一致」会按需到全
docs/做文本检索、读别的 NNN 产出物——但仍是只读，不改任何文件。
Phase 1 · 抽取编号与映射
从各产出物现抽出事实，建一张内存中的映射：
- PRD：全部
R/F（及其文字）、全部AE/AC及其括号里标注覆盖的需求号、是否有「非功能约束」节、frontmatter（status/date/origin）。 - 设计：接口清单、ER 模型的实体/字段、详细设计覆盖的
R/F、frontmatter（origin应指向 PRD）。 - plan：全部实现单元
U及各自的覆盖需求（实现哪些R/F）、设计依据（指向 design 的小节）与 Test scenarios（对应哪些AE/AC）、frontmatter（origin应指向设计）、引用的 migration。 - 原型：现有页面清单 +
index.html入口、各页面对应的R/F（若标注）。
Phase 2 · 逐项检查（给每项判 PASS / WARN / FAIL）
| # | 检查项 | 不通过判级 |
|---|---|---|
| C1 | 编号规整：R/F、AE/AC、U 各自无重复、无重排迹象；断号有解释（如某号已废弃） |
重复/重排=FAIL；裸断号=WARN |
| C2 | 验收覆盖：每条 R/F 至少被一条 AE/AC 覆盖（除非显式标为非目标） |
FAIL |
| C3 | 验收不悬空：每条 AE/AC 括号里的需求号都真实存在，且至少指向一条 |
FAIL |
| C4 | 实现落地（有 plan 时）：每条 R/F 至少落到一个 U（除非非目标） |
FAIL |
| C5 | 单元不悬空（有 plan 时）：每个 U 的覆盖需求都指向存在的 R/F |
FAIL |
| C6 | 验证闭环（有 plan 时）：每个 U 的 Test scenarios 指向存在的 AE/AC |
WARN |
| C7 | NFR 在位：PRD 有「非功能约束」节（无则该节显式写「无特殊要求」也算通过） | WARN |
| C8 | 跨文档一致：prd / design / plan / migration 同 NNN；frontmatter status 合理（如 plan 已 done 但 PRD 还 active 要提示）；origin 链 plan→design→prd 指向真实存在的文件或写了来源简述 |
不一致=WARN |
| C8b | 取号登记一致（有 registry.md 时）：本特性 NNN 在 docs/engineering/registry.md 有登记、且该号未被两条记录重复占用；status 与 PRD/plan 现状不矛盾（如特性已交付但登记仍 reserved）。registry 缺失则标「未建登记表」并提示多人协作建议补上 |
号未登记/被重复占用=FAIL；status 不符=WARN |
| C9 | 原型覆盖（有原型时）：每条 UI 相关 R/F 有对应页面，且页面都挂进了 index.html |
缺页面=WARN |
| C10 | 数据一致（有 design + plan 时）：设计的 ER 模型实体/字段与 migration sql 的表大致对得上（粗检字段/表名） | WARN |
| C11 | 设计落地（有 plan 时）：有设计文档；每个 U 的「设计依据」指向设计里真实存在的小节；设计的接口清单覆盖的 R/F 都进了某个 U |
缺设计=WARN；悬空设计依据=WARN |
| C12 | 回滚段在位（有 migration 时）：migration 脚本含回滚/down 段（或显式写「无」）；不能只有 up 没有撤回说明 | 缺回滚段=WARN |
| C13 | 时间戳规约（有 migration 时）：新建业务表带创建/更新时间戳两列（命名沿用项目惯例，如 create_time/update_time）；豁免的表（字典/只读/中间表）在设计或脚本里注明原因 |
缺时间戳且无豁免说明=WARN |
| C14 | 字段长度一致（有 design + migration 时）：设计/接口契约标注了字符串字段的最大字符数；migration 的列长与之一致（按所选库语义：MySQL varchar(N) 按字符 / Oracle varchar2(N CHAR) / 达梦 等，见 constitution #9） |
漏标或与列长不一致=WARN |
| C15 | 设计章节完整（有 design 时，涉及才查）：涉及界面的特性 design 有「前端设计」节；占名额/高频写场景有「并发与幂等」；多角色特性有「权限」相关设计 | 该有却缺=WARN |
| C16 | 跨特性引用一致（事后兜底）：本特性对外暴露的接口/表/字段/共享原型组件，去全 docs/ 检索是否有别的 NNN 仍引用了已不存在或已改签名的旧版本；本特性对外依赖的接口/表，确认对方 NNN 现状仍提供 |
悬空跨特性引用=WARN |
Phase 3 · 输出体检报告
报告结构：
总判定一行：
✅ 通过/⚠️ N 项提示/❌ N 项必修 + M 项提示。覆盖矩阵总表（现抽或复用已落盘的），把断链行用
⚠️/❌标出：需求 验收 实现单元 状态 R8 AE2、AE5 U2、U3 ✅ R9 —— U4 ❌ 漏验收 R10 AE7 —— ❌ 漏实现 问题清单（先 FAIL 后 WARN），每条：
[检查项] 位置 → 为什么是问题 → 怎么修 → 跑哪个 skill。- 例：
[C2] R9（PRD §2 第 9 条）没有任何 AE/AC 覆盖 → 补一条标注（R9）的验收，或降级为非目标 → /spec-change。
- 例：
Phase 4 · 交接（修复建议，不自己改）
按问题归属给出该跑的命令，等用户决定：
- 需求/验收层（漏验收、悬空 AE/AC、NFR 缺、编号要续编）→ 已上线/在研特性走
/spec-change；尚未定稿的新 PRD 走/spec-prd。 - 设计层（缺设计文档、接口/详细设计缺、ER 与 migration 不一致、单元「设计依据」悬空）→
/spec-design。 - 实现层（漏实现单元、单元悬空、Test scenarios 缺、migration 未落）→
/spec-plan。 - 原型层（UI 相关需求缺页面、入口未挂）→
/spec-prototype。 - 全部通过 → 明确告知「可追溯链完整，可进入下一阶段」。