iterate-from-skore

从 skore 中迭代

来源：scratch/audit/<stem>/audit.md 中的审计摘要， 由 audit-ml-pipeline 在 § 4 record-outcome 阶段生成。 输出：一组待办候选行 + 一段简短的人类可读摘要， 交回给 iterate-ml-experiment。父技能会将这些行写入 JOURNAL.md 的 Backlog，并重新展示来源菜单， 让用户通过 B<N> 将其中一项加入待办。

此技能会读取什么

摘要中有两个与此相关的部分：

• ## Checks summary — 一个 DataFrame，每行包含 code、 severity（passed / issue / tip）和 documentation_url。 每条 issue / tip 记录 → 一个待办候选项，其中 Item 文本由 documentation_url 决定。
• ## Metrics summary — 适用于任务的核心指标 （回归 / 分类 / 多分类）。用于为面向用户的摘要段落提供依据 （“本次运行达到了 X，但 SKD003 检查指出了 Y”）。 本身不会生成待办行。

仅限这两部分。审计模板有意只包含这两个部分；更深入的访问器 （残差、重要性、校准，……）不在此范围内。

为什么读取摘要，而不是重新遍历 Project

审计已经打开 Project、加载报告、调用两个访问器， 并将输出渲染为 Markdown。在这里重复这些工作会增加 实例化 Display 对象的成本，可能导致两次遍历结果不一致， 还会要求此技能本不需要的 Agent 环境。将摘要作为文本读取， 成本更低且结果确定。

输出约定（阅读正文前请先看）

此技能绝不会写入 journal/ 文件（包括 JOURNAL.md）——这些文件由父级负责。它会以对话文本形式返回两个产物：

1. 待办候选行 — 摘要中每条可执行检查对应一行。每行包含：

   • Item：根据检查的 documentation_url 内容提出的一行实验想法。 表述为实验想法，而不是指标读数。
   • Source：audit:<stem>:checks.<code>（例如 audit:01_baseline:checks.SKD003）。此引用对去重至关重要。

2. 摘要 — 面向用户的一段话：说明发现了多少项，按严重性列出最重要的 2-3 项，并以指标摘要中的核心数值作为背景。内容简洁充实。

如果父级的 Backlog 中已有 Source 引用相同的行，丢弃该候选项——不要重复添加。 摘要应注明丢弃的重复项数量（“新增 4 项发现；其中 2 项已在先前挖掘时加入 Backlog”）。

检查项为空时的处理

如果摘要中的 checks summary 没有 issue / tip 行（只有 passed），则返回零条候选行，并明确说明：“报告的检查项均无异常；本轮没有可执行的发现。” 父级会在 JOURNAL.md 的 Status 中记录此情况，接下来由用户选择 user。

无法访问摘要时的回退处理

如果无法读取 scratch/audit/<stem>/audit.md 中的摘要 （文件缺失、审计未执行或审计出错），不要凭记忆编造发现，也不要重新运行探查。返回零条候选行，并说明无法访问的原因。父级会将此问题告知用户；恢复工作由 audit-ml-pipeline 负责（重新运行审计运行器、修复身份验证，……）。

在摘要中说明无法访问，并到此为止。不要起草父级的 JOURNAL.md Status 行，也不要告诉父级应记录什么——参见 § 停止条件。

停止条件

