idea-discovery

ワークフロー 1：アイデア発見パイプライン

各レビュー担当者の枠の前に、レビュー担当者の選択に従ってください： 呼び出しを解決 → .aris/reviewer.json → Claude Code のデフォルト（Codex MCP） を、正規のヘルパーリゾルバー経由で reviewer_route.py を使って適用し、この 枠のティア、新しいコンテキスト、ソース／画像入力、決定論的なゲートを維持します。 以下の Codex の例／固定指定は backend=codex にのみ適用されます。それ以外のルートでは、 それぞれの初回呼び出し／返信の契約を使用します。ルートと実際に返された ID を保存してください。 利用できない選択肢は REVIEW_UNAVAILABLE です。実際の ファミリー／完了状況／スコープに基づいて合否を分類してください。 呼び出し元によるレビュー担当者／モデル／エフォートのオーバーライドは、 レビュー担当者を含む子ワークフローに引き継いでください。生成ワーカーに変更はありません。

次の内容について、アイデア発見ワークフローを完全に実行してください：$ARGUMENTS

概要

このスキルは複数のサブスキルを連結し、単一の自動パイプラインとして実行します：

/research-lit → /idea-creator → /novelty-check → /research-review → /research-refine-pipeline
  (survey)      (brainstorm)    (verify novel)    (critical feedback)  (refine method + plan experiments)

各フェーズは、前のフェーズの出力を基に進みます。最終成果物は、ランキング済みのアイデアを含む検証済みの idea-stage/IDEA_REPORT.md と、最有力アイデアの洗練された提案書（refine-logs/FINAL_PROPOSAL.md）および実験計画（refine-logs/EXPERIMENT_PLAN.md）です。

定数

• PILOT_MAX_HOURS = 2 — GPU 1 台あたり 2 時間を超えると見積もられるパイロット実験はスキップします。レポートでは「手動パイロットが必要」と記載します。
• PILOT_TIMEOUT_HOURS = 3 — ハードタイムアウト：実行中のパイロットが 3 時間を超えた場合は終了します。入手可能であれば、部分的な結果を収集します。
• MAX_PILOT_IDEAS = 3 — 上位 3 件までのアイデアについて、並行してパイロットを実行します。残りのアイデアは机上検証のみ行います。
• MAX_TOTAL_GPU_HOURS = 8 — すべてのパイロットを通じた GPU の合計予算です。超過した場合、残りのパイロットはスキップし、レポートに記載します。
• AUTO_PROCEED = true — true の場合、チェックポイントは情報提供のみとなります。選択されたオプションを報告し、同じターン内で続行します。各選択チェックポイントで明示的なユーザー確認を求め、ターンを終了するには false に設定します。
• REVIEWER_MODEL = gpt-6-astra — Codex MCP 経由で使用するモデルです。backend=codex の場合は、OpenAI モデル（例：gpt-6-astra、gpt-6.1-sol）を使用します。サブスキルに渡されます。
• OUTPUT_DIR = idea-stage/ — アイデア段階の出力はすべてここに保存します。存在しない場合はディレクトリを作成します。
• ARXIV_DOWNLOAD = false — true の場合、/research-lit はフェーズ 1 で関連性の高い上位の arXiv PDF をダウンロードします。false（デフォルト）の場合は、メタデータのみを取得します。/research-lit に引き継がれます。
• COMPACT = false — true の場合、短いコンテキストのモデルやセッション復元用に、コンパクトな要約ファイルを生成します。このワークフローの最後に idea-stage/IDEA_CANDIDATES.md（上位 3～5 件のアイデアのみ）を書き出します。後続のスキルは、完全版の idea-stage/IDEA_REPORT.md の代わりにこちらを読み込みます。
• RENDER_HTML = true — true（デフォルト）の場合、ワークフローの終了時に /render-html を使って idea-stage/IDEA_REPORT.md を HTML に自動レンダリングします。フェーズ 3 ですでにソース MD が新規性レビューと複数モデルレビューを通過しているため、--no-review を使用します。スキップするには false に設定するか、— render html: false を指定します。
• REF_PAPER = false — アイデアの基礎とする参考論文です。ローカルの PDF パス、arXiv URL、または任意の論文 URL を指定できます。設定すると、まず論文が要約され（idea-stage/REF_PAPER_SUMMARY.md）、その後、アイデア生成でコンテキストとして使用されます。「このコードベースでこの論文を改善する」ワークフローでは、base repo と組み合わせてください。
• RESUMABLE = true — ステージのエビデンスを .aris/runs/<run_id>.json に記録し、最終レポートの完了を宣言する前に、決定論的なエビデンスゲートを必須とします。

