ワンクリックでManusで任意のスキルを実行

acc-rootcause

スター0

フォーク0

更新日2026年7月9日 06:37

OpRunway 验收里任何 FAIL 归因前的解耦纪律薄壳——先验证「任务书↔PR 对应」本身，再用被测物自己的东西（自 build + 声明 dtype + 手算 golden + custom↔builtin 对照）解耦「被测物 vs 我们的 harness」，才下归因。P2 规划的原子能力 skill：尚未接入 op-acceptance live 流、勿自动触发、无脚本判定（纪律 skill，不产 verdict）。真机 FAIL 要归因、或复盘一次归因翻案时阅读。

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

lllyys

lllyys/OpRunway

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

acc-rootcause — FAIL 解耦纪律（原子能力 skill）

定位（诚实，P2 边界）：本 skill 是 P2 规划的纪律 skill——只装「FAIL 该怎么归因、什么前提下才能下结论」的推理纪律，无脚本判定、不产 verdict、不落盘。裁决仍唯一归确定性脚本链（validator.py / perf_compare.py / validate_acceptance_state.py，ADR 0007 canonical）；本 skill 只约束「下结论前先做什么解耦」。

未登记进 AGENTS.md（诚实先例）：本 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 勿被自动触发。
血教训来源：Equal（2026-07-08→07-09 三度翻案），见 canon Verify spec-PR correspondence before acceptance（proposed）+ Root-cause decoupling before attribution（proposed）。

0. 更上游前提（比解耦更早）· 先验证「任务书↔PR 对应」本身

任何 FAIL 归因、乃至任何验收裁决之前，先确认：

这个 PR 确是这份任务书的交付 PR（靠 issue/追踪号 + 改动落点目录，不靠算子名字面匹配——名字常是常见子串、易误配）；
该任务确有已验收的交付（不是「任务书要了但未落地/未验收」的空任务）。

配错对应、或对应的其实是空任务 → 下游一切裁决作废，哪怕精度/性能门再严、解耦做得再干净。识别并跳过「未验收空任务」正是 OpRunway 的应有能力。（Equal：#2890 系误配、Equal 社区任务未验收，前「A3 真阳性」结论整体作废——refine 了三遍归因，却始终没质疑最上游。）

1. 解耦纪律（对应确认后，归因前）· 被测物 vs 我们的 harness

「输出全 0 / 未被写」既可能是 harness 没绑定/没回写，也可能是被测 kernel 压根没执行/没写——区分靠对照，不靠直觉：

同一份 runner 换内置 op 做对照：输出正确 → runner/harness 清白、锅在被测 op；仍错 → 才轮到查 harness。
跑被测物自带的 example（官方调用样例）：它对 → 被测物本身可用；它也错 → 被测物真坏。
查已编 vendor 包制品（op-info / kernel binary 是否真生成）：制品缺失即实锤。
dtype 逐个做 op 级测：分清整体不通还是某 dtype 路不通。
被测物自 build + 声明支持的 dtype + 手算 golden 独立复现：小用例逐元素比，坐实范围。

2. 下结论的红线

源码「一行诊断」须经真机重编坐实范围：读源码得「缺一行、一处即修」是假设、非结论——补上重编后可能暴露更深缺陷（补一处、另一处仍炸）。范围以真机复现为准。
技术判定与官方/程序口径分开记：「实测是被测物缺陷」是技术判定、可下；「是否算官方验收失败 / 该不该对外上报」是程序口径，未确认前留口、不外发、不来回改口。
验收职责边界：把缺陷定性清楚即可，不替被测 PR 作者把算子修到底。
裁决归脚本：本 skill 不产 pass/fail；解耦结论供人/编排理解，最终 verdict 仍由确定性脚本链出（ADR 0007）。

详规见 references/rootcause-decoupling.md（对应校验三证据 · 解耦四对照 · 全 0 决策树 · 归因红线，按 canon tier 引）。

このリポジトリの他の Skills

同じリポジトリ

acc-spec

lllyys/OpRunway

把算子任务书（md 本地路径或链接）+ PR 链接，抽成中立的 <op>.spec.json（OpRunway 验收流水线 Layer 0 契约）。当你拿到「算子任务书 + 对应 PR」要开始 NPU 算子验收、或需要从任务书生成 spec 时用。一份任务书含多个算子时产出多份 spec。规则由真实社区任务书语料归纳、经三个已建 spec 验证。

