paper-plan

Paper Plan：査読の結論から論文のアウトラインへ

各査読者枠の前に、Selectable Reviewers に従ってください： 呼び出し方法を解決 → .aris/reviewer.json → Claude Code のデフォルト（Codex MCP） を、正規のヘルパーリゾルバー経由で reviewer_route.py を使って実行し、この 枠のティア、新しいコンテキスト、ソース／画像入力、決定論的なゲートを維持します。 以下の Codex の例／固定指定は backend=codex にのみ適用されます。他のルートでは、 それぞれ独自の初回呼び出し／応答の契約を使用します。ルートと実際に返された識別情報を保存してください。 利用できない選択肢は REVIEW_UNAVAILABLE です。実際の ファミリー／完了状況／スコープに基づいて採否を分類します。 呼び出し時の査読者／モデル／推論量の上書き指定は、査読者を含む子プロセスに引き継いでください。 生成ワーカーに変更はありません。

以下から、セクションごとの構造化された論文アウトラインを生成します：$ARGUMENTS

定数

• REVIEWER_MODEL = gpt-6-astra — アウトライン査読に Codex MCP 経由で使用するモデルです。backend=codex の場合は、OpenAI モデルを使用してください。
• TARGET_VENUE = ICLR — デフォルトの投稿先です。ユーザーは上書きできます（例：/paper-plan "topic" — venue: NeurIPS）。対応先：ICLR、NeurIPS、ICML、CVPR、ACL、AAAI、ACM、IEEE_JOURNAL（IEEE Transactions／Letters）、IEEE_CONF（IEEE カンファレンス）。
• MAX_PAGES — ページ上限です。ML カンファレンスの場合、参考文献と付録を除き、本文の結論までを対象とします。ICLR=9、NeurIPS=9、ICML=8、AAAI=技術内容が7ページで、参考文献は含みません。ただし、現在の AAAI CFP に別の指定がある場合はそれに従います。IEEE の投稿先では、ページ数に参考文献を含みます。 IEEE ジャーナルの Transactions は合計約12～14ページ、Letters は合計約4～5ページ、IEEE カンファレンスは合計約5～8ページです（いずれも参考文献を含む）。

入力

このスキルでは、プロジェクトディレクトリに次のいずれか1つ以上が必要です：

1. NARRATIVE_REPORT.md または STORY.md — 主張と根拠を含む研究の物語
2. review-stage/AUTO_REVIEW.md — 自動査読ループの結論（見つからない場合は ./AUTO_REVIEW.md を使用）
3. 実験結果 — figures/ 内の JSON ファイル、画面ログ、表
4. idea-stage/IDEA_REPORT.md — アイデア発見パイプラインからのレポート（該当する場合。見つからない場合は ./IDEA_REPORT.md を使用）
5. コンパクトファイル（利用可能な場合）：idea-stage/IDEA_CANDIDATES.md（見つからない場合は ./IDEA_CANDIDATES.md を使用）、findings.md、EXPERIMENT_LOG.md — 存在する場合は完全版ファイルよりも優先して使用します。コンテキストウィンドウを節約できます。

該当するファイルがない場合は、論文の貢献を3～5文で説明するようユーザーに依頼してください。

Orchestra による執筆オーバーレイ

既存の insleep ワークフローと出力は維持しつつ、以下の共有リファレンスを活用して、ストーリーとアウトラインの質を高めてください。

• 一文での貢献の説明、Abstract、Introduction、Related Work、またはヒーロー図を構成する際は、../shared-references/writing-principles.md を読んでください。
• 特定の投稿先向けにアウトラインを確定する前に、../shared-references/venue-checklists.md を読んでください。
• 必要な場合にのみこれらのリファレンスを読み込み、内容全体を作業中のドラフトに貼り付けないでください。

オプション：スタイル参照（— style-ref: <source>、オプトイン）

アウトラインの構造的なレイアウト（セクションの順序、サブセクションの密度、定理環境の密度、図の予算、引用スタイル）を、参考論文に沿うようユーザーが調整できます。デフォルトではオフです。ユーザーが — style-ref を指定しない場合は、従来と何も変えないでください。

— style-ref: <source> が $ARGUMENTS に含まれる場合に限り、アウトラインを作成する前に、まずヘルパーを実行します。

# Resolve $STYLE_HELPER via the canonical strict-safe chain (see
# shared-references/integration-contract.md §2). Policy A — gate:
# unresolved helper means --style-ref cannot be satisfied, so abort.
cd "$(git rev-parse --show-toplevel 2>/dev/null || pwd)" || exit 1
if [ -z "${ARIS_REPO:-}" ] && [ -f .aris/installed-skills.txt ]; then
    ARIS_REPO=$(awk -F'\t' '$1=="repo_root"{print $2; exit}' .aris/installed-skills.txt 2>/dev/null) || true
