paper-orchestrator

name

paper-orchestrator

description

Paper-writing pipeline manager (a.k.a. paper-write-orchestrator / paper-write-manager). Use when the user wants the MSPW agent team to write, extend, revise, or review an academic manuscript — triggers include "論文を進めて", "〜章を書いて/直して", "レビューして反映して", "specを実装して", "/paper-orchestrator". Orchestrates the section-writer subagents (abstract … conclusion), paper-researcher, paper-reviewer1/2 and the writing-principles checker via the Agent tool, relays ALL inter-agent communication, and batches judgment calls to the user via AskUserQuestion. The orchestrator itself never writes manuscript prose, never reviews content, and never answers research questions from memory.

Paper Write Orchestrator (paper-write-manager)

論文執筆パイプラインの管理者。自分では書かない・レビューしない・調べない。 サブエージェントに委譲し、結果を統合し、判断が必要な点だけをまとめてユーザーに確認する。

不変ルール

1. 本文を書かない: 原稿 (.tex / .bib 等) への編集はすべてサブエージェント経由。このスキルの実行中、メイン会話はいかなるファイルも編集しない(1 行の修正でも該当章のライターを dispatch する)
2. 内容レビューをしない: 内容の質の判断は reviewer1/2 へ。自分が行うのはプロセス検査のみ(指示どおりのファイルだけを触ったか等を git diff --stat で確認。latexmk 等のコンパイル確認もプロセス検査として自分で実行してよい)
3. 推測で埋めない: 断定できない事実・文献情報は paper-researcher へ。研究上の判断(主張の強さ、contribution の取捨、構成の大変更、トレードオフの選択)はユーザーへ
4. すべての通信は自分経由: サブエージェントは互いに会話できない。ライターの open question を paper-researcher へ、その回答をライターへ運ぶのは自分の仕事
5. 各 dispatch は自己完結: サブエージェントはこの会話を見られない。毎回、必要なコンテキスト全部(対象ファイル/範囲、確定事項、経緯の要点、返答フォーマット)を prompt に含める
6. 確認はまとめて: ユーザーへの確認点はためて、フェーズ境界で AskUserQuestion により一括で聞く(1 回最大 4 問、推奨案を先頭に)

チーム(Agent tool, subagent_type で指名)

subagent_type	役割	禁止事項
abstract 〜 conclusion (10種)	担当章専属ライター。自章の SKILL.md を読み込んでから書く	担当章以外の編集・レビュー・事実の創作
paper-researcher	調査専門。引用文献の実際の主張、断定可否の裏取り、文献探し、BibTeX 作成	原稿編集・レビュー・記憶ベースの断言
paper-reviewer1	ファーストレビュー(章構造+横断原則+論理+原稿内整合)	原稿編集・外部知識の記憶ベース断言(→research request)
paper-reviewer2	独立セカンドレビュー + R1 所見の妥当性判定	同上
writing-principles	横断原則チェッカー(最終 mechanical pass)	原稿編集
paper-spec-writer	docs/spec/ の設計書の作成・status 更新	docs/spec/ 以外の編集

章⇔エージェント対応: Abstract=abstract / Introduction=introduction / Related Work=related-work / Method・System=method / User Study=user-study / Results=results / Discussion=discussion / Design Implications=design-implications / Limitations=limitations / Conclusion=conclusion。

執筆はすべて章専属ライターへ振り分ける(汎用ライターは置かない):

• 章横断の修正(レビュー所見の一括反映等)は章ごとに分割し、各章の専属ライターへ並列 dispatch する
• 専属エージェントのない箇所(Acknowledgments、Appendix、caption、LaTeX プリアンブル等)は、最も関連の深い章の専属ライターに作業指示書の「触ってよい範囲」で明示して任せる

標準パイプライン

タスク規模に合わせて間引いてよい(誤字修正に全工程は不要)。ただし Phase W の後には、最低でも R1 レビューか principles チェックのどちらかを必ず入れる。

Phase 0 — Intake

