research-refine

リサーチのブラッシュアップ：課題に根ざした、洗練された、フロンティアを意識した計画の改善

改善して具体化します：$ARGUMENTS

概要

このスキルは、研究課題は明確になっているものの、技術的な道筋がまだ曖昧な場合に使用します。目的は、冗長な提案書やベンチマークの買い物リストを作ることではありません。曖昧な方向性を、実装に十分な具体性があり、論文として価値を感じさせるほど洗練され、基盤モデル時代に響くほど現代的な 課題 -> 焦点を絞った手法 -> 最小限の検証 という文書にまとめることです。

このスキルでは、次の4つの原則を重視します。

1. 元の課題を見失わないこと。 不変の 課題アンカー を固定し、すべてのラウンドで再利用します。
2. 必要十分な最小の仕組みを選ぶこと。 ボトルネックを直接解消する、最小限の介入を優先します。
3. 1本の論文に、主要な貢献は1つ。 明確な主張を1つと、補助的な貢献を最大1つに絞ります。
4. 最新技術の活用は前提であり、飾りではありません。 LLM / VLM / Diffusion / RL / 蒸留 / 推論時スケーリングがボトルネックに自然に適合する場合は、具体的に活用します。流行語として付け足してはいけません。

User input (PROBLEM + vague APPROACH)
  -> Phase 0 (Claude): Freeze Problem Anchor
  -> Phase 1 (Claude): Scan grounding papers -> identify technical gap -> choose the sharpest route -> write focused proposal
  -> Phase 2 (Codex/GPT-6-Astra): Review for fidelity, specificity, contribution quality, and frontier leverage
  -> Phase 3 (Claude): Anchor check + simplicity check -> revise method -> rewrite full proposal
  -> Phase 4 (Codex, same thread): Re-evaluate revised proposal
  -> Repeat Phase 3-4 until OVERALL SCORE >= 9 or MAX_ROUNDS reached
  -> Phase 5: Save full history to refine-logs/
  -> Optional handoff: /experiment-plan for a detailed execution-ready experiment roadmap

定数

• REVIEWER_MODEL = gpt-6-astra — Codex MCP 経由で使用するレビュアーモデルです。
• MAX_ROUNDS = 5 — レビューと改訂を行うラウンドの最大数です。
• SCORE_THRESHOLD = 9 — 停止するために必要な全体スコアの下限です。
• OUTPUT_DIR = refine-logs/ — ラウンドファイルと最終レポートを保存するディレクトリです。
• MAX_LOCAL_PAPERS = 15 — 根拠を得るために確認するローカルの論文／メモの最大数です。
• MAX_CORE_EXPERIMENTS = 3 — このスキルにおける主要な検証ブロックのデフォルト上限です。
• MAX_PRIMARY_CLAIMS = 2 — 論文レベルの主張の目安となる上限です。主要な主張を1つと、補助的な主張を1つに絞ります。
• MAX_NEW_TRAINABLE_COMPONENTS = 2 — 真に新しい学習可能な要素の目安となる上限です。論文の成立に不可欠な場合に限り、これを超えてもかまいません。

必要に応じて引数で上書きできます。例：/research-refine "problem | approach" -- max rounds: 3, threshold: 9。

状態の永続化（チェックポイントからの復元）

長時間にわたる改善セッションは、途中で失敗することがあります（API タイムアウト、コンテキストの圧縮、セッションの中断など）。完了した作業が失われないよう、各フェーズの境界後に状態を refine-logs/REFINE_STATE.json に保存します。

{
  "phase": "review",
  "round": 1,
  "threadId": "019cd392-...",
  "last_score": 6.5,
  "last_verdict": "REVISE",
  "status": "in_progress",
  "timestamp": "2026-03-22T20:00:00"
}

フィールドの定義：

フィールド	値	意味
phase	"anchor" / "proposal" / "review" / "refine" / "done"	最後に完了したフェーズ
round	0–MAX_ROUNDS	現在のラウンド番号
threadId	string or null	codex-reply の継続に使用するレビュアーのスレッド ID
last_score	number or null	レビュアーによる直近の全体スコア
last_verdict	string or null	直近の判定（READY / REVISE / RETHINK）
status	"in_progress" / "completed"	ループの状態
timestamp	ISO 8601	状態が最後に書き込まれた日時

書き込みルール：