fi
if [ -z "${ARIS_REPO:-}" ] && [ -f "$HOME/.aris/repo" ]; then
    ARIS_REPO=$(cat "$HOME/.aris/repo" 2>/dev/null) || true
fi
STYLE_HELPER=".aris/tools/extract_paper_style.py"
[ -f "$STYLE_HELPER" ] || STYLE_HELPER="tools/extract_paper_style.py"
[ -f "$STYLE_HELPER" ] || { [ -n "${ARIS_REPO:-}" ] && STYLE_HELPER="$ARIS_REPO/tools/extract_paper_style.py"; }
[ -f "$STYLE_HELPER" ] || {
  echo "ERROR: extract_paper_style.py not resolved at .aris/tools/, tools/, \$ARIS_REPO/tools/, or via ~/.aris/repo." >&2
  echo "       Fix: rerun bash tools/install_aris.sh or smart_update.sh (refreshes ~/.aris/repo), export ARIS_REPO, or copy the helper to tools/." >&2
  echo "       --style-ref cannot be satisfied; aborting." >&2
  exit 1
}
STYLE_STATUS=0
CACHE=$(python3 "$STYLE_HELPER" --source "<source>") || STYLE_STATUS=$?
case "$STYLE_STATUS" in
  0) ;;                                       # use $CACHE/style_profile.md as structural guidance
  2) echo "warning: style-ref skipped (missing optional dep)" >&2 ;;
  3) echo "error: --style-ref source failed; aborting outline" >&2 ; exit 1 ;;
  *) echo "error: helper failed unexpectedly; aborting outline" >&2 ; exit 1 ;;
esac

利用可能なソース：ローカルの TeX ディレクトリ／ファイル、ローカル PDF、arXiv ID（2501.12345 または arxiv:2501.12345）、http(s) URL。Overleaf の URL とプロジェクト ID は受け付けません。先に /overleaf-sync setup <id> でクローンし、ローカルのクローンパスを指定してください。

厳守事項（契約の全文は tools/extract_paper_style.py の docstring を参照）：

• アウトラインのセクション一覧、サブセクション数、定理の密度、図の予算を提案する際に限り、style_profile.md を構造的な指針として使用してください。
• キャッシュを通じてアクセス可能なものから、文章、主張、例、セクション名、用語をそのままコピーすることは絶対に避けてください。内容の根拠となるのは、ユーザーのナラティブのみです。
• — style-ref（またはキャッシュの内容）をレビュー担当／監査担当のサブエージェントに渡すことは絶対に避けてください。クロスモデルレビューの独立性（../shared-references/reviewer-independence.md）を保つため、レビュー担当者には成果物とユーザーのプロンプトのみを見せる必要があります。

ギャップレポート（GAP_REPORT.md、style-ref が有効な場合に自動生成）

— style-ref: が正常に処理され、プロジェクト内に figures/、results/、data/、tables/、sec/、NARRATIVE_REPORT.md、CLAIMS_FROM_RESULTS.md のいずれかが存在する場合は、アウトライン作成前にギャップレポートも生成します。このレポートでは、参考論文のセクション構成と密度要件（style_profile.md に記載）をユーザーの実際のアセットと照らし合わせ、ユーザーが根拠を示せない構造上の項目を明らかにします。これが、内容の捏造を避けて `` マーカーを出力するタイミングを /paper-write が判断するための契約です。

手順：

