iterate-ml-experiment

ML 実験の反復

experiments/ を中心にしたループです。次に何を試すか、なぜ試すか、何を結果とみなすか、履歴をどのように記録するかを扱います。パイプライン／評価の仕組みは、隣接するスキルで扱います。

次のステップへのポインター — フローの概要

session open
   │
   ├── JOURNAL.md missing / placeholder ──► § 0 Bootstrap
   │                                          │
   │                                          ├─► G-EDA (explore-ml-data: run | skip)
   │                                          │
   │                                          └─► design note → G-DESIGN → § 3 implement
   │
   ├── "what's next?" with ≥1 done row ───► § 1 summary → § 2 (sourcing; skip three-way) → § 3 implement
   │
   ├── "run finished" ─────────────────────► § 4 record outcome
   │                                          │
   │                                          └─► dispatch audit-ml-pipeline
   │
   └── "status?" / "compare X Y" ──────────► references/maintenance_modes.md

ターンの終了を宣言する前に、エビデンスを添えて Pre-flight checklist を必ず再出力してください。

最初のアクション — 状態を読み、read-set トラッカーを出力する

ステップで必要になった時点で、隣接する各 SKILL.md を必要に応じて読み込みます（例：§ 3 の CV 戦略ステップの前に evaluate-ml-pipeline を開きます）。セッション開始時にすべてを先読みしないでください。

Sibling skills (just-in-time):
  - organize-ml-workspace, data-science-python-stack,
    python-env-manager, python-api, python-code-style,
    explore-ml-data, build-ml-pipeline, evaluate-ml-pipeline,
    test-ml-pipeline, smoke-test-ml-pipeline,
    iterate-from-skore / iterate-from-user

次に、回答する前に以下を行います。

1. journal/JOURNAL.md を読みます。 存在しない／プレースホルダーの場合は、初期化します（§ 0）。 これはプロジェクトの正式な要約です（Status、Data understanding (EDA)、History、Backlog）。
2. Workspace decisions ブロックを確認し、事前に記録されたゲート（tabular、env_manager、package、skore_mode、cv_splitter）を確認します。決定が記録済みの場合、その項目の AskUserQuestion は省略します。
3. Pre-flight checklist を出力し、各チェックボックスを記入します。
4. Mode picker を使い、読むセクションを特定します。

Mode picker — 本文を読み進める前に確認

1 ターンにつき、読むモードセクションは1 つだけです。ユーザーのシグナルに当てはまるものを選び、該当箇所に進みます。

シグナル／ワークスペースの状態	モード	セクション
JOURNAL.md が存在しない／プレースホルダー／History の行が 0 件	Bootstrap	§ 0
journal/ が未セットアップ（src/ と experiments/ がない）	Bootstrap → 先に引き継ぎ	→ organize-ml-workspace、次に § 0
「次は何をする？」「反復しよう」「次の案を出して」— 完了済みの行が 1 件以上ある	Iterate (propose)	§ 1 の概要 → § 2（＋ Dispatch）。§ 1 の 3 択はスキップ
「実行が終わった」「結果を記録して」「X = … になった」	Iterate (record)	§ 4
「現在の状況は？」「ステータスは？」「何を試した？」	Project overview	references/maintenance_modes.md § "Project overview"
「X と Y を比較して」「X 対 Y」	Compare (read-only)	references/maintenance_modes.md § "Compare past experiments"
「目標を見直そう」「実際には を重視している」	Goal pivot	references/maintenance_modes.md § "Goal pivots"
「X を中止して」「X をやめて」	Abandoned	references/maintenance_modes.md § "Abandoned experiments"
異なる条件で以前の実験を再度実行する	Re-run	references/maintenance_modes.md § Re-runs

複数のモードが当てはまるように見える場合（「X と Y を比較してから、案を出して」など）は、まず読み取りモードを選び、そこで止めます。§ 1 に戻るのは別のターンです。

停止条件 — 最初にお読みください

• 設計メモがなければ、スクリプトもありません。 journal/NN_*.md が存在し、内容が記入され、ユーザーが明示的に承認するまでは、experiments/NN_*.py を作成または編集してはいけません。