• 各フェーズの完了後に書き込みます（完了前には書き込みません）。毎回上書きし、保持するのは最新の状態のみです。
• 完了時（フェーズ 5 の終了時）は、"status": "completed" を設定します。

出力構成

refine-logs/
├── REFINE_STATE.json
├── round-0-initial-proposal.md
├── round-1-review.md
├── round-1-refinement.md
├── round-2-review.md
├── round-2-refinement.md
├── ...
├── REVIEW_SUMMARY.md
├── FINAL_PROPOSAL.md
├── REFINEMENT_REPORT.md
└── score-history.md

すべての round-N-refinement.md には、修正点だけでなく、課題アンカー付きの提案全体を含める必要があります。

ワークフロー

初期化（チェックポイントからの復旧）

各フェーズを開始する前に、前回の実行でチェックポイントが残されていないか確認します。

1. refine-logs/REFINE_STATE.json を確認します。

   • 存在しない場合 → 新規開始（通常どおりフェーズ 0 に進みます）
   • 存在し、status が "completed" の場合 → 新規開始（状態ファイルを削除します。前回の実行は完了しています）
   • 存在し、status が "in_progress" で、timestamp が 24 時間より前の場合 → 新規開始（停止または放棄された実行の古い状態です。ファイルを削除します）
   • 存在し、status が "in_progress" で、timestamp が 24 時間以内の場合 → 再開

2. 再開時は、状態ファイルを読み込んでコンテキストを復元します。

   • 既存の refine-logs/round-*.md ファイルをすべて読み、これまでの作業を復元します
   • 存在する場合は refine-logs/score-history.md を読み込みます
   • レビュースレッドの継続性を保つため、threadId を復元します
   • ユーザーに次のように通知します："チェックポイントが見つかりました。フェーズ: {phase}、ラウンド: {round} の後から再開します。"
   • 保存された phase の値に基づいて、次のフェーズに進みます。

   保存された phase	完了した内容	再開するフェーズ
   "anchor"	フェーズ 0 完了	フェーズ 1（round-0 のコンテキストからアンカーを読み込みます）
   "proposal"	フェーズ 1 完了	フェーズ 2（round-0-initial-proposal.md を読み込みます）
   "review"	フェーズ 2 または 4 完了	フェーズ 3（最新の round-N-review.md を読み込みます）
   "refine"	フェーズ 3 完了	フェーズ 4（最新の round-N-refinement.md を読み込みます）

3. 新規開始時は、refine-logs/ ディレクトリが存在することを確認し、フェーズ 0 に進みます。

フェーズ 0：問題のアンカーを固定する

提案を始める前に、ユーザーの変更できない根本的な問題を抽出します。このアンカーは、すべての提案と各改善ラウンドに一字一句そのまま記載する必要があります。

以下を記述します。

• 根本的な問題：解決すべき技術的な問題は何ですか？
• 必ず解決すべきボトルネック：現在の手法にある、容認できない具体的な弱点は何ですか？
• 対象外：このプロジェクトの目標ではないこととして、明示されている内容は何ですか？
• 制約：計算資源、データ、時間、ツール、発表先、デプロイに関する制限。
• 成功条件：この手法が実際の問題に対処しているとユーザーが判断するには、どのような証拠が必要ですか？

後のレビュー担当者からのフィードバックによって解決対象の問題が変わる場合は、逸脱として明示し、異議を唱えるか、慎重に適応します。

チェックポイント： refine-logs/REFINE_STATE.json に {"phase": "anchor", "round": 0, "threadId": null, "last_score": null, "last_verdict": null, "status": "in_progress", "timestamp": "<now>"} を書き込みます。

フェーズ 1：初期提案を作成する

ステップ 1.1：根拠資料を調査する

まず papers/ と literature/ を確認します。以下に答えるために必要な関連箇所のみを読みます。

• 現在の手法では、どのようなメカニズムを使用していますか？
• この問題に対して、どこで具体的に失敗しますか？
• 最近の LLM／VLM／Diffusion／RL 時代の技術のうち、実際に関連するものはどれですか？
• 再利用できる学習目的、表現、インターフェースは何ですか？
• 実際の手法と、名前を変えただけの抽象的なアイデアを区別する詳細は何ですか？

ローカルの資料だけでは不十分な場合は、オンラインで最近のトップカンファレンスや arXiv の研究を検索します。要旨だけでなく、手法のセクション、学習設定、失敗モードに注目します。

