用途
check-traceability 是 guardrails 提供的可追溯性检查技能，用于运行并解读两个检查脚本，发现需求、危害、控制、设计、测试之间的追溯缺口，包括孤立需求、未缓解危害、未实现控制、未追溯的设计、悬空引用等。
主要能力
该技能运行两个检查器：
.guardrails/scripts/check-trace.sh：执行可追溯性门禁.guardrails/scripts/check-ids.sh：执行 ID 合法性检查（DRAFT-ID、DRAFT-FILE、DUPLICATE-ID、MALFORMED-ID）
运行后需读取退出状态和摘要行。每个 check-trace.sh 运行结束会输出两行摘要：checked: 列出各类项目计数，sources: 列出打开的文件数。退出码为 0 且仅有两行摘要表示干净。如果项目有需求但 REQ 0，或项目有 RMF 但 rmf 0，说明检查器没有找到任何内容，是配置或布局问题，而非通过。
使用方式
在仓库根目录运行上述两个命令。退出码 2 是环境错误，表示某个门禁未能运行，必须读取 references/config.md 修复配置后重跑，不得通过从 id_prefixes 中移除前缀来绕过。
每个违规输出为一行 <RULE> <ID> (<detail>)，随后按触发的规则打印 fix <RULE>: <what to do> 提示行。应在工件中修正违规，而非修改检查器。规则详情可查看脚本头部或对应参考文档。
编写条目正文时需注意块规则：条目块从定义形式开始，到下一个 Markdown 标题或下一个包含 ASCII 冒号的粗体行结束。注释应写在条目块内，且不带列表标记；带列表标记的注释会被视为缺失字段。implements: 和 mitigates: 仅在所属块内的行上才产生覆盖信用。ORPHAN-ANNOTATION 表示注释不属于任何条目，MISPLACED-ITEM 表示条目出现在错误的文档中。
适用场景
在修改 SRS、RMF、SAD、SOUP 或测试文件后运行；在 merge-change 中步骤 6a 门禁为 verify-before-merge 时运行；在 CI 中对每次合并运行。
限制
缺少事实：该技能的收费、价格、平台支持等暂未提供。该技能依赖 .guardrails 配置和脚本存在，项目需有相应文档结构才能产生有效检查结果。