kaggle-record-result - SKILL.md Agent Skill

name: kaggle:record-result description: 実験結果を対話的に確認・記録する。CV/LB スコア、考察、知見を README と docs/insights に保存。 argument-hint: [実験名（例: exp001-baseline）] disable-model-invocation: true allowed-tools: Bash, Read, Write, Edit, Glob

実験結果を確認・記録する

このスキルはユーザーと対話しながら実験結果を確認し、記録する。機械的に記録するのではなく、ユーザーから学びを引き出す対話を行う。

best run の決定ルール

大実験の best run = 最高 LB（LB がなければ最高 CV）の run。

EXP_SUMMARY.md の Experiments テーブルには大実験の best run のスコアを記載する。複数 run がある場合、LB スコアが最も高い run を best とする。LB が未提出の run しかない場合は CV スコアで判定する。

フェーズ 1: 実験の特定と状況確認

対象実験を特定する
- $ARGUMENTS があればその実験名を使用
- なければ src/exp*/ を Glob で検索し、ユーザーに選択肢を提示
- 対象実験の README.md を Read して目的・仮説を確認
対象 run を特定する
- src/{exp-name}/config/run*.yaml を Glob で検索し、小実験の一覧を把握
- config/config.yaml の run_name も確認（ベース run）
- ユーザーに「どの run の結果ですか？」と確認
- 複数 run がある場合は一覧を提示して選択してもらう
現在の実験状況を確認する
- 対象 run の config を Read
- src/{exp-name}/output/{run_name}/ 配下に学習済みの出力があるか確認
- EXP_SUMMARY.md の Experiments テーブルで既存のスコアを確認

フェーズ 2: スコアの収集（対話的）

ユーザーに自然な流れで確認する:

CV スコア
- 「CV スコアはいくつでしたか？」
- 各 fold のスコアがわかれば聞く（平均と分散の把握のため）
- 不明の場合は - として記録し、後で更新できることを伝える
LB スコア
- 「Kaggle に submit しましたか？LB スコアはいくつでしたか？」
- 未提出の場合は - として記録
- 「後で submit したら教えてください、更新します」と伝える
Split 方法
- README.md にすでに記載があればそれを確認
- なければ質問する

フェーズ 3: 考察のヒアリング（最重要）

ユーザーから以下を引き出す。答えが薄い場合は掘り下げる質問をする:

結果の評価
- 「仮説は正しかったですか？結果をどう評価しますか？」
- 仮説と結果のギャップがあれば、その理由を一緒に考える
学んだこと
- 「この実験から何がわかりましたか？」
- 「予想外だったことはありますか？」
次のアクション
- 「この結果を踏まえて、次に何を試したいですか？」
- ただし、具体的な次の実験の設計には踏み込まない（それは kaggle:new-experiment の役割）

フェーズ 4: 記録の実行

4-1. 実験 README.md の更新

src/{exp-name}/README.md を更新する:

結果テーブル（大実験全体の best スコアを記載）:

| Metric | Value |
|--------|-------|
| Split  | {split方法} |
| CV     | {cv_score} |
| LB     | {lb_score} |

Runs テーブルの該当行を更新:

| Run | Key Change | CV | LB |
|-----|-----------|----|----|
| run000-base | ベースライン | {cv} | {lb} |
| run001-xxx | XXX | {cv} | {lb} |

考察セクションを記述

各 Fold のスコアが判明している場合は追記:

| Fold | Score |
|------|-------|
| 0    | x.xxx |
| ...  | ...   |

4-2. EXP_SUMMARY.md の更新

Experiments テーブル: 該当行の Split, CV, LB を更新（大実験の best run = 最高 LB、LB なしなら最高 CV の run のスコアを記載）
Experiment Tree: ノードにスコアを追加し、クラスを更新
- スコアが入ったら wip → good（青）に変更
- 全実験中で最高 LB なら best（緑）に変更
- 他の実験が best → good に降格する必要があるかも確認
- 行き詰まり検出でステータスが dead-end になった場合は dead（赤）に変更
ノードのフォーマット:
```
X["exp{番号}-{subtitle}<br/>{split} | CV: {cv} | LB: {lb}"]
```

4-3. docs/insights/ に知見ファイルを作成

ファイル名: YYYY-MM-DD_exp{番号}-{subtitle}.md（今日の日付）

# exp{番号}-{subtitle}

## 概要

- **目的**: （実験の目的）
- **比較変数**: （何を変えたか）
- **CV**: {cv}
- **LB**: {lb}

## 試したこと

（実験の手法の要約）

## 結果

（定量的な結果と定性的な評価）

## 考察

（ユーザーとの議論から得られた洞察）

## 実装上の知見

（コードレベルで他の実験に役立つ発見。なければ省略。）

## 次に試すべきこと

（ユーザーが挙げたアイデア）

フェーズ 5: 行き詰まり検出（Dead-End Detection）

記録完了後、この実験が行き詰まりに達していないかを自動検出する。

5-1. 停滞チェック

対象実験の Runs テーブル（README.md）を確認し、直近 3 run の CV スコアを比較する:

CV スコアが数値として記録されている直近 3 run を取得
最新 run の CV と 3 つ前の run の CV の差を計算
改善幅が 0.5% 未満の場合、以下の警告を表示する:

⚠ 行き詰まり検出: この実験の直近 3 run の CV 改善幅は {差分} です（0.5% 未満）。
この実験は収穫逓減（diminishing returns）に達している可能性があります。

推奨アクション:
- この実験のステータスを「dead-end」に変更し、新しい大実験で根本的に異なるアプローチを検討する
- あるいは、この実験内でまだ試していない大きな変更がある場合は続行する

実験ステータスを「dead-end」に変更しますか？（yes/no）

5-2. 実験ステータスの記録

ユーザーの回答に応じて、実験 README.md のメタ情報を更新する:

ユーザーが dead-end を承認した場合:
- README.md の結果テーブルに Status 行を追加:
```
| Metric | Value |
|--------|-------|
| Status | dead-end |
| Split  | {split方法} |
| CV     | {cv_score} |
| LB     | {lb_score} |
```
- EXP_SUMMARY.md の Experiment Tree で該当ノードのクラスを dead に変更
- 「kaggle:review-strategy で全体戦略を見直すことをお勧めします」と案内
ユーザーが続行を選択した場合:
- ステータスは変更しない
- ただし警告は記録として残す

5-3. run が 3 未満の場合

直近 3 run の CV スコアが揃わない場合（run 数が不足、または CV が未記録）は、行き詰まり検出はスキップし、その旨を報告する。

フェーズ 6: 完了報告

更新・作成したファイルの一覧を表示
スコアのサマリーを表示
Experiment Tree の現在の状態を簡潔に説明（どの実験が best か等）
行き詰まり検出の結果（該当した場合）