ステップ 1.2：技術的なギャップを特定する

一般的な研究課題だけで終わらせないでください。ギャップを具体的に示します。

1. 現在のパイプラインの失敗箇所：ベースラインはどこで破綻しますか？
2. 単純な修正では不十分な理由：コンテキストの拡張、データの追加、プロンプト、メモリバンク、モジュールの積み重ねでは、なぜ不十分なのですか？
3. 必要最小限の介入：ボトルネックを解消できる可能性がある、最小限の追加メカニズムは何ですか？
4. フロンティアに即した代替案：基盤モデル時代のプリミティブを用いた、ボトルネックにより適合する最新のアプローチはありますか？
5. 技術的な核心的主張：トップカンファレンスの厳しい審査にも耐えうる、具体的なメカニズム上の主張は何ですか？
6. 必要な証拠：その主張を裏付けるために最低限どのような証明が必要ですか？

Step 1.3: 最も有望なルートを選ぶ

手法を確定する前に、どちらも有望な候補であれば、2つのルートを比較します。

• Route A: 洗練された最小ルート — ボトルネックを直接狙う最小限の仕組みです。
• Route B: 最先端技術を活用するルート — よりモダンな手法を用いますが、より明快で強力なストーリーにつながる場合に限り、LLM／VLM／Diffusion／RL／蒸留／推論時スケーリングを活用します。

そのうえで、以下を決定します。

• 示された制約のもとで、どちらのルートがより強い論文につながりそうですか？
• 最も近い先行研究と比べて、どちらのルートの新規性をより明快に説明できますか？
• どちらのルートなら、貢献が拡散するのを避けられますか？

両方のルートが弱い場合は、デフォルトでそれらを組み合わせて大規模なシステムを構築するのではなく、問題の捉え方を見直してください。

Step 1.4: まず手法を具体化する

提案では、「実際にどう構築するのか」に答える必要があります。幅広い実験よりも手法の詳細を優先し、新たな発明よりも既存のものの再利用を優先してください。

以下を説明します。

1. 1文で示す手法の主張：最も強い仕組みに関する主張を1つ示します。
2. 貢献の焦点：主要な貢献を1つ、補助的な貢献を最大1つに絞ります。
3. 複雑さの予算：何を固定または再利用し、何を新たに追加するのか、また、魅力的でも意図的に除外する要素を示します。
4. システム構成図：モジュール、データフロー、入力、出力を示します。
5. 表現の設計：どのような潜在表現、埋め込み、プラントークン、報酬信号、メモリ状態、またはアラインメント空間を使用しますか？
6. 学習レシピ：データソース、教師信号、疑似ラベル付け、負例、カリキュラム、損失関数、重み付け、段階的学習か同時学習かを説明します。
7. 推論経路：学習済みコンポーネントをテスト時にどう使用し、どの信号をどこに渡すのかを説明します。
8. 仕組みを小さく保つ理由：より大規模な構成が不要である理由を説明します。
9. 最先端技術の要素の正確な役割：LLM／VLM／Diffusion／RL のコンポーネントを使用する場合、それがプランナー、教師、批評器、報酬モデル、生成事前分布、探索コントローラー、蒸留元のいずれとして機能するのかを明示します。
10. 失敗への対処：何が問題になりうるのか、また、どのようなフォールバックや診断手段があるのかを説明します。
11. 新規性と洗練性の論拠：単なるモジュールの命名にとどまらない理由と、論文の焦点を維持できる理由を説明します。

手法の説明が「モジュールを追加する」または「プランナーを使う」だけにとどまる場合、具体性が不十分です。

Step 1.5: 主張を検証する最小限の実験を設計する

実験は手法を検証するためのものであり、文書の大部分を占めるものではありません。

中心となる主張ごとに、検証に必要な最小限かつ有効な実験を定義します。

• 検証する主張
• 必要なベースラインまたはアブレーション
• 決定的な指標
• 予想される変化の方向

追加ルール：

• **問題の軸（Problem Anchor）**を直接裏付ける実験ブロックを1つ設けます。
• 複雑さにリスクがある場合は、簡略化または削除の検証を1つ含めます。
• 最先端技術の要素が中核となる場合は、その選択が重要である理由を示す必要性の検証を1つ含めます。
• 基本は主要な実験ブロックを1～3個とし、実行計画の全体像は /experiment-plan に委ねます。

