iterate-from-user

ユーザーからの反復

ソース：ユーザー本人、またはユーザーが示したもの（記事、issue、仕様書、リポジトリ）。出力：iterate-ml-experiment に渡す、ユーザー確認済みの Proposal ブロック。

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

このスキルはjournal/ファイルを決して書き込まず、受け入れ基準を決して作成しません。会話文として単一のProposal ブロックを返します（末尾の「返される内容」に全体の形式を記載）： Question、Motivation（Sourceフィールド付き。引用、URL、パス）、Method outline、Open gaps。すべての分岐で必須です：

• 3つの方向性を定める質問すべてに回答していること（「3つの方向性を定める質問」を参照）。
• 統合内容の確認ゲートを通過し、ユーザーが「はい」と回答していること（「返す前に確認」を参照）。
• **Source**フィールドが具体的であること：ユーザーの引用、主張の正確な内容を含む記事のURL、gh issueのリンク、または行番号付きの仕様ファイルのパス。

このスキルには**「提案なし」という結果はありません**。このスキルが起動するのは、親のソース選択メニューでユーザーがuserを選んだ場合のみです。手元に情報がない場合は、親のメニューが再表示されます。

停止条件

• journal/ ファイルを書き込まないでください。 それは iterate-ml-experiment の担当です。このスキルは Proposal を 会話テキストとして返し、ファイルは親スキルが作成します。
• 記憶を頼りにソースの内容を推測しないでください。 ユーザーが 記事、issue、またはファイルに言及した場合は、取得または読み込みを 行ってください。タイトルや一行の説明から内容を再構成しないでください。
• 返す前に確認してください。 Proposal を親に返すのは、ユーザーが 明示的に「はい、それでお願いします」と伝えた後だけです。 Proposal (...) ブロックより前に、統合確認の質問を出してください。 自由記述の「うーん」「たぶん」「興味深い」は確認にはなりません。 「返す前に確認する」の節を参照してください。
• GitHub から取得する前に gh の認証状態を確認してください。 gh issue view／gh api を呼び出す前に、gh auth status を実行してください（低コストで、結果はキャッシュされます）。 未認証の場合は、ユーザー自身で gh auth login を実行するよう依頼する （プロンプトで ! gh auth login を提案する）か、issue の本文を 直接貼り付けてもらってください。gh の呼び出しが失敗すると分かりにくい エラーになるため、認証状態を確認して失敗の原因を明確にしてください。
• 返す前に目標の変更を指摘してください。 ユーザーのアイデア （またはソース）によって、JOURNAL.md の Status に記録された プロジェクトの目標が実質的に変わる場合（出力形式が変わる （点推定 → 予測区間）、後続の利用者が変わる （オフラインバッチ → オンラインサービング）、指標の種類が変わる （二乗誤差 → カバレッジ）など）は、Proposal を返す前に質問として 提示してください。「この変更では JOURNAL.md の Status が から に変わります。まず目標を確認または修正しますか？」 と尋ねてください。 Status ブロックに古い目標が記載されたまま、親の実験ごとの設計メモで 成功の定義を暗黙に変更してはいけません。
• 新しい依存関係は、前提ではなく確認が必要です。 Proposal でプロジェクトの 既存環境にないライブラリ（記事で使われている lightgbm／pytorch／jax など）が必要になる場合、既成事実として Method outline に黙って含めて はいけません。未解決の点（「このアプローチには が必要です。 追加してよいですか？ それとも既存のスタックに合わせて調整しますか？」）として 指摘し、解決は data-science-python-stack とユーザーに委ねてください。 ユーザーの回答があるまでは、ライブラリ名は Open gaps の中だけ に記載し、Method outline には記載しないでください。
• ドメイン固有の主張にはユーザーの確認が必要です。 ソースの主張が、 記事／issue／仕様書だけでは こちらの データセットについて確かめられない こと（例：「特徴量 X はターゲットに対して単調である」 「このアセットクラスでは相互作用 Y が重要である」 「ユースケースは片側なので指標 Z が適切である」など）であれば、 それぞれの主張を Open gaps に列挙し、返す前にユーザーに確認してください。 論文にありがちな推測を事実として提示してはいけません。
• ハーネスレベルの「確認質問をしない」という指示は、このスキルの確認ゲートには 適用されません。 エントリーポイントの AskUserQuestion （記事リンク／リソースリンク／自由記述）と、「返す前に確認する」の節にある 統合確認ゲートは、確認質問ではなく、操作契約上のゲートです。ハーネスレベルの ヒントにかかわらず、必ず実行してください。特に、統合確認ゲートは省略できません。 ユーザーの意図が「明らか」に感じられる場合でも同様です。エージェントによる 言い換えで微妙なニュアンスが抜け落ちるリスクを検出するために、このゲートが あります。プロジェクトの CLAUDE.md の「Skill consultation contract」ルール 3 を参照してください。

