菜单
把算子任务书拆成原语组合、按 rule-catalog 拉每原语的必测 case 模式、实例化去重后出「功能/精度/性能」覆盖矩阵——OpRunway 验收 Task1 用例生成的展开规则。参考草案：尚未接入 op-acceptance live 流、勿自动触发；仅在需理解或扩展「任务书→用例集」的展开规则时阅读。live 用例生成由确定性 gen_cases.py 负责。
用 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 首响应加载。
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）。需要读懂或扩展精度判定口径、排查精度裁决时阅读。
OpRunway 验收里任何 FAIL 归因前的解耦纪律薄壳——先验证「任务书↔PR 对应」本身，再用被测物自己的东西（自 build + 声明 dtype + 手算 golden + custom↔builtin 对照）解耦「被测物 vs 我们的 harness」，才下归因。P2 规划的原子能力 skill：尚未接入 op-acceptance live 流、勿自动触发、无脚本判定（纪律 skill，不产 verdict）。真机 FAIL 要归因、或复盘一次归因翻案时阅读。
| name | acc-casegen |
| description | 把算子任务书拆成原语组合、按 rule-catalog 拉每原语的必测 case 模式、实例化去重后出「功能/精度/性能」覆盖矩阵——OpRunway 验收 Task1 用例生成的展开规则。参考草案：尚未接入 op-acceptance live 流、勿自动触发；仅在需理解或扩展「任务书→用例集」的展开规则时阅读。live 用例生成由确定性 gen_cases.py 负责。 |
定位（诚实）：本 skill 是落地设计 P2 规划的原子能力 skill（原子切分 = casegen / precision / perf / rootcause 四个能力薄壳），承载 canon Primitive-to-case rule library（canonical）里「展开逻辑 = SKILL.md、目录 = references/rule-catalog.md」划分中的展开逻辑部分。当前尚未接入 op-acceptance live 编排流：真实运行时的用例生成走确定性脚本 ${OPRUNWAY_PLUGIN_ROOT}/acc-common/gen_cases.py（${OPRUNWAY_PLUGIN_ROOT} = 本插件根中立变量，Claude 下等价 ${CLAUDE_PLUGIN_ROOT}）——本 skill 不落盘 caseset.json、不调用也不替代 gen_cases.py，只描述「一个算子该测哪些用例、为什么」的推理规则；pass/fail 判定唯一归确定性 validator、不在本 skill（ADR 0007）。
plugin/AGENTS.md 的 skills: 清单——登记 = 声称已接入 live 流，而本 skill 未接入（op-acceptance 的 live 用例生成仍走 gen_cases.py）。分发 / 发现由 init.sh 扇出保证（它 symlink plugin/skills/ 下全部 skill 目录、不依赖 AGENTS.md 登记），故不登记不影响可移植分发。待 P1 / 后续真正接进 runtime 调用链时再登记；本 skill 勿被自动触发。gen_cases.py 现按算子从用户侧 <ops_root>/<op>/golden.py 加载 golden（elementwise 通路不再内置 golden 值、缺则 fail-closed；ADR 0011 golden 去引擎化，proposed）。⚠ 别读成「引擎零内置算子」（2026-07-22 更正）：catlass_adapter.py:152/:162 的内置 matmul golden 与 gen_cases.py:34 的 _BF16_EXACT_OPS 按算子名硬表是两处已知例外，仍在引擎里，但仍不是 rule-catalog 驱动的通用 generator。「rule-catalog → 通用 generator」是 canon 目标态 / 独立后续 todo，本 skill 不声称当下可对任意算子自动落 caseset（且 golden.py 须先由 acc-runner-dev:gen_golden 从任务书产出，手册 skills/acc-runner/references/golden-authoring.md）。输入：算子任务书（公式 / 功能 / 规格 / dtype / shape / 属性 / 精度目标 / 性能目标）+（可选）PR 事实。 输出（说明性）：一份覆盖矩阵推理——原语 × tag × 三轴（dtype / 特殊值 / layout·对齐·tiling·workspace），每条用例标清「测什么形状 / 什么数据 / 为什么 / 走哪个 compare 分支 / 对应任务书条款」；缺口 / 不可达显式列出（no silent 漏项）。
references/rule-catalog.md）identify_by）。UNCOVERED_PRIMITIVE 缺口项并中止 / 降级，禁止静默归并进 matmul。mandatory case 模式，叠加跨切面（dtype / 特殊值 / layout / 对齐 / tiling / workspace），按三轴叠加策略、非全组合。kind 取并集、tolerance / timing 取最严来源、case_origin 记全部来源）；打全标签、标 golden 来源、升级 precision、选 performance；输出覆盖矩阵，缺口 / 不可达显式列出。caseset.json、不算 pass/fail（判定归确定性 validator，ADR 0007）。gen_cases.py：live 用例生成的确定性活在 gen_cases.py；本 skill 是其规则依据的人读版，尚未接入编排。详规见 references/rule-catalog.md（11 原语 + 元规则 + 跨切面 dtype/layout/tiling + 组合规则）。