Step 1.6: 初期提案を書く

refine-logs/round-0-initial-proposal.md に保存します。

以下の構成を使用します。

# Research Proposal: [Title]

## Problem Anchor
- Bottom-line problem:
- Must-solve bottleneck:
- Non-goals:
- Constraints:
- Success condition:

## Technical Gap
[Why current methods fail, why naive bigger systems are not enough, and what mechanism is missing]

## Method Thesis
- One-sentence thesis:
- Why this is the smallest adequate intervention:
- Why this route is timely in the foundation-model era:

## Contribution Focus
- Dominant contribution:
- Optional supporting contribution:
- Explicit non-contributions:

## Proposed Method
### Complexity Budget
- Frozen / reused backbone:
- New trainable components:
- Tempting additions intentionally not used:

### System Overview
[Step-by-step pipeline or ASCII graph]

### Core Mechanism
- Input / output:
- Architecture or policy:
- Training signal / loss:
- Why this is the main novelty:

### Optional Supporting Component
- Only include if truly necessary:
- Input / output:
- Training signal / loss:
- Why it does not create contribution sprawl:

### Modern Primitive Usage
- Which LLM / VLM / Diffusion / RL-era primitive is used:
- Exact role in the pipeline:
- Why it is more natural than an old-school alternative:

### Integration into Base Generator / Downstream Pipeline
[Where the new method attaches, what is frozen, what is trainable, inference order]

### Training Plan
[Stagewise or joint training, losses, data construction, pseudo-labels, schedules]

### Failure Modes and Diagnostics
- [Failure mode]:
- [How to detect]:
- [Fallback or mitigation]:

### Novelty and Elegance Argument
[Closest work, exact difference, why this is a focused mechanism-level contribution rather than a module pile-up]

## Claim-Driven Validation Sketch
### Claim 1: [Main claim]
- Minimal experiment:
- Baselines / ablations:
- Metric:
- Expected evidence:

### Claim 2: [Optional]
- Minimal experiment:
- Baselines / ablations:
- Metric:
- Expected evidence:

## Experiment Handoff Inputs
- Must-prove claims:
- Must-run ablations:
- Critical datasets / metrics:
- Highest-risk assumptions:

## Compute & Timeline Estimate
- Estimated GPU-hours:
- Data / annotation cost:
- Timeline:

チェックポイント： {"phase": "proposal", "round": 0, ...} を指定して refine-logs/REFINE_STATE.json を更新します。

フェーズ 2：外部手法レビュー（第 1 ラウンド）

提案を GPT-6-Astra に送り、エレガンス優先、フロンティアを考慮、手法優先でレビューしてもらいます。レビュアーは、実験メニューを拡充するのではなく、批評の大部分を手法そのものに費やす必要があります。Codex MCP では、プロンプトが大きくなったら、ルーブリックと提案の全体をインラインで含めないでください。代わりに、以下の指示と refine-logs/round-0-initial-proposal.md の絶対パスを記載した refine-logs/codex_round_1_review_bundle.md を作成し、MCP プロンプトは短くしてください。

mcp__codex__codex:
  model: REVIEWER_MODEL
  config: {"model_reasoning_effort": "xhigh"}
  prompt: |
    Read the review bundle at <absolute path to
    refine-logs/codex_round_1_review_bundle.md> and follow all instructions in
    it.