エントリーポイントの AskUserQuestion

このスキルが呼び出されたら、AskUserQuestion を使って開始します。相互に排他的な選択肢を3つ提示し、暗黙のデフォルトは設けません。

• article-link — ユーザーが、このプロジェクト向けに応用したい科学記事（論文、ブログ記事、ライブラリのドキュメント）を持っています。 エージェントが内容を読み、統合し、確認します。
• resource-link — ユーザーが、試す内容を記述した GitHub issue、仕様ファイル、ノートのリポジトリ、その他の具体的な成果物を持っています。 エージェントが内容を読み、3つの問いに沿って要約し、確認します。
• free-text — ユーザーが口頭または文章でアイデアを持っており、直接説明します。 エージェントが3つの整理の問いに沿って内容を言い換え、確認します。

標準の AskUserQuestion UI を使用してください。現在のセッションで本当に利用できない場合に限り、プレーンテキストで選択肢を列挙してください。

例外 — エントリーポイントが事前解決済みの場合。 iterate-ml-experiment が、ソース選択メニューの段階で free-text の処理を終えてからここに処理を引き継ぐ場合（ユーザーがソース選択用の AskUserQuestion に URL、issue のリンク、または具体的なアイデアを直接入力した場合）、親から解決済みの分岐と内容が渡されます。この AskUserQuestion は省略し、内容をすでに受け取った状態で、該当する分岐に直接進んでください。ユーザーは実質的にすでに回答しています。分岐の最後にある統合内容の確認ゲートは引き続き実行します。省略されるのはエントリーポイントの質問のみです。

3つの整理の問い

このスキルが返すすべての Proposal は、すべての分岐において、次の問いに答える必要があります。

1. 何を学ぼうとしていますか？（「X を試す」を仮説に変換します）
2. なぜ今ですか？（このアイデアが浮上した具体的な理由 — ユーザーの発言を引用し、記事にリンクし、issue／ファイルを参照します）
3. 前回の実験と比べて何が変わりますか？（src/<pkg>/ 内で変更するファイルを、コードではなく文章で説明します）

不足があれば、ユーザーに尋ねてください。作り上げてはいけません。「どうすれば成功したとわかりますか？」という4つ目の問いはありません — 受け入れ基準はこのスキルの対象外です。

3つの分岐

分岐 A — article-link

ユーザーが article-link を選び、URL を提示します（貼り付け、追加のプロンプト、または親メッセージに暗黙的に含まれている場合）。

1. WebFetch で取得します（トピックしか提示されておらず、該当する論文を特定する必要がある場合は、先に WebSearch を使います）。要旨と、手法に最も関連するセクションを読みます。
2. 3つの整理の問いに対応づけます。 記事は何を提案していますか？ 採用するために src/<pkg>/ の具体的に何を変更しますか？ 「なぜ今ですか？」への回答には、記事の文言をそのまま引用します。
3. 適用時のリスクを明示します。 記事が異なるモダリティ、はるかに大規模なデータセット、または異なる対象タイプを扱っている場合、手法をそのまま適用できない可能性がある箇所を記載します。Proposal の Open gaps に明記します。
4. 新しい依存関係は暗黙的に Method outline に追加せず、未解決事項として明示します（上記の停止条件を参照）。
5. ドメイン固有の主張には Open gaps で [needs user confirmation] を付けます。
6. 返す前に確認します — § 返す前に確認を参照してください。

このターンに取得できない場合（ツールがない、URL にアクセスできない）： 3つの整理の問いは引き続き提示します（プレースホルダーでも構いません）。ドメインに関する主張は Open gaps に [needs user confirmation] を付けて記載し、§ 返す前に確認の内容を再提示してください。取得した本文がないことを理由に、これらの欄を省略してはいけません。

ブランチ B — resource-link

ユーザーが resource-link を選び、次を指定します。

• GitHub issue：以下の解決優先順位を適用してから、 gh issue view <N> --json title,body,labels,url を実行します（説明が 不十分な場合は、--json …,comments を使うか、 gh api repos/<owner>/<repo>/issues/<N>/comments で最新の コメントを約5件取得します。提案がスレッド内にあることもよくあります）。
• 仕様ファイル／メモファイル：ユーザーが指定したファイルを Read で読み込みます。周辺のファイルは検索しないでください。
• 参照リポジトリ：README.md／SPEC.md／NOTES.md、 またはユーザーが指定したトップレベルの提案文書を読み込みます。 ツリー全体を検索しないでください。重要な情報が埋もれてしまいます。

