flow-paper-lifecycle

論文ライフサイクルオーケストレーター

アイデアから公開可能な成果物まで、論文作成を導きます。役割は、プロジェクトが現在どの段階にあり、次の判断は何で、どの単体スキルに引き継ぐべきかを把握し、移行にゲートを設けることです。論文が弱い土台のまま進まないようにします（貢献が安定する前に執筆を始めない、主張を切り分ける前に規模を拡大しない）。このファイルが担うのは順序付けとゲートだけです。アイデア創出、実験、文章の執筆そのものは行いません。

特定の段階だけを対象とする場合は、オーケストレーターを使わず、該当するスキルを直接呼び出してください。ユーザーが全工程の管理を望む場合に使用します。

開始前：プロジェクトを特定する

推測できないことだけを尋ねます。必要な情報は以下のとおりです。

• 現在の段階 — アイデア、文献レビュー、実験実施中、結果あり、執筆中、査読中、採択済みなどです。これにより開始地点を決めます。ほとんどのプロジェクトはステージ1から始まりません。
• 意図する貢献 — 大まかな一文でも構いません。パイプライン全体は、1つの主張を擁護できるものにするためのものです。
• 投稿先／締め切り — スコープ、ベースラインの基準、各段階にどれだけ投資するかを左右します。

貢献をまったく言葉にできない場合は、ステージ1から始めます。言葉にはできているものの、まだ不確かな場合は、ステージ2から始めます。

パイプライン

順番に進め、プロジェクトの実際の段階から開始し、未達の最後のゲートから再開します。

1 Frame the idea → 2 Stress-test → 3 Ground in literature → 4 Design experiments
→ 5 Plan evidence (baselines/ablations) → 6 Implement & run → 7 Analyze results
→ 8 Plan figures/tables → 9 Plan the argument → 10 Write sections
→ 11 Audit citations → 12 Submission readiness → 13 Target a venue
→ 14 Rebuttal → 15 Release artifacts

ステージ1 — アイデアを形にする → paper-idea-and-scope-brainstormer

生のアイデアを、スコープを定めた貢献と論文の骨子案にまとめます。 ゲート： 一文で表した貢献と、大まかなスコープができていること。

ステージ2 — ストレステスト → research-idea-stress-test

投資する前に、隠れた前提、見せかけの新規性、最も低コストで決定的な実験を検討し、アイデアを手早く厳しく検証します。 ゲート： 低コストの反証検証をアイデアが乗り越えていること。メカニズム／主張／貢献がそれぞれ別個に明示されていること。（ここで中止または再構成すれば、数か月を節約できます。）

ステージ3 — 文献に照らして位置付ける → literature-triangulation

情報源に基づいた全体像を作ります。最も近い先行研究、手法の系統、ベンチマーク、実質的な意見の相違を整理します。すでに存在する貢献を主張する事態を防ぎます。 ゲート： 最も近いベースラインが特定されていること。実際に確認された先行研究に照らして、貢献が位置付けられていること。

ステージ4 — 実験を設計する → experiment-design

高コストな実行の前に、公平な対照条件と明示的な成功基準を備えた、判断に必要な最小限の実験を設計します。 ゲート： 測定可能な成功基準を備えた、反証可能な実験計画があること。

ステージ5 — エビデンスを計画する → benchmark-and-baseline-selector + hypothesis-and-ablation-planner

主張に必要な最小限のベースライン／ベンチマークと、推奨されるベースライン／ベンチマークを明確にし、論文を飾るのではなく因果メカニズムを切り分けるアブレーションを設計します。（プロジェクトの慣例として、すべての提案でベースライン／ベンチマークを検討します。） ゲート： 最小限のベースライン＋ベンチマークのセットについて合意されていること。アブレーションが具体的な代替説明に対応していること。

ステージ6 — 実装して実行する → research-codebase（必要に応じて pytorch-training-recipe / jax-training-recipe を追加）

仮説をすばやく検証できるようにコードベースを構成し、実行内容を実装します。実行に問題がある場合（発散、崩壊、不審な性能向上、データ経路のバグの疑い、次にどのパラメーターを調整すべきか分からないなど）は、experiment-design に戻ります。そこでは、モデルを原因と決めつける前に、診断の一環としてデータ経路を確認します。 ゲート： 実験を再現可能な形で実行し、計画で定めた指標が得られていること。

ステージ7 — 結果を分析する → model-eval-error-analysis → results-writeup

手法がどこで成功し、どこで失敗するか（データの区分、失敗の分類）を調べてから、実行結果を明確な結果の説明にまとめます。有意性について主張する場合は、statistical-testing-guide を使用します。 ゲート： 結果が主張を裏付ける（または反証する）こと。有意性と失敗モードが理解されており、平均値だけに依存していないこと。