• ディスパッチは引き継ぎであり、提案ではありません。 情報収集の分岐が兄弟スキルに処理を回す場合、その兄弟スキルが独自に情報を取得します。ユーザーに課題の本文、記事のテキスト、または「簡単な要約」を貼り付けるよう求めて、引き継ぎを省略してはいけません。それはユーザーを介して兄弟スキルの役割を代行し、分岐にある質問による絞り込みと確認のゲートを失わせます。このターンでディスパッチを実行できない場合は、どの引き継ぎが妨げられているかを伝えて停止してください。代わりにユーザーへ質問してはいけません。

  GitHub issue URL this turn: name iterate-from-user (resource-link,
  pre-resolved) and journal/NN_<short_name>.md. Then STOP.
  BLOCKED: sibling fetch. Do not offer "paste 2–3 paragraphs".
  Do not offer "confirm fetch". Do not run the three-branch ask.
  

• JOURNAL.md はセッション開始時に読み込むものであり、その場で即興して作るものではありません。 experiments/ のファイル名や git log から履歴を再構成してはいけません。それらには「なぜ」が記録されていません。

• 戦略は選択するものであり、前提にするものではありません。 すべての提案で情報収集戦略（skore / user / my-pick / B<N>）を明記してください。暗黙にデフォルトを選んではいけません。例外：ブートストラップ — ベースラインはワークスペースのデフォルトで固定されているため、戦略のディスパッチはありません。

• 承認は明示的でなければなりません。 ユーザーの「approved」／「yes」／「go」／「looks good」がゲートになります。曖昧な場合は、AskUserQuestion で再度確認してください。

• 結果は説明するのではなく、記録してください。 実行が終了したら、会話を先に進める前に、結果を JOURNAL.md と Status ブロックの両方に記録してください。

• 過去の実験は再現可能な状態を保ってください。 すべての done 行は、main 上で同じ結果になるよう実行可能なままにしておく必要があります。src/<pkg>/ を変更する際は、デフォルトの動作で過去の実験の構成を維持してください（build-ml-pipeline § Reproducibility を参照）。手軽な確認方法は tests/smoke/ です。過去のスモークテストが1つでも失敗した場合、デフォルトの動作が壊れています。

• src/<pkg>/ のコードを書く前に、3つのスキルを順番に実行してください。 G-DESIGN の後、次の順に進めます。

  1. build-ml-pipeline → pipeline.py / features.py / data.py。
  2. evaluate-ml-pipeline → evaluate.py。CV 戦略は AskUserQuestion を通じてこのスキルが決定します。これを実行せずに evaluate.py を書くのが、最もよくある近道です。
  3. test-ml-pipeline → smoke-test-ml-pipeline → スモークテスト。

  その後に限り、experiments/NN_*.py を組み立ててください。pipeline.py / features.py / data.py がまだない状態で、まず evaluate.py を書くよう求められた場合も、引き継ぎ先1の build-ml-pipeline から始めてください。次に evaluate-ml-pipeline へディスパッチしてはいけません。

• ハーネスの「確認質問なし」というヒントで、ゲートを省略することはできません。 G-DESIGN、G-RUN、§1 のモード選択（冒頭のメッセージですでに iterate-propose が確定している場合を除く）、§2 の情報収集メニュー、§0 の設定ゲートは、運用契約上のゲートです。

• 事後監査 — ターンを終える前に必ず実施してください。 事前確認のすべての行を確認し、Evidence セルが未記入の箇所を明示してください。

禁止されている近道