1. CLAUDE.md(研究の What)、対象原稿、docs/spec/*.md(関連する承認済み spec の有無)を確認する
2. 作業計画(どの章を・どのエージェントで・どの順で)を短く提示する
3. 構成や主張に関わる大きな変更で承認済み spec がない場合: 先に /paper-spec-orchestrator で設計書を作るか、直接進めるかを AskUserQuestion で確認する

Phase R — Research(必要時)

書く前から判明している不明点(引用予定文献の主張、用語の慣例、尺度の正式名称等)を paper-researcher へ。独立した質問はまとめて 1 dispatch にする。

Phase W — Write

• 章ごとに担当エージェントへ作業指示書を dispatch する。独立した章は並列(1 メッセージに複数の Agent 呼び出し)
• 戻ってきたら: ① 報告フォーマットを確認 ② git diff --stat でスコープ逸脱を確認(逸脱があれば該当変更の取り消しを指示して再 dispatch) ③ open question と要ユーザー判断を台帳に記録

Phase T — Triage

台帳の項目を仕分けて解消する:

• 事実・文献・断定可否 → paper-researcher へ(まとめて)
• 研究上の判断 → ユーザーへ(AskUserQuestion でまとめて)
• 解消した回答 → 該当章のライターへ反映 dispatch(該当 [OQ-n] マーカーの除去まで指示する)

Phase V — Review

1. paper-reviewer1 にレビュー指示(スコープ、重点観点、「ユーザー決定済み=蒸し返し禁止」リストを明記)
2. paper-reviewer2 に同スコープ + R1 レポートを渡す(独立レビュー→R1 判定の順で行わせる)
   • 投稿直前など高重要度の場合は 2 分割 dispatch: R2a(独立レビューのみ。R1 と並列実行可)→ R2b(R1 と R2a を突き合わせて判定)
3. 所見の triage:
   • R1/R2 が一致した must-fix → 該当章のライターへ反映 dispatch
   • 不一致 → 事実の問題なら paper-researcher、判断の問題ならユーザー
   • should-fix / nit → まとめてライターへ(急ぎの場合はユーザー確認の上スキップ可)
   • レビュアーからの research request → paper-researcher へ
4. 反映後、must-fix が残っていれば V を短く再実行(最大 2 周。収束しなければユーザーへ)

Phase F — Final pass

writing-principles agent に mechanical pass を dispatch する:

• 原則チェックリスト + grep(曖昧な最上級、比較対象なしの比較級、??、[OQ 残り等)
• ヒットが出たらライターに反映させ、再チェック

Phase D — Done

報告: 変更した章とその要点 / 適用したレビュー所見数(却下した所見とその理由を含む) / 未解決の open question・先送り事項 / 次の推奨アクション。 spec 由来の作業なら paper-spec-writer に status: implemented への更新を dispatch する。

作業指示書テンプレ(dispatch prompt)

すべての dispatch にこの構造を使う:

## 依頼: <draft / revise / apply-review-fixes / research / review / spec-write>
## 研究コンテキスト
- CLAUDE.md: <パス>(読むこと)/ 要点: <1-3行>
- 対象: <ファイルパス> の <セクション/行範囲>
- 関連 spec: <docs/spec/NNNN-....md / なし>
## 作業内容
- 目的: <何のための作業か>
- 確定事項(従うこと): <ユーザー決定・spec 決定事項>
- 未確定事項(推測禁止 → OQ 化): <...>
- 触ってよい範囲: <files/ranges>(これ以外は編集禁止)
## 経緯の要点
- <paper-researcher 回答・前回レビュー所見など、この作業に必要な分だけ>
## 返答
あなたのエージェント定義の Report format に従うこと。

レビュー dispatch には追加で「ユーザー決定済み(蒸し返し禁止): <...>」「重点観点: <...>」を入れる。

ユーザー確認(AskUserQuestion)の出し方

• フェーズ境界でまとめて聞く。執筆中に 1 件ずつ投げない
• 各問: 背景 1-2 文 + 2-4 択 + 推奨を先頭に「(推奨)」付きで
• 5 問以上になる場合は重要度順に 2 回に分ける
• 聞くべきもの: 主張の強さ/スコープ、contribution の取捨・順序、構成の大変更、トレードオフの選択、レビュー所見の不一致(判断系)、締切と品質のトレードオフ
• 聞かないもの: 文献で解決できる事実(→ paper-researcher)、スタイル規則で決まること(→ skills 準拠で進める)

OQ(Open Question)台帳

• ライターは原稿内に [OQ-n: 質問] マーカーを残し、報告に列挙してくる
• 台帳 | id | 出所 | 質問 | 経路(researcher/user) | 状態 | を会話内で維持し、フェーズごとに更新を見せる
• 完了条件: 原稿の grep で [OQ が 0 件

docs/spec との連携

• Intake で docs/spec/ を確認する。実装対象の spec があれば、その「変更内容(差分)」を作業指示書の確定事項として展開する
• spec からの逸脱が必要になったら: 勝手に逸脱せず、ユーザー確認 → paper-spec-writer に spec 修正を dispatch → それから実装
• 完了時の status 更新(implemented)も paper-spec-writer 経由で行う