ステージ8 — 図表を計画する → figure-table-planner

どの内容をプロットにし、どの内容を表にするかを決め、アブレーション表を設計し、キャプションだけで内容が理解できるようにします。 ゲート： すべての主張を裏付ける図表があること。視覚的なエビデンスと主張が対応付けられていること。

ステージ 9 — 議論を計画する → paper-argument-planner

論文の背骨、つまり問題から貢献へと続く一貫した筋道を、本文を書き始める前に固めます。 ゲート： 安定した背骨があり、貢献が確定していること。このゲートを通過するまで、節を書き始めないでください。

ステージ 10 — 各節を書く（執筆ステージ群）

このステージは委任せず、ここで担当します。4つのサブフェーズからなる、フェーズごとにゲートを設けた執筆コーチです。ユーザーが明示的に上書きしない限り、現在のゲートより先の内容は下書きしないでください。必要に応じて、範囲を絞った節の作業を外部に委任します。

対象とする投稿先の種類を一度だけ尋ねます。選択肢は、定理と証明を中心とする数学、ML カンファレンス、またはハイブリッド／応用です。それに応じて骨子を調整します。数学論文では、定義、定理の記述、証明の構成、既知の結果との関係を前面に出します。ML 論文では、貢献の箇条書き、手法、実験、アブレーション、ベースライン、再現性、限界を前面に出します。ハイブリッド論文では、主張から証拠への対応表に定理と実証の両方の主張を含め、どちらか一方に隠れないようにします。

参照ファイルは段階的に読み込みます。references/writing-structure.md（10a）、references/writing-drafting.md（10b）、references/writing-math-prose.md（10c）、references/writing-logistics.md（10d）を読み込み、引用／読みやすさ／タイトル／要旨について助言する場合は、references/writing-evidence.md も読み込みます。

エビデンスのフラグ。 執筆に関する推奨には、すべて次のいずれかのフラグを付けます。[EXPERT]（実証的に確立されていない執筆上の知見）、[SUPPORTED]（実証的な裏付けがある）、[CONTESTED]（エビデンスが相反する、または分野によって異なる）、[REFUTED]（通説がデータによって否定されている）。[EXPERT] のルールを実証済みの事実として示してはいけません。確信が持てない場合は、[EXPERT] とするか、エビデンスの水準が不明だと伝えてください。

10a — ストーリーと骨子。 何かを書く前に、貢献を一文で言い表すよう促します。「この論文は、<中核となるメカニズム／証拠> によって <新しいこと> を示す／提案する／証明する／導入する。」 ユーザーがこれを言い表せない場合は、そこで止め、その一文だけに取り組みます。主張から証拠への対応表を作成します（主張 → 裏付けとなる証拠／証明／結果 → 節）。洗練された文章ではなく、序論の骨子だけを書きます。[EXPERT] ゲート 10a： 貢献を一文で言い表せている。すべての貢献に、それを裏付ける節がある。序論だけを読んだ読者が、新規性を説明できる。

10b — 下書き。 まず技術的な中核を書き、次に結果、次に序論、最後に要旨を書きます。文章の生成と推敲を分け、下書き中に文章を磨いたり、事実確認に追われたりする代わりに、プレースホルダーを残します。N節を書いた後、ハルモスの螺旋を実行します。N節で明らかになったことを踏まえて、1節からN−1節を書き直します。abstract-and-intro-writer（要旨と序論は一組のままにする）、method-section-writer、related-work-writer（ステージ 3 の対応表を出典とし、記憶には頼らない）、および検証済みの数値に関する文章を担当する results-writeup に委任します。[EXPERT] ゲート 10b（節ごと）： 各節の冒頭段落で、その節の目的を述べている。明示的なプレースホルダーを除き、まだ書かれていない内容への先行依存がない。各節の主張が、主張から証拠への対応表に記載されている。

10c — 数学的な文章の確認。 記号表を作成します（記号、意味、型／定義域、初出時の定義、記号の衝突）。すべての記号を使う前に定義します。全称量化の場合、曖昧な「任意の」を「各」または「すべての」に置き換えます。すべての定理の記述を単独で読んでも理解できるようにします。仮定は直前の段落だけでなく、定理の記述そのものに含めます。自明でない証明にはすべて、一文で証明の要点を示します。「容易にわかる」「明らかに」「標準的な議論により」とする箇所はすべて、根拠を示すか、引用を付けるか、削除します。[EXPERT] ゲート 10c： 記号表が完成している。未定義の記号がない。各定理を単独で読み直せる。「明らか」「容易」「標準的」とする主張はすべて、根拠が示されているか、引用されているか、削除されている。 10d — ドラフトの引き継ぎ。 最終的な書式設定の前に投稿先との適合性を確認します（スコープ、対象読者、ページ数の上限、スタイルファイル、匿名性、補足資料のルール、締め切り）。共著者の承認を得ます。バージョンを固定し、未解決のリスクを列挙し、明示的な承認を求め、予告なしの著者変更は行いません。ジャーナルの場合は、論文の主張を繰り返すのではなく、投稿先との適合性と貢献を述べた簡潔なカバーレターを用意します。ML系の投稿先には、再現性チェックリスト（コード／データ、シード、ハードウェア、ハイパーパラメーター、データ分割、評価スクリプト、ライセンス、計算資源）を添付します。[EXPERT] ゲート 10d： すべてのセクションが論文の軸に沿った完全なドラフトがあり、投稿先との適合性、共著者の承認、再現性に関する成果物が記録されていること。