💡 これらはデフォルト値です。例のようにスキルに伝えることで上書きできます：/idea-discovery "topic" — ref paper: https://arxiv.org/abs/2406.04329 または /idea-discovery "topic" — compact: true。

チェックポイントの実行ルール

Phase 0 の前に、$ARGUMENTS から AUTO_PROCEED を一度だけ解決し、ワークフロー全体を通してそのモードを維持してください。

• AUTO_PROCEED=true は非ブロッキングです。 チェックポイントは進捗の更新であり、質問ではありません。結果と自動的に選択された次のアクションを伝えたら、同じターン内でそのまま実行を続けてください。確認を求めたり、ユーザーからの入力を要求したり、スリープしたり、無応答を待ったり、チェックポイントでターンを終了したりしないでください。
• AUTO_PROCEED=false はブロッキングです。 選択肢を提示してユーザーに尋ね、ターンを終了してください。明示的な返信があった場合にのみ再開してください。

自動続行を「質問して、返信がなければ続行する」形で実装してはいけません。ターンが終了した後、無応答を理由にワークフローを再開することはできません。非ブロッキングの実行中でも、ユーザーはいつでも割り込めます。

このルールの対象は、AUTO_PROCEED によって制御される選択チェックポイントのみです。ユーザーが Feishu のインタラクティブゲートを明示的に有効にした場合、その外部承認または返信は意図的なブロッキング例外となります。無応答のタイムアウトとして扱うのではなく、ユーザーが制御するそのゲートを待ってください。Feishu のオフモード／プッシュのみのモードは、AUTO_PROCEED=true の場合も非ブロッキングのままです。

フェーズごとのエビデンスゲート（RESUMABLE = true）

/research-pipeline と同じ正規ヘルパーチェーン（.aris/tools/ → tools/ → $ARIS_REPO/tools/ → ~/.aris/repo/tools/）を使って、run_state.py と idea_discovery_gate.py を解決します。いずれかのヘルパーが利用できない場合、最終レポートは BLOCKED になります。状態記録なしで暗黙に続行してはいけません。

新しい実行では、方向性のスラッグと日付から <run_id> を導出し、--executor <actual-Claude-model>（例：claude-sonnet-4.5）を指定して、次の順序付き状態記録を開始します。

research-lit,idea-creator,novelty-check,research-review,research-refine-pipeline

各フェーズでは、開始時に running を記録し、成果物が存在することを確認してから done --artifact <path> を記録します。最終ゲートが散在する一時ファイルではなく正規レポートを確認できるよう、次の成果物ロケーターを使用してください。

フェーズ	成果物ロケーター
research-lit	idea-stage/IDEA_REPORT.md#literature-landscape
idea-creator	idea-stage/IDEA_REPORT.md#ranked-ideas
novelty-check	idea-stage/IDEA_REPORT.md#novelty-verification
research-review	idea-stage/IDEA_REPORT.md#external-critical-review
research-refine-pipeline	refine-logs/FINAL_PROPOSAL.md

novelty-check と research-review はレビュアーが関与するフェーズです。done ステータスや見出しだけでは、レビューのエビデンスになりません。各フェーズの実質的な調査結果を対応するレポートセクションに反映した後、まずそのフェーズを done として記録します。その後、設定されたレビュアーから身元を特定できる肯定的な判定が実際に返された場合に限り、実際に返されたモデルと永続的なスレッド／トレース ID を使って、ファミリー横断レシートを記録します。

<resolved-python> <resolved-run_state.py> accept . <run_id> novelty-check --verdict-id "<thread-or-trace-id>" --reviewer "<actual-reviewer-model>"
<resolved-python> <resolved-run_state.py> accept . <run_id> research-review --verdict-id "<thread-or-trace-id>" --reviewer "<actual-reviewer-model>"