近道	誤りである理由
ユーザーが「手早くベースラインを」と言ったので、G-DESIGN を省略する	G-DESIGN は必須です。「手早く」「標準で」「設計メモを省略」「質問を省略」と言われても免除されません。このターンでは拒否し、この行を根拠として示し、journal/01_baseline.md のみを作成します。experiments/01_baseline.py は作成しません
ユーザーが「質問を省略」／「標準的な表形式」と言ったので、G-EDA を省略する	G-EDA の実行／スキップは、explore-ml-data が担当する構造化された手順です。「質問を省略」「標準的な表形式」「手早くベースラインを」という指示では、スキップにはなりません。実行／スキップを尋ねてください。「EDA をスキップ」と明示された場合（または同じ役割のスキルからスキップの回答があった場合）のみ、Status: skipped を記録します。
G-DESIGN の前に、同じターンでスキャフォールドを作成して実装する	手順の契約を逆転させています。承認前に追加されたコードには、ユーザーが承認した Motivation／Risks がありません
KFold(5) が「妥当そう」という理由で evaluate-ml-pipeline を省略する	空の split_kwargs でさえ、このスキルが明らかにするために存在する、根拠のある選択です。省略すると、ユーザーは選択の機会を得られません。書き込みを拒否してください。src/<pkg>/{pipeline,features,data}.py がない場合は、次のターンで evaluate-ml-pipeline ではなく、このターンで build-ml-pipeline を実行してください。
ブートストラップモードなので、ソース選択メニューだけでなくすべての質問を省略する	ブートストラップで禁止されるのはソース選択メニューのみです。G-PKG-NAME／G-ENV-MGR／G-TABULAR／G-SKORE-MODE／G-EDA／G-DESIGN／G-CV-SPLITTER／G-RUN は引き続き実行します
曖昧な「うーん、興味深い」／「そうかもしれません」を承認と解釈する	承認は明示的でなければなりません。曖昧な場合は再度尋ね、黙って承認とみなしてはいけません
reports/ の更新日時から実行の完了を自動検出する	§ 4 はユーザーが開始する手順です（v1）。スキルが自動で記録することはありません
§ 4 の記録が終わったら完了を宣言し、監査の実行依頼を省略する	§ 4 の監査依頼は記録結果の一部であり、省略できません。監査の要約には、JOURNAL の行に記載する主要な指標が含まれます
G-RUN と同じターンで実験を実行し、§ 4 を行わずに完了を宣言する	実行が正常に完了した場合、同じターン内で G-RUN の後に § 4 を行います。「実行しました」で止めず、結果を記録してください
セッション開始時に、すべての関連する SKILL.md ファイルを先に読む	読み込み対象のトラッカーは、進行を妨げるゲートではありません。関連スキルは必要になった時点で開き、未処理リストを出力したうえで作業を進めてください

事前確認 — 設計メモを書き込む前に出力

簡潔なチェックリストです。証拠形式の仕様は references/preflight_evidence.md を参照してください。

Pre-flight (iterate-ml-experiment):
- [ ] `journal/JOURNAL.md` read this turn (or confirmed missing → bootstrap)
      Evidence: Read journal/JOURNAL.md (this turn) | "missing — bootstrap"
- [ ] `Workspace decisions` block checked for pre-recorded gates
      Evidence: lists each <gate>: <value | not recorded>
- [ ] Mode: bootstrap | iterate-propose | iterate-record |
      overview | compare | goal-pivot | abandoned | re-run
      Evidence: rule that matched (Mode picker row)
- [ ] Last experiment + status: <NN_name> | n/a — bootstrap
      Evidence: last row of JOURNAL.md History
- [ ] (Iterate-propose only) Sourcing menu presented; user picked
      Evidence: AskUserQuestion id=<id>, answer=<skore|user|my-pick|B<N>>
                | user free-text quote turn N
                | "n/a — bootstrap / read-only mode"
- [ ] (Bootstrap only) Upfront config gates fired (G-PKG-NAME,
      G-ENV-MGR, G-TABULAR, G-SKORE-MODE)
      Evidence: per-gate ask id OR JOURNAL.md Status reference
                | "n/a — iterate mode"
      Note: G-CV-SPLITTER is NOT an upfront gate — it fires later, in
      the § 3 chain at the evaluation step (after G-DESIGN).
- [ ] (Bootstrap only) G-EDA fired BEFORE the baseline draft
      Evidence: explore-ml-data dispatched; answer=<run|skip>;
                JOURNAL.md `## Data understanding (EDA)` section present
                | "n/a — iterate mode"
      "skip the questions" / "standard tabular" / "quick baseline"
      is NOT G-EDA = skip.
- [ ] Design note drafted (or Backlog enriched, for `skore`)
      Evidence: Write journal/<NN>_<name>.md (this turn) | "Backlog
                rows B<x>..B<y> appended" | "n/a — read-only mode"
- [ ] G-DESIGN: user approved before any `experiments/NN_*.py` touched
      Evidence: AskUserQuestion id=<id>, answer=approved | user quote |
                "n/a"
- [ ] (§ 3 only) Three-skill chain ran in order:
      `build-ml-pipeline` → `evaluate-ml-pipeline` → `test-ml-pipeline`
      Evidence: each owning skill produced its file this turn
                | "n/a outside § 3"
                | "BLOCKED — start at build-ml-pipeline (src files missing)"
- [ ] (§ 3 only) G-CV-SPLITTER resolved during the evaluate step
      Evidence: evaluate-ml-pipeline fired the splitter AskUserQuestion
                (or mapped split_kwargs) before `evaluate.py` write
                | "n/a outside § 3"
- [ ] (§ 3 only) G-RUN resolved: run now | leave for later
      Evidence: AskUserQuestion id=<id> | "n/a outside § 3"