• 不要写入 journal/ 文件，也不要让其他人写入。 其中包括 JOURNAL.md。此技能会将各行作为对话文本返回；由父级写入。不要说“在 JOURNAL.md Status 中记录这一差距”，不要起草 Status 行，也不要向父级发出关于要追加什么内容的指示。父级需要了解的任何信息，都应作为观察写入 Summary 段落；由父级决定哪些内容写入磁盘。通过他人转交写入仍然属于写入。
• 不要从此技能重新打开 skore Project。 审计已经完成。按文本读取摘要就是约定——参见 §“Why read the digest”。如果摘要缺失，请通过 audit-ml-pipeline 重新执行审计运行器；绝不要从 iterate-from-skore 调用 project.get(...)。
• 只有 ## Checks summary 中的行才能生成 Backlog 候选项。 metrics summary 仅为面向用户的段落提供背景信息，本身不会生成 Backlog 行。更深入的诊断内容（残差、特征重要性、校准等）不在审计模板中，也不属于此处范围。
• 遵循 documentation_url。 对每项 issue / tip 检查，都要获取链接的 skore 文档页面（通过 WebFetch），并根据页面建议拟定 Backlog Item。不要凭训练数据中关于 skore 的记忆臆造缓解措施。
• 不要替用户选出唯一的“最佳”发现。 每项可执行检查各输出一行。用户通过父级的来源菜单（B<N>）进行选择。列出候选项后即停止。禁止使用以下结尾措辞：“highest-leverage”“run X next”“combined into one experiment”。只以父级的 B<N> 选择作为结尾。
• 按 Source 引用与现有 Backlog 行去重。 输出前先阅读 JOURNAL.md Backlog；跳过所有 Source 与现有行匹配的候选项。
• 不要撰写验收标准。 Backlog 行是实验想法，不是带有目标变化幅度的目标。用户会在运行后评估结果。
• 不要从此技能执行 Python。 读取摘要使用 Read 工具调用；获取文档 URL 使用 WebFetch 调用。不要运行 pixi run python … 或 python -c …。此技能触发的唯一副作用，是在摘要缺失时（通过 audit-ml-pipeline）重新执行审计运行器。

检查流程

1. 定位摘要。 最新一次 done 实验的审计摘要位于 scratch/audit/<stem>/audit.md。如果存在多个 done 实验，默认选择最新的；只有用户询问时才向其说明这一选择。
2. 按文本读取摘要。 使用 Read 工具。
3. 遍历 ## Checks summary 部分。 对每一行 severity 为 issue 或 tip 的检查：
   • 遵循 documentation_url，通过 WebFetch 获取文档。页面会说明检查的测试内容以及接下来可以尝试的做法。
   • 拟定 Backlog Item，根据页面建议的缓解措施，用一句话表述为实验想法。
   • 引用：audit:<stem>:checks.<code>（例如 audit:01_baseline:checks.SKD003）。
4. 与现有 Backlog 去重。 阅读 JOURNAL.md Backlog。删除引用已存在的候选项。
5. 阅读 ## Metrics summary，仅作为背景信息——核心指标用于支撑面向用户的摘要段落。
6. 撰写以下返回块。

Backlog candidates (from: audit digest of <prev_stem>):
  - Item:    <one-line experiment idea derived from the docs URL>
    Source:  audit:<prev_stem>:checks.<code>
  - Item:    ...
    Source:  ...
  - ...

Dropped as duplicates (already in Backlog): <N>

Summary:
  <one paragraph for the user — counts, top 2-3 highlights, the
  headline metrics for context, and the doc URLs of the surfaced
  checks. Dense, not chatty.>

iterate-ml-experiment 将执行以下操作：

1. 将候选行以稳定的 B<N> 索引追加到末尾，写入 JOURNAL.md Backlog。
2. 将摘要原样呈现给用户。
3. 在 Backlog 已更新的情况下重新显示来源菜单，以便用户直接选择某个 B<N> 行，或在发现促使其选择其他方向时选择 user。

配套技能

• iterate-ml-experiment — 调用方；负责设计说明 （包括 JOURNAL.md）。
• audit-ml-pipeline — 生成本技能所读取摘要的技能。这两个技能共用相同的诊断界面， 但方向相反：audit-ml-pipeline 打开 Project 并生成摘要（写入端）；iterate-from-skore 将摘要作为文本 消费，并访问检查文档 URL（读取端）。
• evaluate-ml-pipeline — 在讨论“接下来该尝试什么”之前，先了解“报告说了什么”。 负责叙述内容的读取端；本技能不使用它。
• iterate-from-user — 同级的来源策略；当摘要中的发现不适合作为起点时， 从用户提供的内容（文章、资源或自由文本）获取来源。