orchestrate-paper

論文のオーケストレーション

指揮者です。著者は技術的なアイデア、実験結果、そして目標（投稿先、または「投稿先選びを手伝って」）を提示します。このスキルは目標（「期限 D までに投稿先 X へ投稿できる状態にする」）を設定し、ライフサイクル全体を通して、目標 → 計画 → 実行 → 検証 → 振り返りのループを実行します。どのサブスキルをどの順番で実行するかを計画して呼び出し、各ステージゲートで著者に確認を求めます。さらに、外部から得られる測定可能なシグナルを使って、各段階で論文が実際に前進したことを確認してから先へ進みます。自己申告だけで判断することはありません。

このスキルは著者に代わって論文を書くことも、何かを投稿することもありません。専門スキルを連携させ（各スキルはそれぞれ独立しています）、著者がいつでも一時停止、確認、却下、再開できるよう、paper-workspace/ に永続的でレビュー可能な記録を残します。

このスキルは、すべてのチェックポイントで、いくつかの譲れない作業原則に従います。前提を明示し、異なる解釈を示し、トレードオフを明らかにし、混乱したら立ち止まり、最新の情報を検証し、著者自身が著者であり続けるようにします。

使用する場面

• 「自分のアイデアと結果から、投稿先に出せる論文まで仕上げて」／「パイプライン全体を実行して」／「アイデアから投稿までコパイロットになって」
• 「ここからの計画は？」／「何が終わっていて、次は何？ 何が障害になっている？」
• サイクル途中の調整：「査読結果が返ってきたところです。次はどうすればいい？」や「採択されました。カメラレディとアーティファクトの準備を進めて」
• 利用できるスキルが多数あり、それらを約 20 個手作業で実行する代わりに、順序立てて実行するための窓口をひとつにまとめたい場合

使用しない場面

• 範囲が明確な単発タスク（「この段落を推敲して」「引用を確認して」）。該当するスキルを直接呼び出してください。オーケストレーションのオーバーヘッドに見合いません。
• レビューなしで文章を代わりに書いてほしい場合。これはそのためのものではありません。あくまでコパイロットであり、論文を書くのは著者です。

入力

1. アイデアと実験 — 論文で主張する内容と、著者がすでに得ている証拠です。オーケストレーターは不足を埋めるために結果を捏造しません。必要な実験が欠けている場合は、捏造するのではなく障害として示します。
2. 目標 — 投稿先とトラック、または help me pick（この場合は最初に select-venue を実行します）。どちらの場合も、最新の CFP を再検証し、キャッシュされたプロフィールをそのまま信用することはありません。
3. 既存の草稿 — 白紙のアイデアから完成間近の .tex まで。計画は現在の状態に合わせて調整されます（以下の状態スクリプトを参照）。
4. .paper-memory/ — paper-memory-convention.md のパターンに従った、位置付け（profile.yml）、蓄積された lessons.md、decisions.md。開始時に読み込みます。

ループ

ステージ → スキル → 終了条件 → チェックポイントの質問の全表については、 references/pipeline-map.mdをお読みください。各ステージのループは次のとおりです。

1. 目標。 目標を1文で述べ、現在の対象 （会場＋トラック＋締め切り）を示します。対象が未設定の場合は、select-venueを実行して選択内容を.paper-memory/decisions.mdに記録し、固定事項として扱う前に著者の確認を得ます（原則 #1、#6）。

2. 計画。 パイプラインマップをもとに、ドラフトの現在の状態に合わせて、レビュー可能な事前計画を作成します。どのサブスキルをどの順序で実行するのか、そしてその理由を明示します。ここでは、場当たり的に一つずつ進めるより、計画を立ててから実行するほうが適しています。著者が承認できるロードマップを提示します。計画を示し、複数ステージにわたる計画を黙って実行し始めないでください。

3. 実行。 ステージのサブスキルを実行します。それぞれが成果物を適切なpaper-workspace/<stage>/フォルダーに書き込み、INDEX.mdに追記します。オーケストレーターが専門処理を再実装するのではなく、該当するサブスキルを呼び出します。

