菜单
校验业务代码与 IDL 契约同步、字段冻结状态是否被破坏。作为 8 维度 code review 的"契约一致"维度，可被 design-checker / code-review-preparer 调用，也可独立运行。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | api-contract-consistency-validator |
| description | 校验业务代码与 IDL 契约同步、字段冻结状态是否被破坏。作为 8 维度 code review 的"契约一致"维度，可被 design-checker / code-review-preparer 调用，也可独立运行。 |
| allowed-tools | Read, Bash, Glob, Grep |
原文 §8.3 把契约一致定位为 Skill（不是 Agent），因为它是一组确定性检查——无需主观判断，只需机械比对 diff 与契约状态。
{
"feature_ids": ["FT-001"],
"commit_range": "abc..def",
"business_diff_path?": "...",
"idl_diff_path?": "..."
}
| ID | 检查 | 阻塞 |
|---|---|---|
| K1 | feature 标记 idl_change: true → IDL 仓必须存在对应 diff | YES |
| K2 | feature 标记 idl_change: false → 业务 diff 中不允许引用新 IDL 字段 | YES |
| K3 | IDL 中带 frozen: true 注释/标记的字段，禁止类型/语义变更 | YES |
| K4 | 业务代码引用的 IDL 字段必须存在（防止编译期不报但运行期 panic） | YES |
| K5 | 新增 IDL 字段必须有默认值或 optional 标记（向后兼容） | YES |
| K6 | detail-design.md 的"IDL 变更"小节覆盖了本次 IDL diff（字段一致、版本号一致） | YES |
| K7 | 同名分支策略：业务仓改 IDL 字段 → IDL 仓必须有同名分支 | YES（已在 4.3 门禁覆盖，这里再次确认） |
tasks/features.json → 找出 idl_change=true 的 featuresgit -C {idl-repo} diff 取 IDL diffgit -C {business-repo} diff 取业务 diff{
"skill": "api-contract-consistency-validator",
"verdict": "PASS|WARN|FAIL",
"findings": [
{ "id": "K3", "file": "{idl-repo}/coupon.jce", "line": 24,
"issue": "frozen 字段 user_ids 类型从 list<int> 改为 list<string>",
"suggestion": "新增 user_ids_v2 字段，保持兼容" }
]
}
code-review-preparer Agent 在阶段 4.4 把它作为第 6 维度调用detail-design-quality-reviewer 在阶段 3.3 调用其中 K5/K6 做设计期 IDL 预审/agentic:check-contract聚合 8 维度 review Agent 的产出，生成统一的 review 报告并写入 reviews/{ts}.md。
当 context/ 下新增/删除文件时，自动更新对应层级的 INDEX.md，避免"孤儿文件"。
按 templates/detail-design.md 模板撰写详细设计文档，包括数据模型、IDL 变更、接口设计、决策、错误处理、监控、灰度等。
运维操作中心（Operations Center）通用适配器——为团队的运营/运维操作（开关、灰度、限流、降级）提供统一调用约定。具体实现按团队接入。
DevOps CLI 通用适配器——把团队的部署/构建/发布命令包装成一致的高层接口。具体实现按团队接入。
当 requirements/{p}/{r}/ 下新增文档（design / review / experience 等）时，自动更新该需求的 INDEX 与摘要。