いずれの値も捏造してはいけません。また、run-state 契約で求められる肯定的な判定なしに accept を呼び出してはいけません。novelty-check では、PROCEED と PROCEED WITH CAUTION の両方が肯定的な判定です。注意事項はパイロットへの指針であり、却下ではありません。否定的なのは ABANDON のみです。research-review では、レビューの最終的な見解がアイデアの放棄を主張していなければ肯定的です。リスクが列挙されていても、それだけで却下を意味するわけではありません。レビューが明確な立場を示さずに終わった場合は、同じレビュースレッドで「続行」または「放棄」の一行判定を求め、その回答に基づいて記録してください。返答がないことから肯定的だと推測してはいけません。否定的な判定ではレビューのレシートは発行されません。 フェーズは done のままにし、最終ゲートは BLOCKED として、存続するアイデアまたは新しいアイデアを選び、その後、該当するレビュアー関与フェーズを再実行してください。レビュアーが利用できない場合、有効な身元情報や回答が返されない場合、または出力がレポートに反映されていない場合も同様です。

フェーズ 5 の終了時に、次を実行します。

<resolved-python> <resolved-idea_discovery_gate.py> . <run_id> --report idea-stage/IDEA_REPORT.md

ゲートは実行結果を、run state の gates.idea-discovery-evidence に書き込みます。PASS の場合、2 つのレビュー用レシート、すべての必須成果物、および内容が空でない対応レポートセクションが検証されています（作成はされません）。フェーズごとの承認は、各ステージ独自のクロスモデルゲートで行います。ゼロ以外の終了コードの場合、ゲートはレポートに BLOCKED: <stage> evidence missing の行を明示的に書き込みます。ワークフローが完了したかのように示してはいけません。— resume <run_id> の場合、最初の未終端フェーズから開始し、最終確定前にゲートを再実行してください。

パイプライン

フェーズ 0：リサーチブリーフを読み込む（存在する場合）

ほかのフェーズを始める前に、プロジェクト内に詳細なリサーチブリーフがあるか確認します。

1. プロジェクトルート（または $ARGUMENTS で渡されたパス）に RESEARCH_BRIEF.md があるか確認します
2. 見つかった場合は読み込み、以下を抽出します。
   • 問題の説明と背景
   • 制約（計算資源、データ、タイムライン、発表先）
   • ユーザーがすでに試したこと／うまくいかなかったこと
   • ドメイン知識と対象外事項
   • 既存の成果（ある場合）
3. これを以降のすべてのフェーズにおける主要なコンテキストとして使用します。1 行のプロンプトに代わるものです
4. RESEARCH_BRIEF.md と 1 行の $ARGUMENTS の両方がある場合は、両者を統合します（詳細についてはブリーフを優先し、引数で方向性を定めます）

ブリーフがない場合は、通常どおり $ARGUMENTS をリサーチの方向性として進めます。

💡 テンプレートからブリーフを作成します：cp templates/RESEARCH_BRIEF_TEMPLATE.md RESEARCH_BRIEF.md — 1～2 ページ程度（4～8k 文字）に収め、長い資料はパスを記載して別ファイルに置きます。

フェーズ 0.5：参考論文の要約（REF_PAPER が設定されている場合）

REF_PAPER が false の場合は、完全にスキップします。

文献を検索する前に、参考論文を要約します。

1. arXiv URL の場合（例：https://arxiv.org/abs/2406.04329）：

   • /arxiv "ARXIV_ID" — download を呼び出して PDF を取得します
   • 最初の 5 ページ（タイトル、要旨、序論、手法の概要）を読みます

2. ローカル PDF パスの場合（例：papers/reference.pdf）：

   • PDF を直接読みます（最初の 5 ページ）

3. その他の URL の場合：

   • WebFetch で取得し、内容を抽出します

4. idea-stage/REF_PAPER_SUMMARY.md を生成します。

# Reference Paper Summary

**Title**: [paper title]
**Authors**: [authors]
**Venue**: [venue, year]

## What They Did
[2-3 sentences: core method and contribution]