4. 検証 — 自己判断ではなく、外部シグナルに基づいて行います。 モデルの自己省察では自身の幻覚を検証してしまうため（references/verification-signals.mdを参照）、測定可能なチェックを使ってステージが終了条件を満たしたことを確認します。シグナルは具体的なものです。latexmk／コンパイルの終了コード、実際の会場のページ数制限との比較、匿名化リンター、verify-citationsによって実在するDOIに解決されるBibTeXエントリー、verify-claimsによって実際の結果までたどれる主張、verify-resultsによって成果物から再現できる報告数値、チェックリストの存在を確認するgrep、スクリプトの合否などです。ある手順に外部の判定基準がない場合（判断を要する場合）は、そのことを伝え、モデルに自己評価させず著者に判断を仰ぎます。

5. 振り返り — 測定可能な改善があったか。 ステージの目標と、測定可能な実行前／実行後の対象値に照らしてreflect-and-improveを実行します。シグナルが改善した場合（または、別のシグナルが改善する一方で維持された場合）に限り、ステージを受け入れます。測定可能なスコアを低下させる変更は決して受け入れないでください。ループが終わらなくならないよう、停止条件（以下）を守ります。

6. チェックポイント。 ステージのゲートで、完了した作業、トレードオフ、存在する場合は競合する解釈、そしてパイプラインマップにあるチェックポイントの質問を提示します。次のステージに進む前に、必ず著者の承認を待ってください。これが状態を保持する一時停止地点です。状態はディスクに保存されるため、著者はその場を離れ、後から再開できます。

いつでも状態スクリプトを実行して、進捗を確認できます。

python3 scripts/pipeline_state.py status --workspace paper-workspace

このスクリプトはpaper-workspace/INDEX.md（および任意のpipeline-state.json）を読み取り、完了済み／次の作業／ブロック要因に加えて、現在の目標と保留中のチェックポイントを表示します。その他のサブコマンドは、init、set-goal、next、advance、block、checkpoint、signoff（著者が提示されたチェックポイントを解除し、ループを進行可能にします）です。python3 scripts/pipeline_state.py --helpを実行してください。

作業例（1 ループを最初から最後まで）

著者：「自分のアイデアと結果を、NeurIPS 2026 に提出できる論文に仕上げてください。」

# GOAL — record the target and open the durable log
python3 scripts/pipeline_state.py init --workspace paper-workspace
python3 scripts/pipeline_state.py set-goal --workspace paper-workspace \
    --goal "submission-ready for NeurIPS 2026 main track" \
    --venue "NeurIPS 2026" --track main --deadline "2026-05-15 AoE"

まず要件を確定します（未達なら停止）。 計画を立てる前に、最新の CFP に対して parse-cfp を実行します。キャッシュされた venues/conferences/neurips-2026.yml は決して使いません。ページ数の上限が 9 ページで、ダブルブラインド査読だと返されたとします。それぞれの情報には、取得元 URL と取得日が付いています。チェックポイントを提示して、返答を待ちます。

python3 scripts/pipeline_state.py checkpoint --workspace paper-workspace \
    --stage parse-cfp \
    --question "9pp, double-blind, NeurIPS checklist required, AoE deadline — confirm before we build on these?"

著者が確認します。次に PLAN：パイプラインマップにあるステージ一覧を、ドラフトの状態（途中まで書かれた .tex があり、関連研究はまだない）に合わせて提示し、承認を得てから、EXECUTE で 1 つのステージ（たとえば preflight-check）を実行します。VERIFY は外部のシグナルに基づいて行い、モデルの自己申告には頼りません。check_sections.py が終了コード 0 で終了し、PDF が 9 ページで、最新の上限 9 ページに収まっていることを確認します。REFLECT：デスク却下の件数が 2 → 0 に減り、改善しているため、受け入れます。記録して、次のチェックポイントを提示します。

python3 scripts/pipeline_state.py advance --workspace paper-workspace \
    --stage preflight-check --signal "check_sections.py exit 0; 9pp <= 9 live limit; anonymizer clean"
python3 scripts/pipeline_state.py status --workspace paper-workspace   # done / next / blocked

後のステージで不足が明らかになった場合（たとえば simulate-reviewers が、著者にないアブレーションを R2 が求めると予測した場合）、それは捏造して埋めるものではなく、ブロッカーです。block --stage simulate-reviewers --on "missing ablation R2 will ask for" を実行し、その内容を提示して、著者の判断を仰ぎます。投稿はオーケストレーターが行うことではありません。準備が整ったパッケージを引き渡して停止します。

停止条件（ループが無限に続かないようにするため）

設定可能ですが、必ず設けます。ループは終了しなければなりません。

