| name | run-audit |
| description | 审查/诊断 finesub 已完成的纠错翻译 run、reference_ingest run 与知识库健康：schema 违规、知识提案/反馈合规、成品字幕与精修对照的成类问题、以及 harness 运行时异常 （重试链、双提交覆盖等）。用户提到「审查 run」「诊断产物」「审计 out/reference」 「检查知识库」「这次跑得怎么样」「validation 为何失败」「为什么还重试」等时使用。 若目标是在固定测试床上改 prompt 并验收，不要用本 skill 代替迭代——改读 docs/prompt-iterate.md 与 session_replay。 |
Run Audit：已完成 run 的离线诊断
对已经跑完的产物目录做只读诊断，写出可落地的报告（证据 → 归属 → 建议）。
契约与失效分类在本 skill 的 references/；纠错 prompt 怎么迭代、怎么验收质量的成熟
流程在仓库文档里——本 skill 不复制那套协议，只在对口处引用。
与 prompt-iterate 的分工（先读这段）
| run-audit（本 skill） | prompt-iterate |
|---|
| 对象 | 生产/reference 一次完整 run 的落盘产物；知识库健康 | 冻结 fixture 的固定窗，只换 prompt 重放 |
| 目的 | 解释「这次跑出了什么/坏在哪/归谁」 | 迭代 prompt/harness 文本并按协议验收 |
| 入口 | 本 SKILL.md + extract_digest.py | docs/prompt-iterate.md |
| 工具 | 离线读 out/...；禁止 --execute | tools/session_replay（默认会调 API） |
| 质量判定 | 精修三方抽查找成类问题；压缩率/validation-ok 不能当质量分 | §2：元信息 + 逐行抽查 +（固定窗）merge/drop gold；失败样本最低抽样量 |
审计若结论是「该改某 fragment / 合并纪律 / singles 残留类问题」：报告里写清归属模板，
并指向 prompt-iterate 做下一轮（含 --variant、分档 -n/--max-attempts、失败抽样
规则）。不要在审计回合里直接开 replay 烧配额，除非用户明确要求。
工具契约：docs/session_replay.md
先分流：用户问的是哪一类
-
运行时 / harness（「为什么 010 成功还跑了 011」「哪次 validation 挂了」「成品是谁写的」）
→ 走下方 轨道 B（先看 digest 的 correction 时间线）。不必强行写完整「质量审计报告」。
-
成品 / 知识 / schema（「审查这个 run」「知识提案合不合规」「和精修比质量」）
→ 走 轨道 A（digest FLAGS → 核实 → 语义抽查 → 结构化报告）。
-
要改 prompt 并对比前后（「下一轮怎么测」「capableC 合并怎样」）
→ 离开本 skill 流程，按 prompt-iterate §2 开 session_replay；可用本 skill 的归因作改动起点。
轨道 A：成品与知识审计
-
定位输入。out/<stem>/ 或 out/reference/<id>/；精修常在
data/manually-refined-subs/<系列>/（对照 index.csv）。有精修时质量结论才硬。
-
跑抽取脚本（每 run 一次）：
python .claude/skills/run-audit/scripts/extract_digest.py out/reference/<id> --refined <精修.srt>
python .claude/skills/run-audit/scripts/extract_digest.py --kb knowledge
digest = 布局 + 统计 + correction 时间线 + FLAGS。FLAGS 是嫌疑不是结论；脚本测不了
语义与「成类」问题。
-
核实 FLAGS。分类与归属见 references/failure-modes.md；
路径/schema 见 references/artifact-map.md。
- 用 run 当时的 prompt_version / variant 判契约（exchange 头或 fingerprint）；用当前
契约提改进建议。
test_profile / flash-lite 暴露的失效默认归「prompt/harness 待改进」，不要用「模型太弱」打发。- 合并长度/源数：现行 validation 多半只 warning（见 prompt-iterate §4）——不要把
「压缩率高」或「validation_ok」单独当成质量结论。
-
语义抽查（脚本测不了）：
- 有精修：抽 2–3 个时间段做 原文 / 机器 / 精修三方对照，只收成类问题。
- knowledge/mistake proposals：长尾定位、reason 证据、
wrong 是否真在 annotated csv 出现过。
- 需要更严的失败样本纪律（例如多条 validation 失败要归纳主因）时，对齐
prompt-iterate §2「失败回复审计最低抽样量」，不要从单条 error 外推。
- 清单外巡检：忘掉 FLAGS，扫成品 SRT 头/中/尾 + 一份 exchange——字形、覆盖时长、
语言设置等重大问题常靠这一步发现。
-
写报告（轨道 A 默认结构）：
## <问题一句话>
- 证据：<路径 + 行号/时间戳 + 引文>
- 归属：<prompt 模板 / src 模块 / harness 行为>
- 建议：<可落地表述或代码改法；若属 prompt 迭代则链到 docs/prompt-iterate.md>
文末：优先级 +「正面结果」。若建议进入 prompt 迭代，写明建议的 session
（通常 correction）、是否需要 --variant，不要在未获许可时调用 API。
轨道 B：运行时时间线（轻量）
digest 已打印 correction 尝试表时优先用它；否则从 task-artifacts.jsonl 抽：
correction_window_response：created_at / attempt / validation_ok / validation_errorscorrection_window_retry：reason（validation_same_window 等）、replacement（true = 下一次是两档重试的第二档：换全新会话的盲重掷，正常路径而非异常）final_srt 出现次数与时间；correction-windows.jsonl 是否同 chunk_id 多条提交- exchange 文件名里的
attemptN 与 API 调用起止时间（两趟 attempt0 时间重叠 → 并发写同目录）
回答格式：时间线 → 因果（同进程重试 vs 双进程覆盖）→ 磁盘上最终生效的是哪次。
只有用户接着要「那译文质量呢」再转入轨道 A。
边界
- 只读产物、写报告；不修 prompt 模板、不写知识库、不重跑任务（那些是用户决定后的事；
prompt 侧后续用 prompt-iterate）。
- 不要用
--execute 或任何会花生成配额的 LLM CLI。
- 多 run 可并行派子代理（把本 skill 流程与 references 路径写入子代理 prompt）。