## Key Results
[Main quantitative findings]

## Limitations & Open Questions
[What the paper didn't solve, acknowledged weaknesses, future work suggestions]

## Potential Improvement Directions
[Based on the limitations, what could be improved or extended?]

## Codebase
[If `base repo` is also set: link to the repo and note which parts correspond to the paper]

🚦 チェックポイント： 要約をユーザーに提示します。

📄 Reference paper summarized:
- Title: [title]
- Key limitation: [main gap]
- Improvement directions: [2-3 bullets]

Proceeding to literature survey with this as context.

フェーズ 1 とフェーズ 2 では、idea-stage/REF_PAPER_SUMMARY.md を追加のコンテキストとして使用します。/research-lit は関連研究や競合研究を検索し、/idea-creator は参考論文を発展させたり改善したりするアイデアを生成します。

フェーズ 1：文献調査

/research-lit を呼び出して研究分野の全体像を把握します。アイデアの発見は、Gemini の AI による幅広い網羅性が特に役立つ場面なので、ユーザーがアイデア発見の呼び出しで明示的な — sources: 指定をすでに行っていない限り、デフォルトでソースに gemini を含めます。

# If $ARGUMENTS already contains "— sources:", pass through unchanged
# (the user is in control of source selection):
/research-lit "$ARGUMENTS" — composed: idea-stage/IDEA_REPORT.md

# Otherwise (the common case), include gemini explicitly for broader discovery:
/research-lit "$ARGUMENTS" — sources: all, gemini — composed: idea-stage/IDEA_REPORT.md

— composed: idea-stage/IDEA_REPORT.md は /research-lit を合成モードにします（上記の 出力の整理 を参照）。単独の全体像ファイルを書き出す代わりに、レポートに取り込むための全体像を返します。フェーズ 1 ではレポートはまだ存在しません。この指定は、今後作成される正規ドキュメントを指しており、フェーズ 2 で /idea-creator が作成します。

gemini-cli がインストールされていない場合、/research-lit は警告を表示して Gemini ソースを問題なくスキップします。パイプラインは中断されません。アイデア発見で Gemini を明示的に無効にするには、/idea-discovery "topic" — sources: all を渡してください（これは自動追加なしの文字どおりのソースリストになります）。

この処理の内容：

• arXiv、Google Scholar、Semantic Scholar で最近の論文を検索します
• gemini-cli が利用可能な場合は、Gemini による幅広い発見（サブ問題の分解、名称のバリエーション、別名の網羅）も行います
• 分野の全体像を構築します：サブ分野、アプローチ、未解決の問題
• 構造的なギャップや繰り返し見られる限界を特定します
• 文献の要約を出力します（作業メモに保存）

🚦 チェックポイント： 全体像の要約をユーザーに提示します。

AUTO_PROCEED=true の場合（非ブロッキング）： 選択した方向性を報告し、 質問をせずに、同じターン内ですぐに続行します。

📚 Literature survey complete. Here's what I found:
- [key findings, gaps, open problems]

AUTO_PROCEED: selected [top-ranked direction]. Continuing to Phase 2.

AUTO_PROCEED=false の場合（ブロッキング）： 同じ調査結果を提示し、 これはご理解と一致していますか？アイデアを生成する前に、範囲を調整しますか？ と尋ねてから、 ターンを終了します。

• ユーザーが承認した場合 → 最適な方向性を選び、フェーズ 2 に進みます。
• ユーザーが変更を求めた場合（例：「X をもっと重視して」「Y は無視して」「範囲が広すぎる」）→ クエリを更新して検索を絞り込み、範囲を調整して /research-lit を再実行し、再度提示します。ユーザーが満足するまで繰り返します。

フェーズ 2：アイデアの創出＋絞り込み＋パイロット実験

ランドスケープのコンテキスト（利用可能な場合は idea-stage/REF_PAPER_SUMMARY.md も含む）を指定して /idea-creator を呼び出します。

/idea-creator "$ARGUMENTS" — composed: idea-stage/IDEA_REPORT.md

/idea-creator は、正式な成果物として idea-stage/IDEA_REPORT.md を管理します。— composed: ディレクティブにより、調査結果や新規性の調査結果が取り込まれ、LIT_LANDSCAPE.md／RESEARCH_REVIEW.md／MANIFEST.md が別途出力されることはありません。

実行内容：

• idea-stage/REF_PAPER_SUMMARY.md が存在する場合はコンテキストに含めます。アイデアは参考論文を基に構築、改善、または拡張する必要があります
• GPT-6-Astra xhigh を使用して、具体的なアイデアを 8～12 件ブレインストーミングします
• 実現可能性、計算コスト、簡易的な新規性調査に基づいて絞り込みます
• 上位アイデアを詳細に検証します（完全な新規性チェック＋悪魔の代弁者による検討）
• 利用可能な GPU でパイロット実験を並行して実行します（上位 2～3 件）
• 実験的なシグナルに基づいて順位付けします
• idea-stage/IDEA_REPORT.md を出力します

🚦 チェックポイント： 順位付けされたアイデアを記載した idea-stage/IDEA_REPORT.md をユーザーに提示します。

AUTO_PROCEED=true の場合（ブロッキングしない）： 自動選択を報告し、質問せずに同じターン内ですぐに続行します。

💡 Generated X ideas, filtered to Y, piloted Z. Top results:

1. [Idea 1] — Pilot: POSITIVE (+X%)
2. [Idea 2] — Pilot: WEAK POSITIVE (+Y%)
3. [Idea 3] — Pilot: NEGATIVE, eliminated

AUTO_PROCEED: selected [top-ranked idea(s)]. Continuing to Phase 3.

AUTO_PROCEED=false の場合（ブロッキングする）： 同じ順位表を提示し、 どのアイデアをさらに検証しますか？ それとも、異なる制約で再生成しますか？ と尋ねてから、ターンを終了します。

• ユーザーがアイデアを選択した場合 → 選択されたアイデアを使ってフェーズ 3 に進みます。
• ユーザーがすべてのアイデアに不満な場合 → フィードバック（「何が足りませんか？」「どのような方向性を希望しますか？」）を収集し、ユーザーの制約に合わせてプロンプトを更新してから、フェーズ 2（アイデアの創出）を再実行します。再生成する前に、すでに試した方向性（research-wiki の Failed Ideas および、存在する場合は .aris/runs/<run_id>.iterations.jsonl）を読み、すでに試した方向性に近すぎる候補を禁止します。これは方向性の多様性を確保するためです。夜間のハートビートによって実行が進む場合は、iteration_log.py note ... --direction "<frame>" で選択した方向性をそれぞれ記録し、後続のティックで類似候補を拒否できるようにします（shared-references/external-cadence.md → 停滞の検出と強制的な構造的転換を参照）。
• ユーザーがスコープの調整を希望する場合 → 方向性を洗練させてフェーズ 1 に戻ります。

フェーズ 3：新規性の詳細な検証

パイロット実験で肯定的なシグナルが得られた上位アイデアごとに、徹底的な新規性チェックを実行します。

/novelty-check "[top idea 1 description]"
/novelty-check "[top idea 2 description]"

実行内容：

• 複数の情報源を対象とした文献検索（arXiv、Scholar、Semantic Scholar）
• GPT-6-Astra xhigh との相互検証
• 直近 3～6 か月の同時期の研究を確認
• 最も近い既存研究と差別化のポイントを特定

詳細な新規性チェックの結果を idea-stage/IDEA_REPORT.md に反映します。 すでに発表済みと判明したアイデアは除外します。

フェーズ 4：外部からの批判的レビュー

残った上位アイデアについて、最も強い論拠、明示的なリスク、そして識別力のある最も低コストな次の実験を含む、率直な外部評価を得ます。中核となる仮説は書き換えの対象ではありません。

/research-review "[top idea with hypothesis + pilot results]" — composed: idea-stage/IDEA_REPORT.md

composed モードでは、/research-review の結論が idea-stage/IDEA_REPORT.md に統合され、プロジェクトルートに個別のレビュー用 .md を作成する代わりに、.aris/traces/… のパスが引用されます。

実行内容：

• GPT-6-Astra xhigh がシニアレビューアー（NeurIPS／ICML レベル）として評価します
• アイデアを採点し、弱点を特定して、最低限実行可能な改善案を提案します
• 実験計画について具体的なフィードバックを提供します

レビューアーのフィードバックと修正した計画を idea-stage/IDEA_REPORT.md に反映します。

フェーズ 4.5：手法の改良と実験計画

レビュー後、上位のアイデアを具体的な提案にまとめ、実験を計画します。

/research-refine-pipeline "[top idea description + pilot results + reviewer feedback]"

実行内容：

• 問題アンカーを固定し、スコープの逸脱を防ぎます
• GPT-6-Astra によるレビューを通じて手法を改良します。レビュアーが指摘したリスクは次のテストを選ぶために使い、コンポーネントの追加には使いません。スコアは参考情報であり、レビュアーに気に入られることより、中心的な仮説の維持を優先します
• アブレーション、予算、実行順序を含む、主張に基づいた実験ロードマップを作成します
• 出力：refine-logs/FINAL_PROPOSAL.md、refine-logs/EXPERIMENT_PLAN.md、refine-logs/EXPERIMENT_TRACKER.md

🚦 チェックポイント： 改良後の提案の概要を提示します。

AUTO_PROCEED=true の場合（ブロッキングなし）： 提案が選定されたことを伝え、質問せずに同じターン内ですぐに続行します。

🔬 Method refined and experiment plan ready:
- Problem anchor: [anchored problem]
- Method thesis: [one sentence]
- Dominant contribution: [what's new]
- Must-run experiments: [N blocks]
- First 3 runs to launch: [list]

AUTO_PROCEED: accepted the top proposal. Continuing to Final Report.

AUTO_PROCEED=false の場合（ブロッキングあり）： 同じ概要を提示し、Proceed to implementation? Or adjust the proposal? と尋ねてから、ターンを終了します。

• ユーザーが承認 → 最終レポートに進みます。
• ユーザーが変更を希望 → フィードバックを /research-refine に渡し、もう一度改良します。
• ライトモード： パイロット実験で結論が出なかった場合も、次に行う、最小限で判別可能な実験計画を作成します。レビュアーのスコアだけを理由にアイデアの評価を下げてはいけません。

フェーズ 5：最終レポート

蓄積したすべての情報を使って idea-stage/IDEA_REPORT.md を完成させます。

# Idea Discovery Report

**Direction**: $ARGUMENTS
**Date**: [today]
**Pipeline**: research-lit → idea-creator → novelty-check → research-review → research-refine-pipeline

## Executive Summary
[2-3 sentences: best idea, key evidence, recommended next step]

## Literature Landscape
[from Phase 1]

## Ranked Ideas
[from Phase 2, updated with Phase 3-4 results]

## Novelty Verification
[from Phase 3]

## External Critical Review
[from Phase 4]

### 🏆 Idea 1: [title] — RECOMMENDED
- Pilot: POSITIVE (+X%)
- Novelty: CONFIRMED (closest: [paper], differentiation: [what's different])
- Reviewer score: X/10
- Next step: implement full experiment → /auto-review-loop

### Idea 2: [title] — BACKUP
...

## Eliminated Ideas
[ideas killed at each phase, with reasons]

## Refined Proposal
- Proposal: `refine-logs/FINAL_PROPOSAL.md`
- Experiment plan: `refine-logs/EXPERIMENT_PLAN.md`
- Tracker: `refine-logs/EXPERIMENT_TRACKER.md`

## Next Steps
- [ ] /run-experiment to deploy experiments from the plan
- [ ] /auto-review-loop to iterate until submission-ready
- [ ] Or invoke /research-pipeline for the complete end-to-end flow

このレポートを完成版として提示する前に、上記のステージごとのエビデンスゲートを実行します。ゲートの結果が BLOCKED の場合はレポートの一部として記載し、省略すべき警告として扱ってはいけません。

フェーズ 5.5：コンパクトファイルの作成（COMPACT = true の場合）

COMPACT が false の場合は完全にスキップします。

生き残った上位 3～5 件のアイデアを簡潔にまとめた idea-stage/IDEA_CANDIDATES.md を作成します。

# Idea Candidates

| # | Idea | Pilot Signal | Novelty | Reviewer Score | Status |
|---|------|-------------|---------|---------------|--------|
| 1 | [title] | +X% | Confirmed | X/10 | RECOMMENDED |
| 2 | [title] | +Y% | Confirmed | X/10 | BACKUP |
| 3 | [title] | Negative | — | — | ELIMINATED |

## Active Idea: #1 — [title]
- Hypothesis: [one sentence]
- Key evidence: [pilot result]
- Next step: /experiment-bridge or /research-refine

このファイルは意図的に小さく（約 30 行）、後続のスキルやセッション復旧時に、約 200 行以上ある idea-stage/IDEA_REPORT.md 全体を読み込まずに内容を確認できるようにしています。

フェーズ 5.6：リサーチ契約の作成（常に実施 — COMPACT の設定にかかわらず）

フェーズ 4 が RECOMMENDED のアイデアで終了した場合、templates/RESEARCH_CONTRACT_TEMPLATE.md（リポジトリのルートまたは $ARIS_REPO/templates/ からテンプレートを解決）を使って idea-stage/docs/research_contract.md を作成し、選定したアイデアと選定理由、中心的な主張、説得力のある最低限のエビデンス、次のステップへのポインターを記入します。実行中に RECOMMENDED のアイデアがなかった場合に限り、スキップします。

このファイルは W1 → W1.5 の引き継ぎに使う焦点を絞った作業契約です。/experiment-bridge はこれに基づいて実装し、/result-to-claim と /ablation-planner は主張のソースとして参照します。また、セッション復旧時の重要度が 2 番目に高いファイル（docs/SESSION_RECOVERY_GUIDE.md）でもあります。セッションがクラッシュした場合、完全なアイデアプールではなく、この契約から ACTIVE のアイデアを再読み込みします。

出力プロトコル

すべての出力ファイルで、以下の共通プロトコルに従ってください。

• 出力構成プロトコル — パイプラインごとに正規の成果物を 1 つ作成します。サブスキルの調査結果をまとめ、内容が重複する .md ファイルを乱立させないでください
• 出力バージョニングプロトコル — まずタイムスタンプ付きファイルを書き、その後、固定名のファイルにコピーします
• 出力マニフェストプロトコル — 15 件の成果物のしきい値を超えた場合に限り、MANIFEST.md を管理します（「すべての出力を記録」するものではありません）
• 出力言語プロトコル — プロジェクトの言語設定に従います

出力の整理 — 正本となるドキュメントは1つ、Markdownファイルの重複なし（必須）

このパイプラインは、サブスキルを合成モードで実行します（output-composition.mdを参照）。正本となる成果物を1つだけ管理し、各サブスキルの調査結果をそこにまとめます。それぞれが内容の重複するファイルを出力することはありません。具体的には、このワークフローでは以下のとおりです。

1. idea-stage/IDEA_REPORT.mdを唯一の正本となる成果物とします。 サブスキルによる中間調査結果（文献の動向、新規性に関するメモ、外部レビュー）は、セクションや付録としてここにまとめます。サブスキルが単独でファイルを出力できるからといって、それらを個別ファイルにはしません。サブスキルが作業用ファイルを作成した場合は、その独自の内容をレポートに取り込み、フェーズ終了時に作業用ファイルを削除します。
2. すべてのサブスキル（/research-lit、/idea-creator、/research-review）に— composed: idea-stage/IDEA_REPORT.mdを渡します。 これにより、出力を散在させずにまとめるよう明示的に指示します。これを指定しない場合、サブスキルは設計上、単独で出力します。
3. 改良した手法の出力はrefine-logs/（FINAL_PROPOSAL.md／EXPERIMENT_PLAN.md／EXPERIMENT_TRACKER.md）に保存します。 idea-stage/以下に別ファイルとして再掲しないでください。レポートからはリンクを張り、内容をコピーしません。
4. ファイルが少数の場合、MANIFEST.mdは作成しません。output-manifest.mdに記載された15成果物のしきい値を超える場合にのみ作成します。
5. パイロットの作業用ファイルは破棄可能です。 再利用可能なパイロットスクリプトと、結果ファイル1つ（pilot_results.jsonlまたは簡潔なサマリー）を残します。数値がレポートに記載されたら、ランチャーのログ、スモークテスト用ファイル、重複する*_summary.jsonを削除します。
6. モデル間レビューのトレースは.aris/traces/…（監査証跡）に保存します。 idea-stage/以下に人が読むためのコピーも残さないでください。レポートからトレースのパスを参照します。
7. 完了前に、 idea-stage/の直下にあるファイルはおおむね次のものにします。IDEA_REPORT.md（＋.html）、パイロットスクリプトと結果、refine-logs/ディレクトリです。レポートに含まれない内容を持つ場合を除き、ほかのファイルは残しません。

HTMLビューのレンダリング（RENDER_HTML = trueの場合に自動実行）

フェーズ4でidea-stage/IDEA_REPORT.md（および任意のIDEA_CANDIDATES.md）を最終化したら、レポートに対して/render-htmlを実行します。これにより、タブレットやスマートフォンで読める単一ファイルのHTMLビューをユーザーに提供できます。

/render-html "idea-stage/IDEA_REPORT.md" --no-review

--no-reviewを指定するのは意図的です。ソースのMarkdownは、このスキル独自の新規性レビューとモデル間レビューをすでに通過しています。HTMLレンダリングは構造を変換するものであり、新たな主張監査のゲートではありません。出力先はidea-stage/IDEA_REPORT.htmlで、ソースのSHA256とレンダリング時刻が埋め込まれます。

ブロッキングではありません： /render-htmlに失敗した場合（ヘルパーがない、Codex MCPを利用できない、ファイル書き込みエラーなど）は、失敗を記録して続行します。HTMLビューは便利な成果物であり、フェーズ4の前提条件ではありません。

RENDER_HTML = falseの場合は、この手順を省略します。

主なルール

• 大きなファイルの処理：ファイルサイズが原因で Write ツールが失敗した場合は、直ちに Bash（cat << 'EOF' > file）を使ってチャンクに分けて書き込み、再試行してください。ユーザーに許可を求めず、何も言わずに実行してください。

• **フェーズを飛ばさないでください。**各フェーズでは絞り込みと検証を行います。飛ばすと、後で無駄な作業につながります。

• **フェーズ間でチェックポイントを設けてください。**見つかった内容を簡潔にまとめます。AUTO_PROCEED=true の場合は、次に実行するアクションを示して、同じターン内で続行してください。false の場合は質問して、ターンを終了してください。

• **判断ではなく、パイロットに中止を決めさせてください。**安価なパイロットで「不可」と分かる方が、実装に1か月かけてから「不可」と分かるより優れています。ただし、中止の判断には、好みではなく、実証的なシグナルか、公開済み論文の明示が必要です。書面上で自分のアイデアを思いとどまらせていると、実行するものが何もないパイプラインになってしまいます。

• **理論的な魅力より、実証的なシグナルを優先してください。**パイロットで肯定的な結果が得られたアイデアは、「素晴らしそうだ」というだけで根拠のないアイデアより優先されます。

• **すべてを記録してください。ただし、ばらばらのファイルではなく、1つのレポートにまとめてください。**行き止まりや除外したアイデアにも価値があります。これらは idea-stage/IDEA_REPORT.md のセクションとして記録してください（上記の出力の整理を参照）。フェーズごとに別の .md ファイルを作らないでください。

• **レビュー担当者には正直に伝えてください。**レビュー用プロンプトには、否定的な結果や失敗したパイロットも含めてください。

• Feishu 通知は任意です。~/.claude/feishu.json が存在する場合は、各フェーズの移行時に checkpoint を、最終レポートの作成時に pipeline_done を送信してください。ファイルが存在しないか、通知がオフの場合は、何もせずにスキップしてください。

Workflow 2 との連携

このパイプラインで検証済みの有力なアイデアが得られた後：

/idea-discovery "direction"         ← you are here (Workflow 1, includes method refinement + experiment planning)
/run-experiment                     ← deploy experiments from the plan
/auto-review-loop "top idea"        ← Workflow 2: iterate until submission-ready

Or use /research-pipeline for the full end-to-end flow.