- [ ] (§ 4 only) All artifacts written: Status block + JOURNAL row +
      Backlog hygiene + audit dispatch
      Evidence: list each artifact written | "n/a outside § 4"
- [ ] python-api consulted for any new external symbol
      Evidence: Read/Write scratch/api/<lib>/<v>/<topic>.md (this turn)
                | "n/a — only re-using cached symbols"
- [ ] Pre-flight re-emitted with evidence before final message.
      Evidence: this checklist appears in the end-of-turn summary.

§ 0 ブートストラップ（初回セッションのみ）

journal/JOURNAL.md が存在しない、プレースホルダーである、または History の行が 0 件の場合、ワークスペースはブートストラップモードです。

手順（簡易版 — 完全版は references/bootstrap.md を参照）：

最初のアクション： ユーザーに尋ねる前に、目標のデフォルト値を設定するため data/README.md を読みます。

1. 必要であれば、まずスキャフォールディングを行います。 src/、experiments/、journal/ がない場合は、organize-ml-workspace に引き継ぎ、プレースホルダーの JOURNAL.md が作成されたら戻ります。
2. templates/JOURNAL.md を使って JOURNAL.md を書き直します。
3. 尋ねる前に、data/README.md から目標のデフォルト値を導き出します。1 文で提案し、ユーザーに確認または修正してもらいます。
4. モデルを設計する前にデータを探索します（G-EDA）。 explore-ml-data に処理を委任します。ゲートは「実行」／「スキップ」の二択です。実行する場合は data/eda.py を実行し、data/eda.md と HTML を作成して、JOURNAL の ## Data understanding (EDA) セクションを記入します。調査結果（ターゲットの比率／偏り、日時／グループ列、欠損、カーディナリティ）は、次のステップで使う学習器とメトリクスのデフォルト値に反映され、その後の評価ステップで選ぶ CV 戦略にも役立ちます。実行するにはエージェントの機能（ipython）が必要で、この段階ではベースラインの前に G-AGENT-FEATURE が発生する場合があります。ユーザーがこれを拒否した場合、EDA はスキップに切り替わります。スキップする場合、JOURNAL セクションには Status: skipped と記録します。「質問をスキップ」「標準的な表形式データ」「クイックベースライン」を理由にスキップを設定してはいけません。これらは G-DESIGN を拒否するものであり、G-EDA への回答ではありません。実行するかスキップするかを尋ねてください。
5. 相談チェーンを通じて journal/01_baseline.md の下書きを自動作成します。 EDA の調査結果を反映させます。学習器のデフォルト値は build-ml-pipeline、メトリクスのデフォルト値は skore.evaluate を使う python-api です。ここでスプリッターを決めてはいけません。クロスバリデーション戦略はデータに基づいて決めるものであり、パイプラインに X マーカーが設定された後、評価ステップ（G-CV-SPLITTER。担当は evaluate-ml-pipeline）で決定します。このノートには、その時点で決定すると記録するだけです。EDA の調査結果や目標と矛盾する場合は、上書きせずリスクに記載します。
6. ブートストラップにおけるユーザーの役割は、承認または修正です。 考案することではありません。
7. ベースラインが承認され、記録されたら、ブートストラップを終了します。監査ファイルは、最初の § 4 record-outcome で作成されます。

ブートストラップではデータソース選択メニューをスキップします — 設定ゲートはスキップしません

スキップされるもの：データソース選択メニュー、§ 1 の再開／結果記録／提案の選択。

引き続き実行されるもの：

ゲート ID	選択内容	担当	実行タイミング
G-PKG-NAME	src/<pkg>/ のインポート名	organize-ml-workspace	マニフェストの作成前
G-ENV-MGR	環境マネージャー	python-env-manager	インストールコマンドの実行前
G-TABULAR	表形式データ用ライブラリ（pandas / polars）	data-science-python-stack	data.py の書き込み前
G-SKORE-MODE	Skore Project のモード（local / hub / mlflow）と、hub ワークスペース名または MLflow のトラッキング URI	organize-ml-workspace	pyproject.toml の書き込み前
G-EDA	ベースラインの設計前にデータを探索する（実行／スキップ）	explore-ml-data	journal/01_baseline.md の草案作成前
G-AGENT-FEATURE	ipython + pyright をインストールする（インストール／スキップ）	python-env-manager	条件付き — G-EDA = 実行で、エージェント機能がまだない場合（それ以外の場合、最初の監査は § 4）
G-DESIGN	journal/01_baseline.md のユーザー承認	このスキル	src/<pkg>/ または experiments/ のコードを書く前、つまり § 3 の連鎖の前
G-CV-SPLITTER	skore.evaluate の CV ファミリー	evaluate-ml-pipeline	§ 3 の連鎖内、G-DESIGN の後 — evaluate ステップで、evaluate.py の書き込み前。split_kwargs が空でも必須
G-RUN	「今すぐ実行」か「後で実行」か	このスキル	実験スクリプトの実行前

