菜单
OpRunway 验收里任何 FAIL 归因前的解耦纪律薄壳——先验证「任务书↔PR 对应」本身，再用被测物自己的东西（自 build + 声明 dtype + 手算 golden + custom↔builtin 对照）解耦「被测物 vs 我们的 harness」，才下归因。P2 规划的原子能力 skill：尚未接入 op-acceptance live 流、勿自动触发、无脚本判定（纪律 skill，不产 verdict）。真机 FAIL 要归因、或复盘一次归因翻案时阅读。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
把算子任务书（md 本地路径或链接）+ PR 链接，抽成中立的 <op>.spec.json（OpRunway 验收流水线 Layer 0 契约）。当你拿到「算子任务书 + 对应 PR」要开始 NPU 算子验收、或需要从任务书生成 spec 时用。一份任务书含多个算子时产出多份 spec。规则由真实社区任务书语料归纳、经三个已建 spec 验证。
OpRunway 验收的代码产出 skill，两件事：(a) gen_golden——据任务书为任意算子产 <ops_root>/<op>/golden.py（真值口径走两档链、PR/仓内参考实现禁作 golden 源、后端生成期定死、check_golden.py 自检），纯 CPU、不需 NPU、不受 runner scope gate 约束；(b) gen_runner/verify_runner——为 ops-<族> 仓、aclnn 两段式接口、opp 安装型的算子（含非 experimental 子树，引擎目录/后缀已生成化），据 spec + PR 事实（算子自带 example + op_def）生成一个「锚定算子实测路径」的 per-op NPU runner（oprunway_<op.lower()>_runner.cpp），并按 runner 自检证据满足/不满足 纪律（未满足则停在 CP-C、不上真机）后才交真机跑测。OpRunway 验收 ③：spec 已就绪、要在真 NPU 上跑一个此类算子的正确性/性能时用。catlass（换构建体系）/非 aclnn 接口/双实现 当前不支持（需先扩 adapter，见 doc/oprunway-batch6b-design.md）。
OpRunway 算子验收编排的 CP-A..E 检查点状态机——定义薄 primary orchestrator 如何调度 3 个 subagent、串工件门禁、把 pass/fail 判定唯一交给确定性脚本链（validator/perf_compare/三级验收门），供 op-acceptance primary 首响应加载。
把算子任务书拆成原语组合、按 rule-catalog 拉每原语的必测 case 模式、实例化去重后出「功能/精度/性能」覆盖矩阵——OpRunway 验收 Task1 用例生成的展开规则。参考草案：尚未接入 op-acceptance live 流、勿自动触发；仅在需理解或扩展「任务书→用例集」的展开规则时阅读。live 用例生成由确定性 gen_cases.py 负责。
OpRunway 验收性能维的方法论薄壳——msprof kernel-only 采集 + timing_scope 必填同口径 + 基线按任务书参考源（TBE/GPU）+ 小 shape 例外，供理解「一个算子的性能该怎么比、为什么」。P2 规划的原子能力 skill：尚未接入 op-acceptance live 流、勿自动触发、不落盘、不算达标（比值/裁决唯一归确定性 perf_compare.py，ADR 0007 canonical；timing_scope 口径见 ADR 0006·proposed）。需要读懂或扩展性能对比口径、排查性能裁决时阅读。
OpRunway 验收精度维的方法论薄壳——oracle 分层（谁当真值）+ dtype 分层度量（哪套标准、什么口径），供理解「一个算子的精度该怎么判、为什么」。P2 规划的原子能力 skill：尚未接入 op-acceptance live 流、勿自动触发、不落盘、不算 pass/fail（判定唯一归确定性 validator.py + precision_policy.py，ADR 0007）。需要读懂或扩展精度判定口径、排查精度裁决时阅读。
| name | acc-rootcause |
| description | OpRunway 验收里任何 FAIL 归因前的解耦纪律薄壳——先验证「任务书↔PR 对应」本身，再用被测物自己的东西（自 build + 声明 dtype + 手算 golden + custom↔builtin 对照）解耦「被测物 vs 我们的 harness」，才下归因。P2 规划的原子能力 skill：尚未接入 op-acceptance live 流、勿自动触发、无脚本判定（纪律 skill，不产 verdict）。真机 FAIL 要归因、或复盘一次归因翻案时阅读。 |
定位（诚实，P2 边界）：本 skill 是 P2 规划的纪律 skill——只装「FAIL 该怎么归因、什么前提下才能下结论」的推理纪律，无脚本判定、不产 verdict、不落盘。裁决仍唯一归确定性脚本链（validator.py / perf_compare.py / validate_acceptance_state.py，ADR 0007 canonical）；本 skill 只约束「下结论前先做什么解耦」。
plugin/AGENTS.md 的 skills: 清单——登记 = 声称已接入 live 流，而本 skill 未接入（live 归因由 acc-verify-rootcause subagent（P1，dispatch_mode=rootcause）承载）。分发 / 发现由 init.sh 扇出保证（symlink plugin/skills/ 下全部 skill 目录、不依赖 AGENTS.md 登记）。待 P1 / 后续真接线再登记；本 skill 勿被自动触发。Verify spec-PR correspondence before acceptance（proposed）+ Root-cause decoupling before attribution（proposed）。任何 FAIL 归因、乃至任何验收裁决之前，先确认：
配错对应、或对应的其实是空任务 → 下游一切裁决作废，哪怕精度/性能门再严、解耦做得再干净。识别并跳过「未验收空任务」正是 OpRunway 的应有能力。（Equal：#2890 系误配、Equal 社区任务未验收，前「A3 真阳性」结论整体作废——refine 了三遍归因，却始终没质疑最上游。）
「输出全 0 / 未被写」既可能是 harness 没绑定/没回写，也可能是被测 kernel 压根没执行/没写——区分靠对照，不靠直觉：
详规见 references/rootcause-decoupling.md（对应校验三证据 · 解耦四对照 · 全 0 决策树 · 归因红线，按 canon tier 引）。