2026-07-230

acc-runner

lllyys/OpRunway

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）。

2026-07-230

acceptance-workflow

lllyys/OpRunway

OpRunway 算子验收编排的 CP-A..E 检查点状态机——定义薄 primary orchestrator 如何调度 3 个 subagent、串工件门禁、把 pass/fail 判定唯一交给确定性脚本链（validator/perf_compare/三级验收门），供 op-acceptance primary 首响应加载。

2026-07-230

acc-casegen

lllyys/OpRunway

把算子任务书拆成原语组合、按 rule-catalog 拉每原语的必测 case 模式、实例化去重后出「功能/精度/性能」覆盖矩阵——OpRunway 验收 Task1 用例生成的展开规则。参考草案：尚未接入 op-acceptance live 流、勿自动触发；仅在需理解或扩展「任务书→用例集」的展开规则时阅读。live 用例生成由确定性 gen_cases.py 负责。

2026-07-220

acc-perf

lllyys/OpRunway

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）。需要读懂或扩展性能对比口径、排查性能裁决时阅读。

2026-07-090

acc-precision

lllyys/OpRunway

OpRunway 验收精度维的方法论薄壳——oracle 分层（谁当真值）+ dtype 分层度量（哪套标准、什么口径），供理解「一个算子的精度该怎么判、为什么」。P2 规划的原子能力 skill：尚未接入 op-acceptance live 流、勿自动触发、不落盘、不算 pass/fail（判定唯一归确定性 validator.py + precision_policy.py，ADR 0007）。需要读懂或扩展精度判定口径、排查精度裁决时阅读。

2026-07-090

name

acc-rootcause

description

acc-rootcause — FAIL 解耦纪律（原子能力 skill）

未登记进 AGENTS.md（诚实先例）：本 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 勿被自动触发。
血教训来源：Equal（2026-07-08→07-09 三度翻案），见 canon Verify spec-PR correspondence before acceptance（proposed）+ Root-cause decoupling before attribution（proposed）。

0. 更上游前提（比解耦更早）· 先验证「任务书↔PR 对应」本身

任何 FAIL 归因、乃至任何验收裁决之前，先确认：

这个 PR 确是这份任务书的交付 PR（靠 issue/追踪号 + 改动落点目录，不靠算子名字面匹配——名字常是常见子串、易误配）；
该任务确有已验收的交付（不是「任务书要了但未落地/未验收」的空任务）。

1. 解耦纪律（对应确认后，归因前）· 被测物 vs 我们的 harness

「输出全 0 / 未被写」既可能是 harness 没绑定/没回写，也可能是被测 kernel 压根没执行/没写——区分靠对照，不靠直觉：

同一份 runner 换内置 op 做对照：输出正确 → runner/harness 清白、锅在被测 op；仍错 → 才轮到查 harness。
跑被测物自带的 example（官方调用样例）：它对 → 被测物本身可用；它也错 → 被测物真坏。
查已编 vendor 包制品（op-info / kernel binary 是否真生成）：制品缺失即实锤。
dtype 逐个做 op 级测：分清整体不通还是某 dtype 路不通。
被测物自 build + 声明支持的 dtype + 手算 golden 独立复现：小用例逐元素比，坐实范围。

2. 下结论的红线

源码「一行诊断」须经真机重编坐实范围：读源码得「缺一行、一处即修」是假设、非结论——补上重编后可能暴露更深缺陷（补一处、另一处仍炸）。范围以真机复现为准。
技术判定与官方/程序口径分开记：「实测是被测物缺陷」是技术判定、可下；「是否算官方验收失败 / 该不该对外上报」是程序口径，未确认前留口、不外发、不来回改口。
验收职责边界：把缺陷定性清楚即可，不替被测 PR 作者把算子修到底。
裁决归脚本：本 skill 不产 pass/fail；解耦结论供人/编排理解，最终 verdict 仍由确定性脚本链出（ADR 0007）。

详规见 references/rootcause-decoupling.md（对应校验三证据 · 解耦四对照 · 全 0 决策树 · 归因红线，按 canon tier 引）。