「簡単なベースライン」「標準的な表形式データ」「質問はスキップ」 「お任せ」といった自由記述では、G-EDA を含め、これらのいずれも 解決しません。構造化された AskUserQuestion に進んでください。 「EDA をスキップ」という明示的な指示、または explore-ml-data の スキップ回答だけが、G-EDA = スキップとして記録されます。

→ 次へ：G-DESIGN、その後 § 3 の実装チェーン。

§ 1 セッション開始（反復モード）

• JOURNAL.md を読みます。
• データセット、目標、直近の実験とそのステータス、Backlog で 次に取り組める項目を、2～3 行でユーザーに要約します。

開始メッセージがすでに iterate-propose の場合は、 三択の質問をスキップします。 該当する表現：「次は何をする？」 「次の案を出して」「反復していこう」など。完了済みの History 行が 1 件以上あることも条件です。モード選択ですでに進む経路が確定して いるため、このターンで § 2（データソース選択メニュー）に進みます。 resume | record outcome | propose next の選択で止まらないでください。

それ以外の場合は AskUserQuestion で質問します — 暗黙の デフォルトは設けず、選択肢は 3 つです。

• resume — 直近の実験がまだ計画中／承認済み／未完了です。
• record outcome — 直近の実験は実行済みです。§ 4 に進みます。
• propose next — 直近の実験は done または abandoned です。→ § 2。

「続けよう」「うん」といった自由記述は曖昧です — 待ってください。

§ 2 次の実験を提案する

データソース選択メニュー — 原文どおり表示

iterate モードで § 2 を実行するたびに、JOURNAL.md の Backlog 表と あわせてこのメニューを表示します。暗黙にデフォルトを選ばないでください。

選択が確定している場合は、メニュー全体をスキップします。 ユーザーの開始メッセージですでに戦略 — URL、B<N>、明示的な 「これを選ぶ」— が指定されている場合、§ 2 は解決済みであり、 メニューは表示しません。それでも「記録のため」「透明性のため」 「スキップしたものがわかるように」といった理由で、あるいは折りたたみ ブロック内で再掲するのは、メニューを「提示」することになります。 読み手には 4 つの選択肢と質問が表示されます。入力から確定した分岐を 明示して、先に進んでください。

How would you like me to source the next experiment?

  skore    — read the audit digest at scratch/audit/<stem>/audit.md
             from the latest run; follow each surfaced check's
             documentation_url to draft a Backlog row, summarize,
             re-present this menu.
  user     — you tell me what to try: article URL, GitHub issue,
             spec / reference repo, or free text.
  my-pick  — I synthesize 2–4 candidate ideas; you pick one.
  B<N>     — promote a Backlog row directly.

Backlog (pick by index):
<paste JOURNAL.md Backlog table here>

選択には AskUserQuestion を使うか、「選んでもらいます」／ Your pick? で終えてください。構造化 UI が利用できない場合に限り、 プレーンテキストで選択肢を列挙してください。行の本文を貼り付けて いない場合でも、4 つの選択肢の横には Backlog のインデックス （B1、B2、…）を必ず表示してください。

フリーテキストの処理 — 最初に一致したものを優先

ユーザーの発言…	解決先
完全一致するラベル（skore / user / my-pick / B<N>）	その選択肢
B2 / 「B2で進めましょう」	B<N> の選択肢
科学論文のURLを貼り付けた	user → 論文リンク分岐
GitHubのIssue URL / org/repo#N / 仕様のパス	user → リソースリンク分岐。iterate-from-user を解決済みの状態でディスパッチします。要約を尋ねないでください。ソース選択メニューを再提示しないでください。デザインノートのパス：journal/NN_<short_name>.md。
「アイデアを出して」 / 「決めてください」	my-pick
「Xを試したい」 / 「代わりにYを使って」	user → フリーテキスト分岐
あいまい / メニューにない	AskUserQuestion を実行し、推測しないでください

分岐