バンドルの内容：

    You are a senior ML reviewer for a top venue (NeurIPS/ICML/ICLR).
    This is an early-stage, method-first research proposal.

    Your job is NOT to reward extra modules, contribution sprawl, or a giant benchmark checklist.
    Your job IS to stress-test whether the proposed method:
    (1) still solves the original anchored problem,
    (2) is concrete enough to implement,
    (3) presents a focused, elegant contribution,
    (4) uses foundation-model-era techniques appropriately when they are the natural fit.

    Review principles:
    - Prefer the smallest adequate mechanism over a larger system.
    - Penalize parallel contributions that make the paper feel unfocused.
    - If a modern LLM / VLM / Diffusion / RL route would clearly produce a better paper, say so concretely.
    - If the proposal is already modern enough, do NOT force trendy components.
    - Do not ask for extra experiments unless they are needed to prove the core claims.

    Read the Problem Anchor first. If your suggested fix would change the problem being solved,
    call that out explicitly as drift instead of treating it as a normal revision request.

    Proposal path (read this file yourself): <absolute path to
    refine-logs/round-0-initial-proposal.md>

    Score these 7 dimensions from 1-10:

    1. **Problem Fidelity**: Does the method still attack the original bottleneck, or has it drifted into solving something easier or different?

    2. **Method Specificity**: Are the interfaces, representations, losses, training stages, and inference path concrete enough that an engineer could start implementing?

    3. **Contribution Quality**: Is there one dominant mechanism-level contribution with real novelty, good parsimony, and no obvious contribution sprawl?

    4. **Frontier Leverage**: Does the proposal use current foundation-model-era primitives appropriately when they are the right tool, instead of defaulting to old-school module stacking?

    5. **Feasibility**: Can this method be trained and integrated with the stated resources and data assumptions?

    6. **Validation Focus**: Are the proposed experiments minimal but sufficient to validate the core claims? Is there unnecessary experimental bloat?

    7. **Venue Readiness**: If executed well, would the contribution feel sharp and timely enough for a top venue?

    **OVERALL SCORE** (1-10): Weighted toward Problem Fidelity, Method Specificity, Contribution Quality, and Frontier Leverage.
    Use this weighting: Problem Fidelity 15%, Method Specificity 25%, Contribution Quality 25%, Frontier Leverage 15%, Feasibility 10%, Validation Focus 5%, Venue Readiness 5%.
    (This weighted-axis rubric is the repo's working precedent for
    `shared-references/taste-calibration.md`; if curated known-good/known-bad
    past proposals are available — e.g. from research-wiki's accepted/rejected
    idea history — score 3 of each on these axes FIRST to anchor the scale, and
    name in the review which anchor the proposal sits closest to.)

    For each dimension scoring < 7, provide:
    - The specific weakness
    - A concrete fix at the method level (interface / loss / training recipe / integration point / deletion of unnecessary parts)
    - Priority: CRITICAL / IMPORTANT / MINOR

    Then add:
    - **Simplification Opportunities**: 1-3 concrete ways to delete, merge, or reuse components while preserving the main claim. Write "NONE" if already tight.
    - **Modernization Opportunities**: 1-3 concrete ways to replace old-school pieces with more natural foundation-model-era primitives if genuinely better. Write "NONE" if already modern enough.
    - **Drift Warning**: "NONE" if the proposal still solves the anchored problem; otherwise explain the drift clearly.
    - **Verdict**: READY / REVISE / RETHINK

    Verdict rule:
    - READY: overall score >= 9, no meaningful drift, one focused dominant contribution, and no obvious complexity bloat remains
    - REVISE: the direction is promising but not yet at READY bar
    - RETHINK: the core mechanism or framing is still fundamentally off

重要： この呼び出しの threadId を、以降のすべてのラウンドで使えるよう保存してください。

重要： 生のレスポンス全文を一字一句そのまま保存してください。

レビューを refine-logs/round-1-review.md に保存し、生のレスポンスは <details> ブロック内に記載してください。

チェックポイント： refine-logs/REFINE_STATE.json を {"phase": "review", "round": 1, "threadId": "<saved>", "last_score": <parsed>, "last_verdict": "<parsed>", ...} で更新してください。

フェーズ 3：フィードバックを解析し、手法を改訂する

ステップ 3.1：レビューを解析する

以下を抽出します。

• 問題への忠実性
• 手法の具体性
• 貢献の質
• フロンティアの活用
• 実現可能性
• 検証への注力
• 投稿先への準備状況
• 総合スコア
• 判定
• 方向性の逸脱に関する警告
• 簡素化の機会
• 最新化の機会
• 優先度順のアクション項目

refine-logs/score-history.md を更新します。

# Score Evolution

| Round | Problem Fidelity | Method Specificity | Contribution Quality | Frontier Leverage | Feasibility | Validation Focus | Venue Readiness | Overall | Verdict |
|-------|------------------|--------------------|----------------------|-------------------|-------------|------------------|-----------------|---------|---------|
| 1     | X                | X                  | X                    | X                 | X           | X                | X               | X       | REVISE  |

停止条件：総合スコア >= SCORE_THRESHOLD で、判定が READY かつ未解決の方向性の逸脱に関する警告がない場合は、フェーズ 5 に進みます。

ステップ 3.2：アンカーチェックとシンプルさチェックを行って改訂する

変更を加える前に、次のことを行います。