• ステージ終了条件を満たした — パイプラインマップに定められた測定可能な基準に合格した場合。
• 収穫逓減 — 振り返りによる指標の改善が小さな差分（例：prose-lint の差分が N 未満）にとどまる場合。推敲を止めます。
• 反復回数の上限 — 各ステージの改善パスは最大約 3 回とし、その後はエスカレーションします。
• 予算上限 — トークン数または時間の予算に達したら停止して報告します。
• 著者へのエスカレーション — 未検証の前提が次のステップの条件になっている場合、依頼に複数の解釈がある場合、またはモデルが本当に判断に迷っている場合（原則 #1、#2、#4）に行います。エスカレーションは失敗ではなく、正式な結果の 1 つです。

ライブ検証は必須です

投稿先のルールは投稿サイクルごとに変わり、モデルの記憶は必然的に古くなります。締め切り、ページ数の上限、査読の匿名性レベル、テンプレート、チェックリスト、成果物バッジのルールに依存するステージを実行する前に、parse-cfp を使って最新の CFP から情報を再取得し、キャッシュされた venues/conferences/*.yml のプロフィールよりも優先します。オーケストレーターがチェックポイントに含める投稿先に関する情報にはすべて、著者がリンク先を開いて確認できるよう、取得元 URL と取得日を残します。取得直後は過信が最も起きやすいため、その情報に基づいて行動する前に、一次情報源で再確認します。このスキルに投稿先のルールをハードコードしてはいけません。

出力

• paper-workspace/ 配下の進行中の計画とステージごとの成果物。それぞれを INDEX.md に記録し、永続的でレビュー可能な記録とします。
• pipeline_state.py による、現在の完了事項／次の作業／ブロッカーの表示。
• 各チェックポイントで、完了事項、トレードオフ、著者に判断を求める事項を簡潔に説明します。完成して投稿済みであるかのようなドラフトを提示してはいけません。

専門分野に合わせて調整する

パイプラインマップには、一般的な会議論文およびジャーナル論文の手順が含まれています。分野に合わせて派生させてください。ジャーナルの場合はステージの順序を変更し（反論の代わりに改訂・再投稿とするなど）、引用の慣例を入れ替え、分野に適用されるチェックリスト、倫理声明、データポリシー、成果物のトラックを調整します。ステージゲートは維持し、その中で何を実行するかを変更してください。

ガードレール

• コパイロットとして動作し、操縦はしません。 計画と調整を行いますが、結果や引用を捏造せず、受理されたと主張したり判断を予測したりせず、著者に代わってシステムに提出することは決してありません。
• 自己内省ではなく、外部シグナルで検証します。 完了シグナルは常に、コンパイル／lint／DOI 解決／チェックリスト／人間による承認です。モデルが自らの出力を評価することはありません（references/verification-signals.md を参照）。
• 各ステージゲートで必ず停止します。 ステージ間では著者の承認が必要です。CFP カードを確定情報として扱う、反論を送信する、カメラレディ版を作成するといった重要な移行時には、必ず停止します。
• 永続的なチェックポイントを設けます。 次へ進む前に、各ステージの成果物と INDEX.md を保存します。これにより、一時停止や再起動後に前段のスキルを再実行せずに済み、キー不要の検索スタックに対する API の重複呼び出しを防げます。
• 締切を二重に数えません。 成果物の評価／カメラレディの進行は、論文の締切に含めず、受理後の別個の締切として管理します。
• 1 ファイルは 500 行未満、references/ は 1 階層までとし、スクリプトは標準ライブラリのみを使用し、--help と適切なゼロ以外の終了コードを備えます。

メモリ

paper-memory-convention.md で説明されている共有 .paper-memory/ 規約を使用します。

• 開始時： profile.yml（位置付け）、lessons.md（各ステージで注意すべき繰り返しの習慣）、decisions.md（過去の投稿先／トラックの選択）を読み、計画を個別に調整し、これまでの決定との一貫性を保ちます。
• 各ステージの終了時： reflect-and-improve/scripts/reflect_log.py を使って、日付入りのエントリーを追記します — date · orchestrate-paper · stage advanced / blocked, on what signal — また、投稿先／トラックに関する決定があれば decisions.md に記録します。
• 必要に応じて .paper-memory/ を作成し、.gitignore への追加を提案します。ローカルでのみ使用し、アップロードはしません。