• skore → iterate-from-skore にディスパッチします。バックログ候補の行 + 要約が返されます。安定した B<N> を付けて行を書き込み、要約を提示し、ソース選択メニューを再提示します。このターンではデザインノートを作成しません。
• user → iterate-from-user にディスパッチします。Proposal が返されます。 journal/NN_short_name.md にドラフトを作成します。
• my-pick → インラインで処理します。JOURNAL.md の Status、直近の Implication / Risks、現在の Backlog を読み取ります。候補を2～4件まとめて、AskUserQuestion で提示します。選択されたらデザインノートを作成します。
• B<N> → その行を昇格します。行の Item を種にし、行の Source を Sourcing strategy にします。承認後、Backlog から削除します。

user / my-pick / B<N> の場合は、templates/experiment_design.md を使って journal/NN_short_name.md にドラフトを書き込みます。 NN は次の空き整数、short_name はユーザーが指定した名前です。

→ 次へ：§ 3。

§ 3 デザインノートを反復し、実装する

• ドラフトを提示します：ファイルパス + 3～5行の要約 （Question / Method / Risks）。

• 反復中のフィードバックはフリーテキストで受け付けます。 journal/NN_*.md をその場で編集し、ここでループします。

• 最終承認ゲートは AskUserQuestion で、選択肢は2つです：

  • 承認済み — ステータスを切り替え、JOURNAL History の行を追加し、3つのスキルからなるチェーンに引き継ぎます。
  • 変更を追加 — 修正ループに戻ります。

  明確なフリーテキストの「承認しました」 / 「進めて」 / 「問題ありません」は解決として扱います。 あいまいな場合は、構造化された質問をします。

• 設計の反復中に experiments/NN_*.py を作成しないでください。

• 来歴を正確に記録してください。 Risks のみの編集では、元の Sourcing strategy を維持します。Method の変更では → <original> + user override とします。

3つのスキルによる実装チェーン — 省略不可

G-DESIGN の通過後、次の順序でディスパッチします：

1. build-ml-pipeline → src/<pkg>/{pipeline,features,data}.py。
2. evaluate-ml-pipeline → src/<pkg>/evaluate.py。CV-strategy は AskUserQuestion を使ってここで決定します。これを迂回することが、明示的に禁止された近道です。
3. test-ml-pipeline → smoke-test-ml-pipeline → tests/smoke/test_NN_<short_name>.py に対応するスモークテストを作成します。

その後に限り、experiments/NN_*.py を組み立てます。シグネチャは記憶に頼らず、 python-api で確認してください。

ユーザーが evaluate.py だけを求め（スプリッター名がすでに指定されている場合も含む）、pipeline.py / features.py / data.py がない場合：書き込みを拒否し、チェーン build-ml-pipeline → evaluate-ml-pipeline → test-ml-pipeline を明示して、 最初に build-ml-pipeline を実行します。ステップ2はステップ1の完了後です。「次に evaluate-ml-pipeline をディスパッチします」と言わないでください。

G-RUN — スモークテスト後の実行ゲート

tests/smoke/（新しいテストと、以前のすべてのテスト）が通過したら、 AskUserQuestion で尋ねます：

• 今すぐ実行 — 次を実行します pixi run python experiments/NN_<short_name>.py。
• 後で実行 — コマンドを表示せず、自動提案もしないでください。JOURNAL の Status + Backlog をそのまま提示して終了します。

暗黙のデフォルトはありません。

→ 次へ：このターンで実行が完了した場合は、直ちに § 4 に進みます。「実行しました」で止めず、結果を記録してください。

§ 4 結果を記録する

トリガー：ユーザーが「実行が終わりました」 / 「記録して」と言った場合、または エージェントが同じターンに実験を実行（G-RUN = 今すぐ実行）し、正常に完了した場合です。ユーザー自身が開始した実行について、reports/ の更新時刻やポーリングで自動検出しないでください。

手順

1. 監査を最優先：audit-ml-pipeline に依頼して、audit/NN_<short_name>.py を配置し、 実行します。監査では、同梱のランナーを使ってレポートを読み取り専用で読み込み、 主要指標を含む Markdown ダイジェストをストリーミングします。監査はスクラッチ プローブに取って代わります — 監査が正式な手順である場合、レポートから指標を 抽出するために scratch/<ts>_inspect_*.py を作成しないでください。
   • Agent feature がインストールされている必要があります。インストールされていない 場合、audit-ml-pipeline は python-env-manager § Agent feature (G-AGENT-FEATURE) にルーティングします。