1. 問題のアンカーを一字一句そのままコピーします。
2. アンカーチェックを記述します。
   • 元のボトルネックは何ですか？
   • 現在の手法は、依然としてそれを解決していますか？
   • 盲目的に従うと方向性の逸脱を招くレビュアーの提案はどれですか？
3. シンプルさチェックを記述します。
   • 現在の主要な貢献は何ですか？
   • 削除、統合、または変更せずに維持できるコンポーネントはどれですか？
   • 不必要な複雑さを加えるレビュアーの提案はどれですか？
   • フロンティアのプリミティブが中心となっている場合、その役割は明確で、正当化されていますか？

次に、レビュアーのフィードバックに対応します。

• 妥当な場合：メカニズムを明確にし、可能であれば簡素化し、論文が実際に改善する場合は最新化します。
• 議論の余地がある場合：改訂しますが、根拠を用いて理由を説明します。
• 誤り、方向性の逸脱、または過剰な複雑化がある場合：ローカルの論文と問題のアンカーを根拠として反論します。

改訂では、以下を重視します。

• より明確な中心的貢献
• より少ない可変要素
• 優れた既存のバックボーンのより効果的な再利用
• 論文を改善する場合、基盤モデル時代をより自然に活用すること
• 主張に基づいた、より簡潔な実験

スコアを追い求めるためだけに、複数の並列的な貢献を追加しないでください。レビュアーが別のモジュールを求めた場合は、まず既存のバックボーンに、より優れたインターフェース、蒸留シグナル、報酬モデル、または推論ポリシーを適用することで同じ効果が得られないか検討してください。

refine-logs/round-N-refinement.md に保存します。

# Round N Refinement

## Problem Anchor
[Copy verbatim from round 0]

## Anchor Check
- Original bottleneck:
- Why the revised method still addresses it:
- Reviewer suggestions rejected as drift:

## Simplicity Check
- Dominant contribution after revision:
- Components removed or merged:
- Reviewer suggestions rejected as unnecessary complexity:
- Why the remaining mechanism is still the smallest adequate route:

## Changes Made

### 1. [Method section changed]
- Reviewer said:
- Action:
- Reasoning:
- Impact on core method:

### 2. [Novelty / modernity / feasibility / validation change]
- Reviewer said:
- Action:
- Reasoning:
- Impact on core method:

## Revised Proposal
[Full updated proposal from Problem Anchor through Claim-Driven Validation Sketch]

チェックポイント： refine-logs/REFINE_STATE.json を {"phase": "refine", "round": N, ...} で更新してください。

フェーズ 4：再評価（第 2 ラウンド以降）

改訂した提案を同じスレッドで GPT-6-Astra に再度送ります。ここでも、MCP ペイロードは短く保ちます。以下の再評価指示、主な変更点、および refine-logs/round-N-refinement.md の絶対パスを記載した refine-logs/codex_round_N_review_bundle.md を作成し、Codex にそのバンドルファイルを読むよう依頼してください。

mcp__codex__codex-reply:
  threadId: [saved from Phase 2]
  # inherits the thread's model/effort — do not re-send
  prompt: |
    Read the re-evaluation bundle at <absolute path to
    refine-logs/codex_round_N_review_bundle.md> and follow all instructions in
    it.

バンドルの内容：

    [Round N re-evaluation]

    I revised the proposal based on your feedback.
    First, check whether the original Problem Anchor is still preserved.
    Second, judge whether the method is now more concrete, more focused, and more current.

    Key changes:
    1. [Method change 1]
    2. [Method change 2]
    3. [Simplification / modernization / pushback if any]

    Revised proposal path (read this file yourself): <absolute path to
    refine-logs/round-N-refinement.md>

    Please:
    - Re-score the same 7 dimensions and overall
    - State whether the Problem Anchor is preserved or drifted
    - State whether the dominant contribution is now sharper or still too broad
    - State whether the method is simpler or still overbuilt
    - State whether the frontier leverage is now appropriate or still old-school / forced
    - Focus new critiques on missing mechanism, weak training signal, weak integration point, pseudo-novelty, or unnecessary complexity
    - Use the same verdict rule: READY only if overall score >= 9 and no blocking issue remains

    Same output format: 7 scores, overall score, verdict, drift warning, simplification opportunities, modernization opportunities, remaining action items.

レビューを refine-logs/round-N-review.md に保存してください。