ゲートに失敗した場合は、簡潔な合否チェックリストを返し、失敗ごとに該当する文章を正確に引用します。成果物が欠けている場合は、代わりに不足している項目名を引用します。

ステージ 11 — 引用を監査 → citation-auditor

参考文献が実在すること、主張が出典と一致すること、捏造や誤帰属がないことを確認します。 ゲート： 参考文献一覧と本文中の引用が検証済みであること。

ステージ 12 — 投稿準備状況 → submission-readiness-audit（＋ professor-critic）

投稿先の要件に照らして、完全性、書式、主張と根拠の対応、再現性に関する記述を確認します。OpenReview時代のML／NLP／CV／AI系の投稿先では、査読者に見えるリスクを監査で明示的に対象とします。根拠のない主張、曖昧な新規性、名前を明示したベースラインの欠落、再現性の不足、限界や倫理面の問題、データの帰属、引用の信頼性などです。その後、チェックリストではできない敵対的なレビューを行います。ドラフトをprofessor-criticに渡し、対象読者を「競合手法に取り組む、投稿先のReviewer 2」、評価基準を「採択／大幅修正／却下」と指定します。まず判定を示して問題点を徹底的に洗い出し、実際の査読者に指摘される前に致命的な反論を明らかにします。（submission-readiness-auditは要件に照らして論文を確認し、professor-criticは敵対的な読者をシミュレートします。peer-review-writerではありません。これは他者の論文を査読するためのものです。） ゲート： 投稿前監査に合格し、未対処の致命的な問題がない状態で敵対的な査読を通過すること。

ステージ 13 — 投稿先を選ぶ → venue-targeting

論文に合う投稿先を選び、その投稿先の慣例に合わせて構成やスコープを調整します（早い段階で実施して、前のステージに活用することもできます）。 ゲート： 投稿先を選定し、その投稿先に合う形で論文を構成していること。

ステージ 14 — 査読への回答 → reviewer-response-strategist

査読後に、回答方針と追加実験の必要性を検討します。OpenReview形式のディスカッション期間中は、結論を左右する懸念に回答し、解決済みの点を認め、根拠が変わった場合は主張や実験を更新し、論点をすり替えないようにします。 ゲート： 各査読者の結論を左右する懸念に対応した回答計画があること。

ステージ 15 — 成果物を公開する → artifact-release-packager（＋ reproducibility-audit）

公開する内容を決めてパッケージ化し、結果が実際に再現できることを監査します。 ゲート： 論文の主張を裏付け、主要な結果を再現できる成果物のリリースがあること。

ルータールール

• 重複させず、委任します。 各ステージは単独の担当に引き継ぎます。このファイルが順序とゲートを管理します。ステージ 10 は唯一の例外です。ゲートがパイプラインのゲートと同じであるため、執筆フェーズはこのファイルが担当します。ただし、個別のセクション作業は引き続き外部に委任します。
• 最初からやり直さず、再開します。 プロジェクトの実際のステージから入り、未達のゲートのうち最後のものから取り組みます。
• ステージ 10 の前にハードゲートを設けます。 論旨の骨格（ステージ 9）が安定するまで、セクションの執筆は始めません。貢献内容が不安定なまま草稿を書くと、最も多くの時間を無駄にします。
• 自由に前の段階へ戻ります。 結果（7）が弱ければ、プロジェクトを設計（4）に戻したり、枠組みを再設定したり（2）できます。後戻りは通常のことであり、失敗ではありません。
• 投稿先を早い段階で検討することもできます。 締め切りが決まっている場合は、ステージ 13 を最初に実行し、投稿先の基準に合わせて範囲とベースラインを定めます。
• 他者の論文を査読する場合は別のルートです。 ユーザーが査読者として作業している場合は、peer-review-writer に引き継ぎます。
• ユーザーの目標に達したら停止します。 すべてのプロジェクトで、ステージ 13〜15 を一度に実行する必要はありません。