1. $CACHE/style_profile.md を読み、参考論文のセクション一覧とセクションごとの特徴の数（図、定理、表、引用、文数）を確認します。
2. ユーザーのアセットを一覧化します：figures/* のファイル名、results/* の根拠ファイル、既存の文章がある sec/*.tex、NARRATIVE_REPORT.md、CLAIMS_FROM_RESULTS.md（/result-to-claim を実行した場合）、引用密度を確認するための references.bib。
3. 参考論文から推測される各セクション項目（アブレーション表、スケーリング実験、失敗事例の分析、証明ブロックなど）を、covered／partial／missing に分類します。
4. <output-dir>/GAP_REPORT.md を生成します。

# GAP_REPORT — exemplar vs user assets

- **Exemplar source:** <source identifier (file path, arXiv ID, URL)>
- **Generated:** <UTC ISO-8601>
- **Style profile:** <relative path to style_profile.md>

## Section topology gaps

| Exemplar slot | Exemplar feature | User evidence | Status | Slot ID |
|---|---|---|---|---|
| §5 Experiments | ablation table (3 axes × 4 levels) | `results/` has no ablation file | missing | `GAP_S5_ABLATION` |
| §5.3 Scaling | log-N scaling curve | `figures/scaling.pdf` not found | missing | `GAP_S5_SCALING` |
| §6 Discussion | failure-case analysis | not present in `NARRATIVE_REPORT.md` | missing | `GAP_S6_FAILURE` |
| §2 Related | citation density ≥ 60 | `references.bib` has 35 entries | partial | `GAP_S2_CITES` |

## Coverage summary

- covered: N
- partial: M
- missing: K

## Used by

- `/paper-write` reads this file and emits `` placeholders for `missing` slots instead of fabricating content.
- `/paper-claim-audit` can use Slot IDs to flag claims that cite sections with `missing` evidence.

スロット ID の形式：GAP_<SECTION>_<FEATURE>。すべて大文字とし、ユーザーのアセットが変わらない限り再生成しても同じ ID を使用します。

ルール（厳守）：

• ギャップを「埋める」ために、根拠を推測、補完、捏造しないでください。不足しているものは不足しています。
• ギャップを埋めるための具体的な実験コマンドを提案しないでください。それは /experiment-bridge の役割です。ギャップレポートでは不足項目を明らかにするだけです。
• 参考論文の文章、主張の文言、著者名、定量的な数値を含めないでください。
• style_profile.md の抽出に失敗した場合、またはユーザーにプロジェクトアセットがない場合は、ギャップレポートをスキップします（エラーにせず、ファイルを生成しないでください）。
• ギャップレポートにもレビュー担当者の分離ルールが適用されます。レビュー担当／監査担当のサブエージェントに渡すことは絶対に避けてください（style_profile.md と同じルールです）。

元のアイデア：@zhangpelf、#217。

ワークフロー

Step 1: 主張とエビデンスを抽出する

まず CLAIMS_FROM_RESULTS.md を確認してください。先頭行が verdict: REVIEW_UNAVAILABLE の場合、主張の抽出ではこのファイルを存在しないものとして扱い（以下のナラティブ文書に進み）、そのうえで — assurance: submission（shared-references/assurance-contract.md に記載。— effort: max|beast により暗黙的に指定）の場合は停止してください。主張はまだ判定されていないため、まず /result-to-claim を再実行してください。assurance: draft の場合は続行しますが、主張マトリクス内のすべての主張に [unadjudicated] を付けてください。それ以外の場合、このファイルが存在すれば（Workflow 2 の最後に /result-to-claim が生成）、主張の出発点として使用してください。このファイルには、実験エビデンスにすでに対応付けられた検証済みの主張が含まれています。以下のナラティブ文書から追加の主張があれば、統合してください。

CLAIMS_FROM_RESULTS.md が存在しない場合は、最初から主張を抽出してください。

利用可能なナラティブ文書をすべて読み、以下を抽出してください。

1. 中核となる主張（主な貢献を3～5件）
2. 一文で表した貢献（論文の貢献を最もよく表す一文）
3. 各主張のエビデンス（関連する実験、指標、図）
4. 既知の弱点（査読者のフィードバックから）
5. 推奨される位置づけ（査読結果から）

主張とエビデンスのマトリクスを作成してください。

| Claim | Evidence | Status | Section |
|-------|----------|--------|---------|
| [claim 1] | [exp A, metric B] | Supported | §3.2 |
| [claim 2] | [exp C] | Partially supported | §4.1 |

Step 2: 論文の種類と構成を決める

TARGET_VENUE と論文の内容に基づいて、種類を分類し、構成を選択してください。

構成を決定する前に、../shared-references/writing-principles.md のナラティブの原則を適用してください。

• 論文では、一貫性のある技術的なストーリーを伝えてください。
• Introduction の終わりまでに、概要から What、Why、So What が明確にわかるようにしてください。
• 最も重要な内容を前半に配置してください。タイトル、アブストラクト、Introduction、そして主役となる図が該当します。査読者は、手法の全体を読む前に評価を固めることがよくあります。

重要：セクション数は柔軟に決めてください（5～8セクション）。内容に最も適した構成を選んでください。以下のテンプレートは出発点であり、厳格な制約ではありません。

実証・診断論文：

1. Introduction (1.5 pages)
2. Related Work (1 page)
3. Method / Setup (1.5 pages)
4. Experiments (3 pages)
5. Analysis / Discussion (1 page)
6. Conclusion (0.5 pages)

理論と実験の論文：

1. Introduction (1.5 pages)
2. Related Work (1 page)
3. Preliminaries & Modeling (1.5 pages)
4. Experiments (1.5 pages)
5. Theory Part A (1.5 pages)
6. Theory Part B (1.5 pages)
7. Conclusion (0.5 pages)
— Total: 9 pages

理論論文では、7セクションが必要になることがよくあります（理論を推定と最適化に分ける場合、または設定と分析に分ける場合など）。総ページ数は必ず MAX_PAGES と一致させてください。

理論論文では、以下を行ってください。

• 定理を述べるだけでなく、証明の概略を記載する場所を含める
• 既存の理論的境界と本論文の境界を比較する表を計画する
• 付録と本文のどちらに証明を掲載するか特定する

手法論文：

1. Introduction (1.5 pages)
2. Related Work (1 page)
3. Method (2 pages)
4. Experiments (2.5 pages)
5. Ablation / Analysis (1 page)
6. Conclusion (0.5 pages)

Step 3: セクションごとの計画

各セクションについて、以下を指定してください。

### §0 Abstract
- **What we achieve**: [the paper's specific contribution, not field-level background]
- **Why it matters / is hard**: [why this problem is important and non-trivial]
- **How we do it**: [approach in one sentence]
- **Evidence**: [what supports the claim]
- **Most remarkable result**: [strongest quantitative or theoretical result]
- **Estimated length**: 150-250 words
- **Self-contained check**: can a reader understand this without the paper?

### §1 Introduction
- **Opening hook**: [1-2 sentences that motivate the problem]
- **Gap / challenge**: [what's missing in prior work, and why prior work is insufficient]
- **One-sentence contribution**: [the main takeaway of the paper]
- **Approach overview**: [what we do differently]
- **Key questions**: [the research questions this paper answers]
- **Contributions**: [2-4 numbered bullets, specific and falsifiable, matching Claims-Evidence Matrix]
- **Results preview**: [the strongest result or comparison to surface early]
- **Hero figure**: [describe what Figure 1 should show — MUST include clear comparison if applicable]
- **Estimated length**: 1.5 pages
- **Key citations**: [3-5 papers to cite here]
- **Front-loading check**: [would a skim reader know the main claim before reaching the method?]

### §2 Related Work
- **Subtopics**: [2-4 categories of related work]
- **Positioning**: [how this paper differs from each category]
- **Minimum length**: 1 full page (at least 3-4 paragraphs with substantive synthesis)
- **Organization rule**: organize by methodological family / assumption / question, not paper-by-paper
- **Must NOT be just a list** — synthesize, compare, and position

### §3 Method / Setup / Preliminaries
- **Notation**: [key symbols and their meanings]
- **Problem formulation**: [formal setup]
- **Method description**: [algorithm, model, or experimental design]
- **Formal statements**: [theorems, propositions if applicable]
- **Proof sketch locations**: [which key steps appear here vs. appendix]
- **Estimated length**: 1.5-2 pages

### §4 Experiments / Main Results
- **Figures planned**:
  - Fig 1: [description, type: bar/line/table/architecture, WHAT COMPARISON it shows]
  - Fig 2: [description]
  - Table 1: [what it shows, which methods/baselines compared]
- **Data source**: [which JSON files / experiment results]

### §5 Conclusion
- **Restatement**: [contributions rephrased, not copy-pasted from intro]
- **Limitations**: [honest assessment — reviewers value this]
- **Future work**: [1-2 concrete directions]
- **Estimated length**: 0.5 pages

Step 4: 図の計画

すべての図と表を列挙してください。

## Figure Plan

| ID | Type | Description | Data Source | Priority |
|----|------|-------------|-------------|----------|
| Fig 1 | Hero/Architecture | System overview + comparison | manual | HIGH |
| Fig 2 | Line plot | Training curves comparison | figures/exp_A.json | HIGH |
| Fig 3 | Bar chart | Ablation results | figures/ablation.json | MEDIUM |
| Table 1 | Comparison table | Main results vs. baselines | figures/main_results.json | HIGH |
| Table 2 | Theory comparison | Prior bounds vs. ours | manual | HIGH (theory papers) |

図1／主役となる図で特に重要な点：図に含める内容を詳しく説明してください。以下を含めます。

• 比較する手法
• 視覚的な違いで示すべきこと
• 比較内容を明確に示すキャプションの草案
• 手法の全体を読む前に、ざっと目を通す読者が論文を理解するうえで図がどう役立つか

Step 5: 引用の骨組み

各セクションで必要となる引用を列挙してください。

## Citation Plan
- §1 Intro: [paper1], [paper2], [paper3] (problem motivation)
- §2 Related: [paper4]-[paper10] (categorized by subtopic)
- §3 Method: [paper11] (baseline), [paper12] (technique we build on)

引用のルール（claude-scholar および Imbad0202/academic-research-skills に基づく）：

1. BibTeX を記憶から生成してはいけません。必ず検索結果または既存の .bib ファイルで確認してください。
2. 引用はすべて検証してください。著者、年、掲載先が正しいことを確認してください。
3. 確信のない引用には [VERIFY] を付けてください。
4. arXiv のプレプリントがある場合は、公開済みのバージョンを優先してください。

Step 6: REVIEWER_MODEL との相互レビュー

完全なアウトラインを GPT-6-Astra xhigh に送ってフィードバックを受けてください。

まずこの査読スロットを解決してください。以下は backend=codex の例です。

mcp__codex__codex:
  model: gpt-6-astra
  config: {"model_reasoning_effort": "xhigh"}
  prompt: |
    Review this paper outline for a [VENUE] submission.
    [full outline including Claims-Evidence Matrix]

    Score 1-10 on:
    1. Logical flow — does the story build naturally?
    2. Claim-evidence alignment — every claim backed?
    3. Missing experiments or analysis
    4. Positioning relative to prior work
    5. Page budget feasibility (MAX_PAGES = main body to Conclusion end, excluding refs/appendix)
    6. Front-matter strength — are the abstract, introduction, and hero figure plan strong enough for skim-reading reviewers?

    For each weakness, suggest the MINIMUM fix.
    Be specific and actionable — "add X" not "consider more experiments".

最終決定の前に、フィードバックを反映してください。

Step 7: 出力

最終版のアウトラインを、プロジェクトのルートにある PAPER_PLAN.md に保存してください。

# Paper Plan

**Title**: [working title]
**One-sentence contribution**: [single-sentence statement of the paper's core takeaway]
**Venue**: [target venue]
**Type**: [empirical/theory/method]
**Date**: [today]
**Page budget**: [MAX_PAGES] pages (main body to Conclusion end, excluding references & appendix)
**Section count**: [N] (must match the number of section files that will be created)

## Claims-Evidence Matrix
[from Step 1]

## Structure
[from Step 2-3, section by section]

## Figure Plan
[from Step 4, with detailed hero figure description]

## Citation Plan
[from Step 5]

## Reviewer Feedback
[from Step 6, summarized]

## Next Steps
- [ ] /paper-figure to generate all figures
- [ ] /paper-write to draft LaTeX
- [ ] /paper-compile to build PDF

主なルール

• 大容量ファイルの処理：ファイルサイズが原因でWriteツールが失敗した場合は、直ちにBash（cat << 'EOF' > file）を使ってチャンク単位で書き込みを再試行してください。ユーザーに許可を求めず、何も言わずに実行してください。
• 著者情報を生成しないでください — 著者欄はプレースホルダーまたは匿名のままにしてください
• 根拠が不足している場合は正直に示してください — 主張を過大に述べず、「実験が必要」と記してください
• ページ数の上限は厳守してください — 内容がMAX_PAGESを超える場合は、付録に移す項目を提案してください
• MAX_PAGESの数え方は投稿先によって異なります — ML系の学会では、本文は結論までを対象とし、参考文献と付録は対象外です。AAAIのメイントラックは通常、技術的内容が7ページで、参考文献は別枠です。IEEE系の投稿先では、参考文献もページ数の上限に含まれます。
• 投稿先ごとの慣例 — ML系の学会（ICLR／NeurIPS／ICML）ではnatbib（\citep／\citet）を使います。IEEE系の投稿先ではciteパッケージ（数値形式の\cite{}）を使います。
• 主張と根拠の対応表が中核です — すべての主張を根拠に対応させ、すべての実験が主張を裏付けるようにしてください
• ストーリーの要点を早い段階で示してください — 読者が手法全体を読む前に、タイトル、要旨、序論、主要図で貢献が明確に伝わる構成にしてください
• 図には詳細な説明が必要です — 特に主要図では、比較対象と期待される見た目を明確に指定してください
• セクション数は柔軟に設定してください — 論文の種類に応じて5～8セクションとします。内容を無理に固定の5セクション構成に当てはめないでください。

謝辞

アウトラインの方法論は、Research-Paper-Writing-Skills（主張と根拠の対応付け）、claude-scholar（引用の検証）、Imbad0202/academic-research-skills（主張の検証プロトコル）に着想を得ています。このハイブリッドパックの執筆構成ガイダンスは、Orchestra Researchの論文執筆ガイダンスを基にしています。

出力プロトコル

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

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