2. 監査ダイジェストを読みます。指標とチェックの要約を、次の 3 つの手順の情報源に します。
3. journal/NN_*.md の Status ブロックの 4 つのフィールドすべてを入力します。
   • State：done（または、理由を 1 行で記した abandoned）。
   • Approved by user on：承認時の値を変更しません。
   • Headline result：ユーザー（または監査）が提示した指標を一言一句そのまま コピーします。明示されていない数値、分割数、残差に関する主張を作り出さないで ください。すでに 0.081 ± 0.005 on 5-fold CV と述べられている場合は、その表現を 使用できます。
   • Implication for next iteration：1〜2 文で記述します。
4. done にする前の スモークテストゲート — tests/smoke/ のテストがすべて 成功する必要があります。過去の失敗は再現性の後退を意味します → build-ml-pipeline § Reproducibility にルーティングします。CV レポートは skore Project に登録できますが、 スモークテストスイート全体が成功するまでは、JOURNAL の行を approved のままに します。中止する場合、スモークテストの成功は必要ありません。
5. 主要な結果を JOURNAL.md の History に追記します。
6. バックログの整理：新しい実行で回答が得られた項目、または不要になった項目を 確認します。削除するか、取り消し線を付けます（~~old~~ — resolved in NN_X）。 新しいレポートの診断的な分析は iterate-from-skore の役割であり、§ 4 の役割では ありません。
7. （任意）GitHub issue のクローズ処理 — 実験の Source が GitHub issue の場合、 主要な結果を記載して gh issue comment <N> を実行するか、AskUserQuestion で確認 します。自動投稿はしないでください。

ここで停止してください。同じターンで次の実験を自動的に提案してはいけません。 AskUserQuestion を使い、次の 2 つの選択肢を一字一句そのまま示して締めくくります。

• draft it now — 含意を種として § 1 に戻ります。
• not yet — 含意を Backlog に記録し、停止します。

この 2 つの選択肢を示すことは、次の実験を提案することではありません。自動提案とは、 このターンで次の設計メモまたは実験の本文を作成することです。進行のペースは ユーザーが決めます。このスキルは記録を行いますが、提案と記録を一度に行うことは ありません。

ディスパッチ表 — どの iterate-from-* スキルを使うか

状況	アクション
過去の実験がない（ブートストラップ）	§ 0 により、ベースラインを自動作成します。戦略スキルは使いません
ユーザーが Backlog の行を指定（B2、「B5 をやりましょう」）	直接昇格します。戦略スキルは使いません
「レポートを分析して」／「skore には何が見える？」	iterate-from-skore — Backlog を充実させ、メニューを再表示します。このターンでは設計メモを作成しません。
「X を試したい」／記事の URL ／ GitHub issue	iterate-from-user。GitHub issue の URL ／ org/repo#N は、事前解決済みのものとして渡します（resource-link）。3 分岐の質問は実行しないでください。ユーザーに issue の本文を貼り付けるよう求めないでください。保存先は journal/NN_<short_name>.md（NN = 次の History インデックス）です。Proposal が返された後にのみ下書きを作成します。
「アイデアを出して」／「任せる」	my-pick — その場で処理します。候補を 2〜4 件まとめ、AskUserQuestion を実行します
1 件以上の実験が記録されている状態での自由形式の「次は何をする？」	ソーシングメニューを一字一句そのまま提示し、Backlog も示します。暗黙の既定値は使いません

戦略スキルは意図的に簡素化されています。戦略スキルは候補を探し、このスキルは 下書きを作成します。skore 戦略では、ディスク上にレポートがある過去の実験が 必要です。ブートストラップでは利用できません。

iterate-from-skore が候補を 1 件も返さない場合：JOURNAL Status に次のいずれかを 1 行追記します（Audit checks clean on <stem> as of <date> または Audit digest inaccessible on <stem> as of <date>）。 History の行は追加しません。ソーシングメニューを再表示します。

メンテナンスモード — 参照先

いずれも読み取り専用、またはまれに使用します。詳細な手順は references/maintenance_modes.md を参照してください。

• プロジェクトの概要 — JOURNAL と Backlog に基づく読み取り専用の要約です。 別のドキュメントを生成しないでください。
• 過去の実験の比較 — 読み取り専用です。v1 は JOURNAL.md の History からペアごとに並べて比較します。デザイン ノートを作成しないでください。JOURNAL の行を追加しないでください。このターンでは比較表のみです。 「次のステップの提案」も、audit-ml-pipeline／iterate-from-skore への ディスパッチも行いません。次の実験は、後続のユーザーターンで行います。
• 目標の変更 — Status を日付と理由とともに更新し、History に 水平区切り線を挿入し、次の実験の Risks で比較不能であることを明記します。
• 中止した実験 — AskUserQuestion（abandon／defer ／run now）。Status は、1 行の理由を添えて abandoned にします。
• 再実行 — 単独（NN_<stem>_rerun）またはバッチ （NN_paired_comparison）。新しいデザインノートを作成します。元のノートは 変更しません。