GitHub issue の解決優先順位（リポジトリを決して黙って推測しないでください）：

1. ユーザーのメッセージ内の明示的な URL （https://github.com/<owner>/<repo>/issues/<N>）——常に優先します。
2. org/repo#N 形式の略記 （probabl-ai/skore#42）——現在のコンテキストより優先します。
3. 修飾なしの #N または「issue 42」——現在の gh コンテキストに フォールバックします（gh repo view --json nameWithOwner で確認します）。見つからない場合は、取得する前に ユーザーに尋ねてください。

3種類すべてのリソースについて、以下を行います。

1. 3つの要件を明確にする質問に対応付けます。 リソースが明らかに したいことは何ですか？ リソースが示す動機は何ですか？ src/<pkg>/ で具体的に何が変わりますか？
2. 具体的に引用します。 Source フィールドには、issue の URL、 ファイルパス（必要に応じて行番号も）、またはリポジトリ名と ファイル名を記載します。リポジトリ名だけでは不十分です。
3. 不足点を明記します。 リソースが3つの要件のいずれかに答えて いない場合は、Open gaps に列挙します。
4. 返す前に確認します——以下を参照してください。

このターンで取得できない場合（gh も Read も使えない場合）： それでも gh auth status、続けて gh issue view <N> …（または指定された ファイルに対する Read）を示し、3つの要件を提示し、未回答の項目を Open gaps に列挙して、確認用の言い換えを提示します。issue の本文が ないことを理由に、これらの項目を省略してはいけません。

ブランチ C — free-text

ユーザーが free-text を選び、アイデアを直接入力します。

1. 平易な言葉で3つの要件を順に確認します。 要約時にユーザーの言葉を 引用し、ユーザー自身の枠組みを保ちます。
2. ユーザーの言葉を Source として扱います。 Proposal の Source フィールドには、ユーザーの引用（またはユーザーが承認した1文の 言い換え）を記載します。
3. 返す前に確認します——自由記述の提案も、要約確認の手順を通します。 エージェントによるアイデアの言い換えでは、ユーザーの意図が微妙に ずれてしまうことがあります。

返す前に確認する

すべてのブランチで、Proposal を iterate-ml-experiment に渡す前に、 エージェントはユーザーに短い平文の要約を提示し、明示的な承認を待ちます。

「 から、<一文で示した意図>を実現したいということだと理解しました。具体的には、src/<pkg>/<file>.py を変更し、<手法の概要>を実装します。未解決の点：<箇条書き>。プランナーに渡す前に、これでご希望の内容を捉えられているか確認してもよいですか？」

ユーザーが「はい」と答えるまでは、メッセージにはこの引用文だけを含めます。PENDING／NOT RETURNED と表示する場合も、Proposal ( ヘッダーは出力しないでください。

ユーザーの返答に応じて、次のように進めます。

• 「はい／確認／進めて」→ Proposal を返します。 親スキルがそこから journal/NN_*.md を作成します。この「はい」を得る前に Proposal (...) ブロックを出力しないでください。
• 「いいえ／少し違う／X を調整して」→ 修正して再確認します。 ユーザーが納得するまで要約を繰り返します。ユーザーの承認を得ていない Proposal を返さないでください。

この確認手順は必須です。これは親スキルの設計メモ承認ゲートに相当する ユーザー側の手順です。設計メモの作成前、修正コストが最も低い段階で 誤解を見つけられます。このターンにソース本文を取得できなかった場合も、 必ず言い換えを提示してください。

返す内容

設計メモではなく、短い構造化ブロックです。

Proposal (from: user via <article-link | resource-link | free-text>):
  Question:        <one sentence>
  Motivation:      <quote / URL / file path + the why-now reason>
  Source:          <article URL with claim | gh issue URL | spec file:line | user quote>
  Method outline:  <prose; which file in src/<pkg>/ is touched>
  Open gaps:       <transfer risks, dep questions, domain assertions
                    needing user confirmation, anything the source
                    didn't answer>

iterate-ml-experiment がこれを受け取り、 journal/NN_short_name.md を作成します。Success フィールドはありません—— このスキルは意図的に受け入れ基準を作成しません。実行後に結果を判断するのは ユーザーです。

関連スキル

• iterate-ml-experiment — 呼び出し元です。設計メモを管理します。
• iterate-from-skore — 唯一の兄弟戦略です。前回の skore レポートを分析してバックログに追加し、次の実験のソースとします。
• data-science-python-stack — 記事で新しい依存関係が導入される場合に参照します（上記の停止条件）。
• build-ml-pipeline / evaluate-ml-pipeline — Method outline が最終的に変更するファイル（pipeline.py、evaluate.py、…）を管理します。