iterate-from-skore

skore から反復する

ソース：audit-ml-pipeline の § 4 record-outcome で生成される、scratch/audit/<stem>/audit.md の監査ダイジェスト。 出力：バックログ候補の行と簡潔なユーザー向け要約。iterate-ml-experiment に返します。親スキルはその行をJOURNAL.md の Backlog に書き込み、ソーシングメニューを再提示して、ユーザーが B<N> で1つ選べるようにします。

このスキルが読み込む内容

このダイジェストには、ここで重要となる2つのセクションがあります。

• ## Checks summary — 各行に code、severity（passed／issue／tip）、documentation_url が含まれる DataFrame です。各 issue／tip 行からバックログ候補を1つ作成し、documentation_url を Item のテキストに反映します。
• ## Metrics summary — タスクに適した主要メトリクス（回帰／分類／マルチクラス）です。ユーザー向け要約の段落（「実行では X を達成しましたが、SKD003 チェックで Y が検出されました」）の根拠として使います。単独ではバックログの行を生成しません。

それ以外は対象外です。監査テンプレートは意図的にこの2つのセクションまでに限定されています。より深いアクセサー（残差、重要度、キャリブレーションなど）は、ここでは対象外です。

ダイジェストを読み、Project を再確認しない理由

監査ですでに Project を開き、レポートを読み込み、2つのアクセサーを呼び出して、出力を Markdown としてレンダリングしています。ここで同じ作業を繰り返すと、Display オブジェクトの実体化にかかるコストが重複し、2回の確認の間にずれが生じるリスクがあり、このスキルでは不要なエージェント環境も必要になります。ダイジェストをテキストとして読むほうが、低コストで決定的です。

出力の仕様（本文の前にお読みください）

このスキルは JOURNAL.md を含む journal/ ファイルを一切書き込みません。それらは親が管理します。会話テキストとして、次の2つを返します。

1. バックログ候補の行 — ダイジェストにある、対応可能なチェックごとに1行です。各行には次の内容が含まれます。

   • Item：チェックの documentation_url の内容から導き出した、1行の実験案です。メトリクスの読み取りではなく、実験案として表現します。
   • Source：audit:<stem>:checks.<code>（例：audit:01_baseline:checks.SKD003）。重複排除に不可欠な引用情報です。

2. Summary — ユーザー向けの1段落です。検出した所見の数、重要度上位2～3件、背景としての主要メトリクスを記載します。簡潔にまとめてください。

親の Backlog に同じ Source 引用情報を持つ行がすでにある場合は、その候補を除外し、重複を作らないでください。Summary には除外した重複の数を記載します（「新しい所見は4件で、うち2件は以前のマイニングですでに Backlog にありました」）。

チェック項目がない場合

ダイジェストの Checks summary に issue／tip の行がない場合（passed のみ）、候補の行を0件返し、その旨を明示した Summary を返してください：「チェック項目を見る限り、レポートに問題はありません。今回、対応可能な所見はありません。」親はこれを JOURNAL.md の Status に記載し、次にユーザーが user を選びます。

ダイジェストにアクセスできない場合の代替処理

​​scratch/audit/<stem>/audit.md のダイジェストが読み取れない場合（ファイルがない、監査が実行されていない、監査でエラーが発生したなど）、記憶から所見を捏造したり、プローブを再実行したりしないでください。行を0件返し、アクセスできなかったことを説明する Summary を返します。親がこの不足をユーザーに伝えます。復旧は audit-ml-pipeline が担当します（監査ランナーの再実行、認証の修正など）。

Summary にアクセス失敗を記載したら、そこで終了してください。親の JOURNAL.md の Status 行を下書きしたり、記録内容を指示したりしないでください。§ Stop conditions を参照してください。

停止条件

• journal/ ファイルを書き込んだり、ほかの人に書き込むよう指示したりしないでください。 JOURNAL.md も含まれます。このスキルは行を会話テキストとして返し、親が書き込みます。「不足点を JOURNAL.md の Status に記録する」、Status 行の下書き、親に追記を指示する内容は、いずれも禁止です。親に伝える必要があることは、所見として Summary 段落に記載してください。ディスクに何を保存するかは親が判断します。ほかの人を経由して書き込むことも、書き込みに変わりありません。
• このスキルから skore Project を再度開かないでください。 監査はすでに実施済みです。ダイジェストをテキストとして読むことが契約です。§「ダイジェストを読む理由」を参照してください。ダイジェストが見つからない場合は、audit-ml-pipeline 経由で監査ランナーを再実行してください。iterate-from-skore から project.get(...) を呼び出してはいけません。
• Backlog の候補に反映するのは ## Checks summary の行だけです。 metrics summary は人向けの段落に使うコンテキストであり、それだけで Backlog の行を作成するものではありません。より詳細な診断情報（残差、特徴量の重要度、キャリブレーションなど）は監査テンプレートに含まれておらず、ここでは対象外です。
• documentation_url を参照してください。 issue / tip の各チェックについて、リンク先の skore ドキュメントページを（WebFetch 経由で）取得し、そのページの推奨事項から Backlog の Item を作成してください。skore に関する学習データの記憶から、緩和策を創作してはいけません。
• ユーザーに提示する所見を一つだけ選ばないでください。 対応可能なチェックごとに 1 行を出力します。ユーザーは親のソーシングメニュー（B<N>）から選択します。候補リストを出したら終了してください。「最も効果が高いもの」「次に X を実行」「1 つの実験にまとめる」といった締めくくりは禁止です。親の B<N> 選択肢だけで締めくくってください。
• 既存の Backlog 行と Source の引用を照合して重複を除いてください。 出力前に 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 を作成します。 ページで推奨されている緩和策をもとに、1 行の実験アイデアとして記述します。
   • 引用: 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. 候補の行を JOURNAL.md の Backlog に書き込み、末尾に安定した B<N> インデックスを追加します。
2. 要約をそのままユーザーに提示します。
3. Backlog が拡充された状態でソーシングメニューを再提示します。これにより、ユーザーは B<N> の行を直接選ぶことも、所見を受けて別の方向に進む場合は user を選ぶこともできます。

関連スキル

• iterate-ml-experiment — 呼び出し元です。設計ノート （JOURNAL.md を含む）を管理します。
• audit-ml-pipeline — このスキルが読み取るダイジェストの生成元です。 2つのスキルは同じ診断サーフェスを共有しますが、方向は逆です。 audit-ml-pipeline はプロジェクトを開いてダイジェストを生成します （書き込み側）。一方、iterate-from-skore はダイジェストをテキストとして 取り込み、チェックドキュメントの URL をたどります（読み取り側）。
• evaluate-ml-pipeline — 「次に何を試すべきか」の前に 「レポートには何が書かれているか」を確認するためのスキルです。 ナラティブの読み取り側であり、このスキルでは使用しません。
• iterate-from-user — ソースをユーザーから取得する姉妹スキルです。 ダイジェストの調査結果が適切な出発点ではない場合に、 記事、リソース、または自由形式のテキストをソースとして使用します。