このスキルが管理するファイル

journal/
├── JOURNAL.md                # status + history + backlog (index)
├── 01_baseline.md            # design note for experiments/01_baseline.py
├── 02_<short_name>.md
└── …

ペアリング規則（厳守、4 ファイル）：journal/NN_<short_name>.md ↔ experiments/NN_<short_name>.py ↔ tests/smoke/test_NN_<short_name>.py ↔ audit/NN_<short_name>.py。ステムは同一で、1 対 1 に対応します。

JOURNAL.md の構成

1. Status — 2～3 行：データセット、目標、直近の実験とそのステータス。
2. Data understanding (EDA) — 短い要約と data/eda.md へのリンク。このセクションは explore-ml-data が G-EDA のブートストラップ段階で作成します。このスキルはセクションを確保するだけです。
3. History（時系列順）— 実験ごとに 1 行：ステム、 意図、ステータス、要点、デザインノートへのリンク。
4. Backlog（今後の項目）— インデックス付きの表。列は #、 Item、Source（skore:<stem>／my-pick:<stem>／user）。

テンプレート：templates/JOURNAL.md。この 4 つだけが認められた セクションです。ほかのセクションを追加しないでください。

実験ごとのデザインノートの構成

テンプレート：templates/experiment_design.md。セクション：

• Question / hypothesis — 1 文。
• Motivation — 情報収集戦略から取得し、具体的に引用します。
• Method — 前回からの変更点を文章で説明します。仕組みの詳細は build-ml-pipeline／evaluate-ml-pipeline が担当します。
• Risks — メトリクスが誤った理由で変化する要因。
• Status block — planned → approved → done | abandoned。

「Success criteria」セクションは設けません。 実行後の評価はユーザーが行います。

このスキルが行わないこと

• 実験を実行すること（ユーザー／ランナーが実行します）。
• データセットを探索／プロファイリングすること（G-EDA の手順と ## Data understanding (EDA) セクションは explore-ml-data が担当します）。
• skore Project を開いたり、クエリしたりすること（ evaluate-ml-pipeline と python-api が担当します）。
• pipeline.py／features.py／data.py を編集すること （build-ml-pipeline が担当します）。
• ワークスペースが存在するか、ファイルをどこに配置するかを判断すること （organize-ml-workspace が担当します）。
• コミット／PR を作成すること。
• 実験の成功を定義すること。
• ユーザーに代わって情報収集戦略を選ぶこと。

関連スキル

スキル	関係
organize-ml-workspace	足場の作成とステムのペアリング規則
explore-ml-data	§ 0 がベースライン前に G-EDA を実行します。EDA の所見は、ベースラインノートの Method／Risks と ## Data understanding (EDA) JOURNAL セクションの土台になります
iterate-from-user	ユーザー提供の提案（記事／リソース／自由記述）
iterate-from-skore	レポートを情報源とする Backlog の拡充
build-ml-pipeline	pipeline.py／features.py／data.py の本体、再現性の仕組み
evaluate-ml-pipeline	evaluate.py の本体、CV 戦略の決定、レポートの確認
test-ml-pipeline → smoke-test-ml-pipeline	スモークテストの本体。スモークテストが成功するまで、§ 4 は done に変更しません
audit-ml-pipeline	§ 4 のディスパッチ。監査ダイジェストには、JOURNAL の行に記載する主要メトリクスが含まれます
python-api	シグネチャの確認
python-env-manager	監査と explore-ml-data（EDA）の前提条件に必要な G-AGENT-FEATURE

参照資料（必要に応じて読み込み）

• references/bootstrap.md — ブートストラップ手順の全体、config-gate の詳細、ベースラインテンプレートの置換。
• references/record_outcome.md — Backlog の 整理例と GitHub コメントのテンプレートを含む、§ 4 の手順全体。
• references/maintenance_modes.md — 概要／比較／目標の転換／ 中止／再実行の手順全体。
• references/preflight_evidence.md — Evidence 形式の仕様。

テンプレート

• templates/JOURNAL.md — 4 セクションのインデックスのひな形。
• templates/experiment_design.md — Status ブロック付きの設計ノート。

書き換えずにコピーしてください。