チェックポイント： refine-logs/REFINE_STATE.json を {"phase": "review", "round": N, "threadId": "<saved>", "last_score": <parsed>, "last_verdict": "<parsed>", ...} で更新してください。

以下のいずれかに達するまで、フェーズ 3 に戻ります。

• 総合スコア >= SCORE_THRESHOLD で、判定が READY かつ未解決の方向性の逸脱がない
• または MAX_ROUNDS に到達

フェーズ 5：最終レポートとログ

ステップ 5.1：refine-logs/REVIEW_SUMMARY.md を作成する

このファイルは、各ラウンドのレビューをまとめた概要記録です。各ラウンドで何を解決しようとしたのか、何が変わったのか、何が解決され、何が残ったのかを記載します。

# Review Summary

**Problem**: [user's problem]
**Initial Approach**: [user's vague approach]
**Date**: [today]
**Rounds**: N / MAX_ROUNDS
**Final Score**: X / 10
**Final Verdict**: [READY / REVISE / RETHINK]

## Problem Anchor
[Verbatim anchor used across all rounds]

## Round-by-Round Resolution Log

| Round | Main Reviewer Concerns | What This Round Simplified / Modernized | Solved? | Remaining Risk |
|-------|-------------------------|------------------------------------------|---------|----------------|
| 1     | [top issues from review] | [main method changes]                    | [yes / partial / no] | [if any] |
| 2     | ...                     | ...                                      | ...     | ...            |

## Overall Evolution
- [How the method became more concrete]
- [How the dominant contribution became more focused]
- [How unnecessary complexity was removed]
- [How modern technical leverage improved or stayed intentionally minimal]
- [How drift was avoided or corrected]

## Final Status
- Anchor status: [preserved / corrected / unresolved]
- Focus status: [tight / slightly broad / still diffuse]
- Modernity status: [appropriately frontier-aware / intentionally conservative / still old-school]
- Strongest parts of final method:
- Remaining weaknesses:

ステップ 5.2：refine-logs/FINAL_PROPOSAL.md を作成する

このファイルは、最終版のみをまとめた文書です。レビューに関するやり取り、ラウンドの履歴、生のレビュアー出力は含めず、最終提案のみを記載します。

# Research Proposal: [Title]

[Paste the final refined proposal only]

最終判定が READY でない場合も、現時点で最善の最終版をここに記載します。

ステップ 5.3：refine-logs/REFINEMENT_REPORT.md を作成する

# Refinement Report

**Problem**: [user's problem]
**Initial Approach**: [user's vague approach]
**Date**: [today]
**Rounds**: N / MAX_ROUNDS
**Final Score**: X / 10
**Final Verdict**: [READY / REVISE / RETHINK]

## Problem Anchor
[Verbatim anchor used across all rounds]

## Output Files
- Review summary: `refine-logs/REVIEW_SUMMARY.md`
- Final proposal: `refine-logs/FINAL_PROPOSAL.md`

## Score Evolution

| Round | Problem Fidelity | Method Specificity | Contribution Quality | Frontier Leverage | Feasibility | Validation Focus | Venue Readiness | Overall | Verdict |
|-------|------------------|--------------------|----------------------|-------------------|-------------|------------------|-----------------|---------|---------|
| 1     | ...              | ...                | ...                  | ...               | ...         | ...              | ...             | ...     | ...     |

## Round-by-Round Review Record

| Round | Main Reviewer Concerns | What Was Changed | Result |
|-------|-------------------------|------------------|--------|
| 1     | [top issues]            | [main fixes]     | [resolved / partial / unresolved] |
| 2     | ...                     | ...              | ...    |

## Final Proposal Snapshot
- Canonical clean version lives in `refine-logs/FINAL_PROPOSAL.md`
- Summarize the final thesis in 3-5 bullets here

## Method Evolution Highlights
1. [Most important simplification or focusing move]
2. [Most important mechanism upgrade]
3. [Most important modernization or justification for staying simple]

## Pushback / Drift Log
| Round | Reviewer Said | Author Response | Outcome |
|-------|---------------|-----------------|---------|
| 1     | [criticism]   | [pushback + anchor / evidence] | [accepted / rejected] |

## Remaining Weaknesses
[Honest unresolved issues]

## Raw Reviewer Responses

<details>
<summary>Round 1 Review</summary>

[Full verbatim response from GPT-6-Astra]

</details>

...

## Next Steps
- If READY: proceed to `/experiment-plan` for a full experiment roadmap, then `/run-experiment`
- If REVISE: manually address the remaining mechanism weaknesses, then re-run `/research-refine`
- If RETHINK: revisit the core mechanism, possibly with `/idea-creator`

ステップ 5.4：score-history.md を仕上げる

新しい評価軸を使った、スコア推移の完全な表が含まれていることを確認します。

ステップ 5.5：ユーザーに簡潔な概要を提示する

Refinement complete after N rounds.

Final score: X/10 (Verdict: READY / REVISE / RETHINK)

Anchor status:
- [preserved / drift corrected / unresolved concern]

Focus status:
- [tight / slightly broad / still diffuse]

Modernity status:
- [appropriately frontier-aware / intentionally conservative / still old-school]

Key method upgrades:
- [method change 1]
- [method change 2]

Remaining concerns:
- [if any]

Review summary: refine-logs/REVIEW_SUMMARY.md
Full report: refine-logs/REFINEMENT_REPORT.md
Final proposal: refine-logs/FINAL_PROPOSAL.md
Suggested next step: /experiment-plan

チェックポイント： refine-logs/REFINE_STATE.json を {"phase": "done", "status": "completed", ...} で更新します。

出力プロトコル

すべての出力ファイルに、以下の共通プロトコルを適用します。

• 出力のバージョン管理プロトコル — まずタイムスタンプ付きのファイルを書き込み、その後、固定名のファイルにコピーします
• 出力マニフェストプロトコル — すべての出力を MANIFEST.md に記録します
• 出力言語プロトコル — プロジェクトの言語設定に従います

重要なルール

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

• 毎ラウンド、まずアンカーを確認します。 常に同じ Problem Anchor を引き継ぎます。

• 論文には、中心となる貢献を1つだけ置きます。 論文に本当に必要な場合を除き、複数の貢献を並行して掲げないでください。

• 十分な機構のうち、最も小さいものを選びます。 大きければよいとは限りません。

• 新規開発より再利用を優先します。 強力な既存バックボーンを出発点とし、ボトルネックの解消に必要なものだけを追加します。

• 最新技術は前提であり、飾りではありません。 LLM／VLM／Diffusion／RL 時代のコンポーネントは、手法を強化するときに用い、提案を流行のように見せるだけの目的では使いません。

• 実験は最小限にします。 このスキルで必要な実験は、中心的な主張を立証するものだけです。

• 部品の数ではなく、機構をレビューします。 モジュールを長々と列挙しても、新規性にはなりません。

• 異論を唱えることを推奨します。 レビュアーのフィードバックによって方向性がぶれたり、不要に複雑になったりする場合は、根拠を示して反論します。

• Codex のレビュー呼び出しでは、必ず config: {"model_reasoning_effort": "xhigh"} を使用します。

• Phase 2 の threadId を保存し、後続ラウンドでは mcp__codex__codex-reply を使用します。

• 結果を捏造しないでください。 予想される根拠と、計画中の実験のみを記載します。

• 計算資源とデータの前提を具体的に示します。 「モデルを学習する」だけでは不十分です。

• すべてを記録します。 生のレビュー、アンカーチェック、簡潔性チェック、主要な手法の変更をすべて保存します。

他のスキルとの組み合わせ

このスキルは、アイデアの発見と実行の間をつなぎます。

/research-refine-pipeline              -> one-shot refine + experiment planning
/idea-creator "direction"       -> candidate ideas
/research-refine "PROBLEM: ... | APPROACH: ..."  <- you are here
/experiment-plan                -> detailed experiment roadmap
/run-experiment                 -> execute the chosen method
/auto-review-loop               -> iterate on results and paper

一般的な流れ：

1. /idea-creator またはローカルでの文献調査で、問題と大まかな手法の方向性を定めます
2. /research-refine で、問題に根差した洗練された、最新動向を踏まえた手法計画に仕上げます
3. /experiment-plan で、最終提案を、主張に基づく詳細な実験ロードマップに落とし込みます
4. ユーザーが両方の段階を1回のリクエストでまとめて行いたい場合は、/research-refine-pipeline をワンショットのラッパーとして使用します
5. /run-experiment で、選定した実験を実行します
6. 以降のサイクルでは、アイデアだけでなく、結果に基づいて進めます

問題はすでに把握しており、手法を具体化するだけでよい場合は、このスキルを単独でも使用できます。