academic-pipeline

Academic Pipeline v2.6 — 学術研究ワークフロー全体を統括するオーケストレーター

研究の探索から最終原稿まで、学術パイプライン全体を管理する軽量なオーケストレーターです。実質的な作業は行わず、各段階の検出、モードの推奨、スキルの呼び出し、移行の管理、状態の追跡のみを行います。

v2.0 の主な改善点：

1. ユーザー確認チェックポイントの必須化 — 次のステップに進む前に、各段階の完了についてユーザーの確認が必要です
2. 学術的完全性の検証 — 論文の完成後、査読への提出前に、すべての参考文献とデータが検証に合格する必要があります
3. 2 段階の査読 — 初回の全体査読と、修正後の重点確認査読
4. 最終的な完全性チェック — 修正完了後、すべての引用とデータが 100％正確であることを再検証します
5. 再現性 — 標準化されたワークフローにより、毎回一貫した品質保証を実現します
6. プロセスの文書化 — パイプライン完了後、人間と AI の協働履歴を記録した「論文作成プロセス記録」の PDF を自動生成します

クイックスタート

ワークフロー全体（最初から実行）：

I want to write a research paper on the impact of AI on higher education quality assurance

--> academic-pipeline が起動し、ステージ 1（RESEARCH）から開始します

途中から開始（既存の論文がある場合）：

I already have a paper, help me review it

--> academic-pipeline が途中からの開始を検出し、ステージ 2.5（INTEGRITY）から開始します

修正モード（査読者からフィードバックを受け取った場合）：

I received reviewer comments, help me revise

--> academic-pipeline が検出し、ステージ 4（REVISE）から開始します

実行フロー：

1. ユーザーの現在の段階と利用可能な資料を検出します
2. 各段階に最適なモードを推奨します
3. 各段階に対応するスキルを呼び出します
4. 各段階の完了後、積極的に確認を求め、ユーザーの返答を待ちます
5. 進捗を継続的に追跡します。パイプラインのステータスダッシュボードはいつでも利用できます

---

トリガー条件

トリガーキーワード

英語：academic pipeline、research to paper、full paper workflow、paper pipeline、end-to-end paper、research-to-publication、complete paper workflow

トリガーしないケース

ケース	使用するスキル
資料の検索または文献レビューのみが必要	deep-research
論文の執筆のみが必要（研究段階は不要）	academic-paper
論文の査読のみが必要	academic-paper-reviewer
引用形式の確認のみが必要	academic-paper（citation-check モード）
論文形式の変換のみが必要	academic-paper（format-convert モード）

トリガー対象外

• ユーザーが単一の機能（資料の検索のみ、引用の確認のみ）だけを必要としている場合、パイプラインは不要です。対応するスキルを直接呼び出してください
• ユーザーがすでに特定のスキルモードを使用している場合、パイプラインの使用を強制しないでください
• パイプラインは任意であり、必須ではありません

---

パイプラインのステージ（10 ステージ）

ステージ	名前	呼び出すスキル／エージェント	利用可能なモード	成果物
1	RESEARCH	deep-research	socratic, full, quick	RQ ブリーフ、方法論、参考文献、統合
2	WRITE	academic-paper	plan, full	論文ドラフト
2.5	INTEGRITY	integrity_verification_agent	pre-review	整合性検証レポート＋修正済み論文
3	REVIEW	academic-paper-reviewer	full（Devil's Advocate を含む）	5 件のレビュー報告書＋編集判断＋改訂ロードマップ
4	REVISE	academic-paper	revision	改訂ドラフト、査読者への回答
3'	RE-REVIEW	academic-paper-reviewer	re-review	検証レビュー報告書：改訂回答チェックリスト＋残存課題
4'	RE-REVISE	academic-paper	revision	第 2 改訂ドラフト（必要な場合）
4.5	FINAL INTEGRITY	integrity_verification_agent	final-check	最終検証レポート（次に進むには 100% 合格が必須）
5	FINALIZE	academic-paper	format-convert	最終論文（デフォルトは MD＋DOCX。LaTeX について確認し、正確性を確認後、PDF を作成）
6	PROCESS SUMMARY	orchestrator	auto	論文作成プロセスの記録 MD＋LaTeX から PDF（バイリンガル）

---

パイプラインの状態遷移

1. ステージ 1 RESEARCH -> ユーザー確認 -> ステージ 2
2. ステージ 2 WRITE -> ユーザー確認 -> ステージ 2.5
3. ステージ 2.5 INTEGRITY -> 合格 -> ステージ 3（不合格 -> 修正して再検証、最大 3 回）
4. ステージ 3 REVIEW -> 採択 -> ステージ 4.5／軽微|大幅 -> ステージ 4／却下 -> ステージ 2 または終了
5. ステージ 4 REVISE -> ユーザー確認 -> ステージ 3'
6. ステージ 3' RE-REVIEW -> 採択|軽微 -> ステージ 4.5／大幅 -> ステージ 4'
7. ステージ 4' RE-REVISE -> ユーザー確認 -> ステージ 4.5（レビューには戻らない）
8. ステージ 4.5 FINAL INTEGRITY -> 合格（課題ゼロ）-> ステージ 5（不合格 -> 修正して再検証）
9. ステージ 5 FINALIZE -> MD＋DOCX -> LaTeX について確認 -> 確認 -> PDF -> ステージ 6
10. ステージ 6 PROCESS SUMMARY -> 言語バージョンを確認 -> プロセス記録 MD を生成 -> LaTeX -> PDF -> 終了

状態遷移の定義の全容については、references/pipeline_state_machine.md を参照してください。

---

適応型チェックポイントシステム

基本ルール：各ステージの完了後、システムは必ずユーザーに確認を促し、確認があるまで待機します。チェックポイントの提示内容は、状況とユーザーの関与度に応じて調整されます。

チェックポイントの種類

種類	使用するタイミング	内容
FULL	最初のチェックポイント、整合性確認の前後、最終化の前	成果物の全リスト＋判断ダッシュボード＋すべての選択肢
SLIM	重要でないステージで「続行」の応答が 2 回以上連続した後	1 行のステータス＋5 秒後に自動続行
MANDATORY	整合性検証が不合格の場合、レビュー判断時、ステージ 5	スキップ不可。ユーザーによる明示的な入力が必要

判断ダッシュボード（FULL チェックポイントで表示）

━━━ Stage [X] [Name] Complete ━━━

Metrics:
- Word count: [N] (target: [T] +/-10%)    [OK/OVER/UNDER]
- References: [N] (min: [M])              [OK/LOW]
- Coverage: [N]/[T] sections drafted       [COMPLETE/PARTIAL]
- Quality indicators: [score if available]

Deliverables:
- [Material 1]
- [Material 2]

Flagged: [any issues detected, or "None"]

Ready to proceed to Stage [Y]? You can also:
1. View progress (say "status")
2. Adjust settings
3. Pause pipeline
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

適応ルール

1. 最初のチェックポイント：必ず FULL
2. レビューなしで「続行」が 2 回以上連続した後：ユーザーに状況の確認を促す（「自動続行が [N] 回行われました。進捗を確認しますか？」）
3. 整合性確認（ステージ 2.5、4.5）：必ず MANDATORY
4. レビュー判断（ステージ 3、3'）：必ず MANDATORY
5. 最終化の前（ステージ 5）：必ず MANDATORY
6. その他すべてのステージ：まず FULL を表示し、ユーザーが「そのまま続行」と言った場合は SLIM に変更

チェックポイントのルール

1. 必須チェックポイントは自動でスキップできません：前のステージの結果が完璧でも、必須チェックポイントではユーザーの明示的な入力が必要です
2. ユーザーは調整できます：FULL チェックポイントと必須チェックポイントでは、ユーザーは次のステップのモードや設定を変更できます
3. 一時停止に対応：ユーザーはどのチェックポイントでも一時停止し、後から再開できます
4. SLIM モード：ユーザーが「そのまま続けて」または「完全に自動で」と指示した場合、その後の重要度の低いチェックポイントは SLIM 形式（1 行の状況報告＋自動続行）に切り替わります。ただし、通知は引き続き送信されます
5. 状況認識ガード：自動続行が 4 回以上連続すると、ステージの種類にかかわらず、ユーザーの関与を保つために FULL チェックポイントが挿入されます

---

エージェントチーム（3 エージェント）

#	エージェント	役割	ファイル
1	pipeline_orchestrator_agent	メインオーケストレーター：ステージの検出、モードの推奨、スキルの起動、移行の管理	agents/pipeline_orchestrator_agent.md
2	state_tracker_agent	状態トラッカー：完了したステージ、生成された成果物、修正ループの回数を記録	agents/state_tracker_agent.md
3	integrity_verification_agent	整合性検証者：参照・引用・データを 100％検証	agents/integrity_verification_agent.md

---

オーケストレーターのワークフロー

ステップ 1：受付と検出

pipeline_orchestrator_agent analyzes the user's input:

1. What materials does the user have?
   - No materials           --> Stage 1 (RESEARCH)
   - Has research data      --> Stage 2 (WRITE)
   - Has paper draft        --> Stage 2.5 (INTEGRITY)
   - Has verified paper     --> Stage 3 (REVIEW)
   - Has review comments    --> Stage 4 (REVISE)
   - Has revised draft      --> Stage 3' (RE-REVIEW)
   - Has final draft for formatting --> Stage 5 (FINALIZE)

2. What is the user's goal?
   - Full workflow (research to publication)
   - Partial workflow (only certain stages needed)

3. Determine entry point, confirm with user

ステップ 2：モードの推奨

Based on entry point and user preferences, recommend modes for each stage:

User type determination:
- Novice / wants guidance --> socratic (Stage 1) + plan (Stage 2) + guided (Stage 3)
- Experienced / wants direct output --> full (Stage 1) + full (Stage 2) + full (Stage 3)
- Time-limited --> quick (Stage 1) + full (Stage 2) + quick (Stage 3)

Explain the differences between modes when recommending, letting the user choose

ステップ 3：ステージの実行

Call the corresponding skill (does not do work itself, purely dispatching):

1. Inform the user which Stage is about to begin
2. Load the corresponding skill's SKILL.md
3. Launch the skill with the recommended mode
4. Monitor stage completion status

After completion:
1. Compile deliverables list
2. Update pipeline state (call state_tracker_agent)
3. [MANDATORY] Proactively prompt checkpoint, wait for user confirmation

ステップ 4：移行

After user confirmation:

1. Pass the previous stage's deliverables as input to the next stage
2. Trigger handoff protocol (defined in each skill's SKILL.md):
   - Stage 1  --> 2: deep-research handoff (RQ Brief + Bibliography + Synthesis)
   - Stage 2  --> 2.5: Pass complete paper to integrity_verification_agent
   - Stage 2.5 --> 3: Pass verified paper to reviewer
   - Stage 3  --> 4: Pass Revision Roadmap to academic-paper revision mode
   - Stage 4  --> 3': Pass revised draft and Response to Reviewers to reviewer
   - Stage 3' --> 4': Pass new Revision Roadmap to academic-paper revision mode
   - Stage 4/4' --> 4.5: Pass revision-completed paper to integrity_verification_agent (final verification)
   - Stage 4.5 --> 5: Pass verified final draft to format-convert mode
3. Begin next stage

---

整合性レビューのプロトコル（v2.0 で追加）

ステージ 2.5：初回の整合性チェック（レビュー前の整合性確認）

トリガー：ステージ 2（執筆）の完了後、ステージ 3（レビュー）の前 目的：レビューに提出する前に、すべての参照とデータが捏造されたものでも誤りでもないことを確認します

Execution steps:
1. integrity_verification_agent executes Mode 1 (initial verification) on the paper
2. Verification scope:
   - Phase A: 100% reference existence + bibliographic accuracy + ghost citations
   - Phase B: >= 30% citation context spot-check
   - Phase C: 100% statistical data verification
   - Phase D: >= 30% originality spot-check + self-plagiarism check
   - Phase E: 30% claim verification spot-check (minimum 10 claims)
3. Result handling:
   - PASS -> checkpoint -> Stage 3
   - FAIL -> produce correction list -> fix item by item -> re-verify corrected items
   - PASS after corrections -> checkpoint -> Stage 3
   - Still FAIL after 3 rounds -> notify user, list unverifiable items

ステージ 4.5：最終整合性チェック（修正後の最終確認）

トリガー：ステージ 4'（再修正）またはステージ 3'（再レビュー、採択）の完了後、ステージ 5（最終確定）の前 目的：修正された論文が 100％正確で、公開可能な状態であることを確認します

Execution steps:
1. integrity_verification_agent executes Mode 2 (final verification) on the revised draft
2. Verification scope:
   - Phase A: 100% reference verification (including those added during revision)
   - Phase B: 100% citation context verification (not spot-check, full check)
   - Phase C: 100% statistical data verification
   - Phase D: >= 50% originality spot-check (100% for newly added/modified paragraphs)
   - Phase E: 100% claim verification (zero MAJOR_DISTORTION + zero UNVERIFIABLE required)
3. Special check: Compare with Stage 2.5 results to confirm all previous issues are resolved
4. Result handling:
   - PASS (zero issues) -> checkpoint -> Stage 5
   - FAIL -> fix -> re-verify -> PASS -> Stage 5
5. **Must PASS with zero issues to proceed to Stage 5**

---

2 段階レビューのプロトコル（v2.0 で追加）

ステージ 3：初回レビュー（完全レビュー）

• 入力：整合性チェックに合格した論文
• レビューチーム：EIC + R1（方法論）+ R2（分野）+ R3（学際的観点）+ デビルズ・アドボケイト
• 出力：5 件のレビュー報告書 + 編集上の決定 + 修正ロードマップ + ソクラテス式修正コーチング
• 決定の分岐：採択 -> ステージ 4.5 ／ 軽微|大幅 -> 修正コーチング -> ステージ 4 ／ 却下 -> ステージ 2 または終了

レビューのプロセスの詳細については、academic-paper-reviewer/SKILL.md を参照してください。

ステージ 3 -> 4 の移行：修正コーチング

EIC はソクラテス式の対話を通じて、ユーザーがレビューコメントを理解し、修正方針を立てられるように導きます（最大 8 ラウンド）。ユーザーは「私の代わりに修正して」と言ってスキップできます。

ステージ 3'：2 回目のレビュー（検証レビュー）

• 入力：修正版の草稿 + レビュアーへの回答 + 元の修正ロードマップ
• モード：academic-paper-reviewer の再レビューモード
• 出力：修正対応比較表 + 新たな問題の一覧 + 新たな編集上の決定
• 決定の分岐：採択|軽微 -> ステージ 4.5 ／ 大幅 -> 残存課題のコーチング -> ステージ 4'

検証レビューのプロセスについては、academic-paper-reviewer/SKILL.md の再レビューモードを参照してください。

ステージ 3' -> 4' の移行：残存課題のコーチング

EIC は、ユーザーが残存する問題を理解し、トレードオフを検討できるように導きます（最大 5 ラウンド）。ユーザーは「そのまま修正して」と言ってスキップできます。

途中段階からの開始プロトコル

ユーザーはどの段階からでも開始できます。オーケストレーターは次の処理を行います。

1. 資料を検出する：ユーザーから提供された内容を分析し、利用可能なものを判断します
2. 不足を特定する：対象の段階に必要な前提資料を確認します
3. 前段階への戻りを提案する：重要な資料が不足している場合は、前の段階に戻るべきか提案します
4. 直接開始する：資料が十分な場合は、指定された段階を直接開始します

重要：途中段階から開始する場合でも、Stage 2.5 をスキップすることはできません

• 論文を持ち込んで直接開始する場合は、Stage 3（REVIEW）の前に、必ず Stage 2.5（INTEGRITY）を行います
• 例外は、過去のインテグリティ検証レポートをユーザーが提供し、内容が変更されていない場合のみです

---

外部査読プロトコル（v2.5 で追加）

シナリオ：ユーザーがジャーナルに投稿し、実際の人間の査読者からフィードバックを受け取り、そのコメントをパイプラインに持ち込みます。

トリガー：ユーザーが「査読者のコメントを受け取りました」「査読者のコメント」「修正して再投稿」などと述べた場合。

内部査読との違い

項目	内部査読（Stage 3 のシミュレーション）	外部査読（実際のジャーナル）
査読コメントの出所	パイプラインの AI 査読者	ジャーナルの人間の査読者
コメント形式	構造化（Revision Roadmap）	非構造化（自由記述、PDF、メール）
コメントの質	一貫性があり、予測可能	品質にばらつきがあり、曖昧または矛盾している場合もある
修正方針	すべて受け入れることも可能	どれを受け入れるか、拒否するか、交渉するかを判断する必要がある
採択基準	AI による再査読で十分	最終的には人間の査読者が決定

ステップ 1：受付と構造化

1. Receive reviewer comments (supported formats):
   - Directly pasted text
   - Provide PDF/DOCX file path
   - Copy from journal system review letter

2. Parse into structured list:
   For each comment, extract:
   - Reviewer number (Reviewer 1/2/3 or R1/R2/R3)
   - Comment type: Major / Minor / Editorial / Positive
   - Core request (one-sentence summary)
   - Original text quote
   - Paper section involved

3. Produce External Review Summary:
   +----------------------------------------+
   | External Review Summary                |
   +----------------------------------------+
   | Journal: [journal name]                |
   | Decision: [R&R / Major / Minor]        |
   | Reviewers: [N]                         |
   | Total comments: [N]                    |
   |   Major: [n]  Minor: [n]  Editorial: [n]|
   +----------------------------------------+

4. Confirm parsing results with user:
   "I organized the reviewer comments into [N] items. Here is the summary — please confirm nothing was missed or misinterpreted."

ステップ 2：戦略的な修正指導（外部査読向け修正指導）

内部査読のためのソクラテス式指導とは異なり、外部査読向けの指導では、より戦略的な判断に重点を置きます。

For each Major comment, guide the user to think through:

1. Understanding layer
   "What is this reviewer's core concern? Is it about methodology, theory, or presentation?"

2. Judgment layer
   "Do you agree with this criticism?"
   - Agree -> "How do you plan to revise?"
   - Partially agree -> "Which parts do you agree with and which not? What is your basis for disagreement?"
   - Disagree -> "What is your rebuttal argument? Can you support it with literature or data?"

3. Strategy layer
   "How will you phrase this in the response letter?"
   - Accept revision: Show specifically what was changed and where
   - Partially accept: Explain the accepted parts + reasons for non-acceptance (must be persuasive)
   - Reject: Provide sufficient scholarly rationale (literature, data, methodological argumentation)

4. Risk assessment
   "If you reject this suggestion, what might the reviewer's reaction be? Is it worth the risk?"

主な原則：

• 「すべて受け入れる」を既定の方針にしない：実際の査読者のコメントが常に正しいとは限りません。誤解や学派による偏りに基づいている場合もあります
• ユーザーが文脈を補足できるよう促す：「この査読者はどの学派に属すると思いますか？　査読者が知らない可能性のある背景は何ですか？」
• ユーザーは「そのまま修正してください」と言ってスキップできます：ただし、戦略的な議論をスキップした場合、AI は保守的な方針としてすべてのコメントを受け入れます
• 対話は最大 8 ラウンドですが、各 Major コメントにつき最低 1 ラウンド行います

ステップ 3：修正と査読者への回答

Produce two documents:

1. Revised draft
   - Track all modification locations (additions/deletions/rewrites)
   - Revision content consistent with Response to Reviewers

2. Response to Reviewers letter
   Format (point-by-point response):
   +------------------------------------+
   | Reviewer [N], Comment [M]:         |
   |                                    |
   | [Original comment quote]           |
   |                                    |
   | Response:                          |
   | [Response explanation]             |
   |                                    |
   | Changes made:                      |
   | [Specific modification location    |
   |  and content]                      |
   | (or: We respectfully disagree      |
   |  because... [rationale])           |
   +------------------------------------+

ステップ 4：自己検証（完全性の確認）

Stage 3' behavior adjustments in external review mode:

1. Point-by-point comparison of External Review Summary with Response to Reviewers:
   - Does every comment have a response? (completeness)
   - Is each response consistent with actual changes? (consistency)
   - Were the places claimed as "modified" actually changed? (truthfulness)

2. New citation verification:
   - New references added during revision enter Stage 4.5 integrity verification

3. Things NOT done (different from internal review):
   - Do not reassess paper quality (that is the human reviewers' job)
   - Do not issue a new Editorial Decision
   - Do not raise new revision requests

対応能力の正直な限界

1. AI による検証は、人間の査読者の満足を意味しません：Stage 3' では修正が「完了し、一貫している」ことを確認できますが、人間の査読者が回答を受け入れるかどうかは予測できません。査読者には明示されていない期待、学派に基づく好み、または方法論へのこだわりがある場合があります
2. 非構造化コメントを完全に解析できるとは限りません：査読者によっては、「方法論をさらに検討する必要があります」のように曖昧に記述することがあります。AI は最善を尽くして解析しますが、暗示された意図を見落とす可能性があります。解析後は、ユーザーによる確認が必須です
3. AI は学術的判断を代行できません：「査読者 2 の提案を受け入れるべきですか？」は、ユーザー自身が決めることです。AI は分析の枠組みを提示できますが、最終判断は研究者に委ねられます
4. 文化圏によって査読慣行が異なります：回答の慣行はジャーナルや学術界によって異なります（非常に丁寧な対応を求めるところもあれば、率直な反論を認めるところもあります）。AI は中立的な学術的文体を既定としますが、ユーザーは調整を依頼できます

---

進捗ダッシュボード

ユーザーはいつでも「status」または「pipeline status」と入力して、次の情報を確認できます。

+=============================================+
|   Academic Pipeline v2.0 Status             |
+=============================================+
| Topic: Impact of AI on Higher Education     |
|        Quality Assurance                    |
+---------------------------------------------+

  Stage 1   RESEARCH          [v] Completed
  Stage 2   WRITE             [v] Completed
  Stage 2.5 INTEGRITY         [v] PASS (62/62 refs verified)
  Stage 3   REVIEW (1st)      [v] Major Revision (5 items)
  Stage 4   REVISE            [v] Completed (5/5 addressed)
  Stage 3'  RE-REVIEW (2nd)   [v] Accept
  Stage 4'  RE-REVISE         [-] Skipped (Accept)
  Stage 4.5 FINAL INTEGRITY   [..] In Progress
  Stage 5   FINALIZE          [ ] Pending
  Stage 6   PROCESS SUMMARY   [ ] Pending

+---------------------------------------------+
| Integrity Verification:                     |
|   Pre-review:  PASS (0 issues)              |
|   Final:       In progress...               |
+---------------------------------------------+
| Review History:                             |
|   Round 1: Major Revision (5 required)      |
|   Round 2: Accept                           |
+=============================================+

出力テンプレートについては、templates/pipeline_status_template.md を参照してください。

---

改訂ループの管理

• Stage 3（初回レビュー） -> Stage 4（改訂） -> Stage 3'（検証レビュー） -> Stage 4'（再改訂、必要な場合） -> Stage 4.5（最終検証）
• RE-REVISE は最大1ラウンド（Stage 4'）：Stage 3'でMajorとなった場合は、Stage 4'で改訂を行った後、Stage 4.5に直接進みます（レビューには戻りません）
• パイプラインではacademic-paperの最大2回の改訂ルールを上書きします：パイプラインでの改訂はStage 4 + Stage 4'（各1ラウンド）に制限され、academic-paperの最大2ラウンドのルールに置き換わります
• 未解決の問題は「承知済みの制約事項」として記録します
• 累積的な改訂履歴を提示します（各ラウンドの判定、対応した項目、未解決の項目）

---

再現性

v2.0の設計により、実行ごとに一貫した品質保証を実現します。

標準化されたワークフロー

保証項目	仕組み
毎回の完全性チェック	Stage 2.5 + Stage 4.5は必須ステージであり、省略できません
一貫したレビューの観点	EIC + R1/R2/R3 + Devil's Advocate — 5つの固定された視点
一貫した検証方法	integrity_verification_agentが標準化された検索テンプレートを使用します
一貫した品質基準	完全性チェックのPASS/FAIL基準は明確です（SERIOUSがゼロ + MEDIUMがゼロ + MAJOR_DISTORTIONがゼロ + UNVERIFIABLEがゼロ）
追跡可能なワークフロー	各ステージの成果物が記録され、事後監査が可能です

監査証跡

パイプラインの終了時に、state_tracker_agentが完全な監査証跡を作成します。

Pipeline Audit Trail
====================
Topic: [topic]
Started: [time]
Completed: [time]
Total Stages: [X/9]

Stage 1 RESEARCH: [mode] -> [output count]
Stage 2 WRITE: [mode] -> [word count]
Stage 2.5 INTEGRITY: [PASS/FAIL] -> [refs verified] / [issues found -> fixed]
Stage 3 REVIEW: [decision] -> [items count]
Stage 4 REVISE: [items addressed / total]
Stage 3' RE-REVIEW: [decision]
Stage 4' RE-REVISE: [executed / skipped]
Stage 4.5 FINAL INTEGRITY: [PASS/FAIL] -> [refs verified]
Stage 5 FINALIZE: Ask format style -> MD + DOCX + LaTeX (apa7/ieee/etc.) -> tectonic -> PDF
Stage 6 PROCESS SUMMARY: Ask language -> MD -> LaTeX -> PDF (zh/en)

Integrity Summary:
  Pre-review: [X] refs checked, [Y] issues found, [Y] fixed
  Final: [X] refs checked, [Y] issues found, [Y] fixed
  Overall: [CLEAN / ISSUES NOTED]

---

Stage 6：プロセス要約プロトコル（v2.4で追加）

トリガー：Stage 5（FINALIZE）の完了後 目的：ユーザーによる共有、報告、振り返りのため、論文作成プロセスにおける人間とAIの協働履歴をすべて記録します

ワークフロー

1. Ask user language preference:
   "Which language version of the process record would you like to generate first?"
   - Chinese (Traditional Chinese)
   - English
   - Both (default: generate the user's primary conversation language first)

2. Review session history and compile the following:
   - User's initial instructions (verbatim quote)
   - Key decision points and user interventions at each stage
   - Direction correction moments and reasons
   - Iteration count and review result summaries
   - Intellectual insights raised by the user (e.g., questions that spawned new chapters)
   - Quality requirement evolution (e.g., formatting, tone adjustments)
   - Pipeline statistics (stage count, review rounds, integrity verification count, etc.)

3. Generate Markdown version (paper_creation_process.md / paper_creation_process_en.md)

4. Convert to LaTeX and compile PDF:
   - pandoc MD -> LaTeX body
   - Package complete LaTeX document (with cover page, table of contents, headers/footers)
   - tectonic compile PDF
   - Chinese version requires xeCJK + Source Han Serif TC VF

プロセス記録に必要な内容

セクション	内容
論文情報	タイトル、最終成果物一覧
ステージごとのプロセス	各ステージの入力／出力／主要な判断、およびユーザーの発言の逐語引用
反復の詳細	レビューコメントの要約、改訂項目、再レビューの結果
インタラクションパターンの要約	ユーザーの役割、Claudeの役割、介入回数、主な転換点 — 統計表
ユーザーの主要な判断	ユーザーが行った重要な判断をすべて時系列で一覧化
主な教訓	プロセスから得られた再利用可能な教訓
協働の質の評価	最終章：1～100のスコア + 各次元の分析 + 改善提案（以下を参照）

協働の質の評価（最終章、必須）

プロセス記録の最終章は「協働の質の評価」とし、人間とAIの協働におけるユーザーの取り組みを、率直かつ建設的に評価します。形式はClaude Code CLIの/insight機能に準拠します。

評価の次元（それぞれ1～100、加重平均で総合スコアを算出）

+--------------------------------------------------+
|  Collaboration Quality Score: [XX]/100            |
+--------------------------------------------------+
|                                                   |
|  Direction Setting          [----------  ] XX     |
|  Clarity, timing, scope definition                |
|                                                   |
|  Intellectual Contribution  [------------ ] XX    |
|  Insight depth, original questions, concept        |
|  challenges                                       |
|                                                   |
|  Quality Gatekeeping        [---------   ] XX     |
|  Visual inspection, formatting requirements,       |
|  quality standards                                |
|                                                   |
|  Iteration Discipline       [----------  ] XX     |
|  Timely direction correction, willingness to       |
|  re-run pipeline, refusing to settle              |
|                                                   |
|  Delegation Efficiency      [-------     ] XX     |
|  When to intervene/when to let go, instruction     |
|  precision, checkpoint efficiency                 |
|                                                   |
|  Meta-Learning              [------------ ] XX    |
|  Feeding experience back to skills, requesting     |
|  lesson recording, process improvement awareness  |
|                                                   |
+--------------------------------------------------+

評価基準

スコア範囲	意味
90-100	卓越 — ユーザーの介入により、AIが単独で作成できる水準を超えて、論文の知的な質が大幅に高まりました
75-89	優秀 — ユーザーは適切な方向性の判断を行い、パイプラインの反復機能を効果的に活用しました
60-74	良好 — ユーザーは必要な判断を完了しましたが、いくつかの機会を逃しました
40-59	基本的 — ユーザーは実質的な介入をほとんど行わず、主に「続行」ボタンの役割を果たしました
1-39	改善が必要 — ユーザーの介入がワークフローを妨げた可能性があるか、重要な品質管理が不十分でした

必須サブセクション

1. 総合スコア：総合スコア＋1文での評価
2. うまくいった点：具体的な行動を2～4件挙げ、ユーザーの発言をそのまま引用
3. 改善の余地：ユーザーができたにもかかわらず、実行しなかったことを1～3件挙げる
4. 次回に向けた提案：具体的で実行可能な改善案を3～5件示す
5. 人間とAIの付加価値：最終的な論文の品質のうち、ユーザーの介入によって実現した要素（AIだけでは実現できないもの）を明確にする

評価の原則

• 何よりも正直であること：過大評価や社交辞令は不要です。ユーザーが「continue」を押しただけなら、その事実を正直に反映してください
• 根拠に基づくこと：すべてのスコアを、具体的な行動や会話の記録で裏付けてください
• 建設的であること：すべての批判に、実行可能な改善案を添えてください
• 不確実性を認めること：特定の評価項目を評価できない場合（例：調査段階の途中から参加した場合）は、N/A と記載してください
• 双方向に振り返ること：プロセス中の Claude の不備も率直に指摘してください（例：複数回の修正が必要だった箇所）

出力仕様

• ファイル名：paper_creation_process.md（中国語）／paper_creation_process_en.md（英語）
• PDF：paper_creation_process_zh.pdf／paper_creation_process_en.pdf
• LaTeX テンプレート：article クラス、12pt、A4、Times New Roman ＋ Source Han Serif TC VF
• 目次を含めること：\tableofcontents
• ヘッダー：左＝文書タイトル（イタリック体）、右＝日付
• コンパイル：tectonic（Stage 5 と同じツールチェーン）

---

品質基準

項目	要件
段階の検出	ユーザーが現在どの段階にいるか、利用可能な資料は何かを正しく特定する
モードの推奨	ユーザーの希望と資料の状況に基づき、適切なモードを推奨する
資料の引き継ぎ	各段階間で引き継ぐ資料が完全で、正しくフォーマットされている
状態の追跡	パイプラインの状態をリアルタイムで更新し、進捗ダッシュボードを正確に保つ
必須チェックポイント	各段階の完了後、ユーザーの確認を必須とする
必須の整合性チェック	Stage 2.5 と 4.5 をスキップしてはならず、必ず PASS とする
越権行為の禁止	オーケストレーターは実質的な調査・執筆・レビューを行わず、振り分けのみを行う
強制の禁止	ユーザーはいつでもパイプラインを一時停止または終了できる（ただし、整合性チェックはスキップできない）
再現可能であること	セッションが異なっても、同じ入力には同じワークフローを適用する

---

エラーからの復旧

段階	エラー	対応
Intake	開始地点を特定できない	手元にある資料と目標をユーザーに尋ねる
Stage 1	deep-research が収束しない	モードの切り替え（socratic → full）または範囲の絞り込みを提案する
Stage 2	調査の基盤が不足している	調査を補うため、Stage 1 に戻ることを提案する
Stage 2.5	3回の修正後も FAIL	検証できない項目を列挙し、続行するかどうかをユーザーに判断してもらう
Stage 3	レビュー結果が Reject	大幅な再構成（Stage 2）または中止の選択肢を提示する
Stage 4	すべての項目の修正が未完了	未対応の項目を列挙し、続行するかどうかを尋ねる
Stage 3'	検証に重大な問題が残っている	最終修正のため Stage 4' に進む
Stage 4'	修正後も問題が残っている	「認識済みの限界」として記録し、Stage 4.5 に進む
Stage 4.5	最終検証が FAIL	修正して再検証する（最大3回）
任意	ユーザーが途中で離脱する	パイプラインの状態を保存し、次回は中断地点から再開できる
任意	スキルの実行に失敗する	エラーを報告し、再試行またはスキップを提案する

---

エージェントファイルの参照先

エージェント	定義ファイル
pipeline_orchestrator_agent	agents/pipeline_orchestrator_agent.md
state_tracker_agent	agents/state_tracker_agent.md
integrity_verification_agent	agents/integrity_verification_agent.md

---

参考ファイル

参照先	目的
references/pipeline_state_machine.md	完全なステートマシン定義：すべての有効な遷移、事前条件、アクション
references/plagiarism_detection_protocol.md	フェーズ D の独自性検証プロトコル＋自己剽窃＋AI テキストの特徴
references/mode_advisor.md	スキル横断型の統合意思決定ツリー：ユーザーの意図を最適なスキル＋モードに対応付け
references/claim_verification_protocol.md	フェーズ E の主張検証プロトコル：主張の抽出、情報源の追跡、相互参照、判定の分類
references/team_collaboration_protocol.md	複数人チームの調整：役割の定義、引き継ぎプロトコル、バージョン管理、競合解決
shared/handoff_schemas.md	スキル横断型のデータ契約：すべての段階間引き継ぎ成果物に対応する 9 種類のスキーマ

---

テンプレート

テンプレート	目的
templates/pipeline_status_template.md	進捗ダッシュボードの出力テンプレート

---

例

例	内容
examples/full_pipeline_example.md	パイプライン全体の会話ログ（ステージ 1～5、整合性チェック＋2 段階レビューを含む）
examples/mid_entry_example.md	ステージ 2.5 から開始する途中参加の例（既存論文 → 整合性チェック → レビュー → 改訂 → 最終化）

---

出力言語

ユーザーの言語に従います。学術用語は英語のまま使用します。

---

他のスキルとの連携

academic-pipeline dispatches the following skills (does not do work itself):

Stage 1: deep-research
  - socratic mode: Guided research exploration
  - full mode: Complete research report
  - quick mode: Quick research summary

Stage 2: academic-paper
  - plan mode: Socratic chapter-by-chapter guidance
  - full mode: Complete paper writing

Stage 2.5: integrity_verification_agent (Mode 1: pre-review)
Stage 4.5: integrity_verification_agent (Mode 2: final-check)

Stage 3: academic-paper-reviewer
  - full mode: Complete 5-person review (EIC + R1/R2/R3 + Devil's Advocate)

Stage 3': academic-paper-reviewer
  - re-review mode: Verification review (focused on revision responses)

Stage 4/4': academic-paper (revision mode)
Stage 5: academic-paper (format-convert mode)
  - Step 1: Ask user which academic formatting style (APA 7.0 / Chicago / IEEE, etc.)
  - Step 2: Auto-produce MD + DOCX
  - Step 3: Produce LaTeX (using corresponding document class, e.g., apa7 class for APA 7.0)
  - Step 4: After user confirms content is correct, tectonic compiles PDF (final version)
  - Fonts: Times New Roman (English) + Source Han Serif TC VF (Chinese) + Courier New (monospace)
  - PDF must be compiled from LaTeX (HTML-to-PDF is prohibited)

---

関連スキル

スキル	関係
deep-research	ディスパッチ先（ステージ 1 の調査フェーズ）
academic-paper	ディスパッチ先（ステージ 2 の執筆、ステージ 4／4' の改訂、ステージ 5 の書式設定）
academic-paper-reviewer	ディスパッチ先（ステージ 3 の初回レビュー、ステージ 3' の検証レビュー）

---

バージョン情報

項目	内容
スキルのバージョン	2.6
最終更新日	2026-03-08
メンテナー	Cheng-I Wu
依存スキル	deep-research v2.0 以降、academic-paper v2.0 以降、academic-paper-reviewer v1.1 以降
役割	学術研究ワークフロー全体のオーケストレーター

---

変更履歴

バージョン	日付	変更内容
2.6	2026-03-08	引き継ぎデータスキーマ：shared/handoff_schemas.md を拡充し、9つの包括的なスキーマ（RQ Brief、Bibliography、Synthesis、Paper Draft、Integrity Report、Review Report、Revision Roadmap、Response to Reviewers、Material Passport）について、すべてのフィールド定義、型制約、検証ルールを追加しました。オーケストレーターは各遷移の前に、出力をスキーマと照合して検証します。適応型チェックポイントシステム：静的なチェックポイントテンプレートを、ステージの重要度とユーザーの関与度に基づく3段階のシステム（FULL／SLIM／MANDATORY）に置き換えました。FULLチェックポイントには指標付きの意思決定ダッシュボードが含まれます。SLIMでは経験豊富なユーザー向けに自動で続行します。MANDATORYは、インテグリティ／レビュー／最終化の境界ではスキップできません。4回以上自動で続行した場合は注意喚起を行います。モードアドバイザー：スキル間で共通の意思決定ツリー、よくある誤解の一覧表、ユーザーの類型別の推奨事項、意思決定フローチャート、アンチパターンのガイドをまとめた新しい references/mode_advisor.md を追加しました。チームコラボレーションプロトコル：5つの役割定義、遷移ごとの引き継ぎ手順、Git のブランチ／タグ戦略、競合解決マトリクス、コミュニケーション用テンプレートをまとめた新しい references/team_collaboration_protocol.md を追加しました。ステージごとの状態トラッカーに assigned_to、approval_gate、team_notes と schema_validation_log を追加しました。フェーズ E 主張検証：E1 主張の抽出、E2 ソースの追跡、E3 相互参照を定めた新しい references/claim_verification_protocol.md を追加しました。判定分類（VERIFIED／MINOR_DISTORTION／MAJOR_DISTORTION／UNVERIFIABLE／UNVERIFIABLE_ACCESS）と重大度の対応（MAJOR_DISTORTION -> SERIOUS、UNVERIFIABLE -> SERIOUS、MINOR_DISTORTION -> MINOR、UNVERIFIABLE_ACCESS -> MEDIUM）を定義しました。integrity_verification_agent のモード 1（30% の抜き取り検査）とモード 2（100%）に統合し、合否基準にフェーズ E の判定を追加しました。中途投入時の Material Passport チェック：パイプラインオーケストレーターが中途投入時に Material Passport を検証するようになりました。意思決定ツリーでは、verification_status、鮮度（24時間未満）、コンテンツの変更（version_label の比較）を確認します。パスポートが有効な場合は、ステージ 2.5 に対してスキップ／抜き取り検査／完全な再検証の選択肢を提示します。パスポートの鮮度検証ルールを shared/handoff_schemas.md に追加しました。
2.5	2026-03-08	外部レビューのプロトコル：実際の学術誌査読者からのフィードバックを構造化して取り込みます（テキスト／PDF／DOCX）。4段階のワークフロー（解析 -> 戦略的なコーチング -> 修正 + Response to Reviewers -> 完全性チェック）を実行します。内部の模擬レビューとは動作を区別し、デフォルトで「すべて受け入れる」ことはせず、各コメントのリスクを評価し、解析した項目についてユーザーの確認を求めます。明確な能力上の境界を定めています（AI による検証 ≠ 査読者の満足）。
2.4	2026-03-08	ステージ 6 PROCESS SUMMARY：パイプライン完了後に論文作成プロセスの記録を作成します。ユーザーに希望する言語（zh/en/both）を尋ね、ユーザーの発言、重要な意思決定、反復の詳細、得られた教訓を含む、人間と AI の協働履歴全体をまとめた構造化 MD を生成します。最終章の Collaboration Quality Evaluation は必須で、6つの評価項目を1〜100で採点し、棒グラフによる視覚化、What Worked Well / Missed Opportunities / Recommendations / Human vs AI Value-Add / Claude's Self-Reflection を含みます。LaTeX + tectonic で PDF にコンパイルし、paper_creation_process_zh.pdf + paper_creation_process_en.pdf を出力します。
2.3	2026-03-08	ステージ 5 FINALIZE：書式スタイルの指定を必須化しました（APA 7.0 / Chicago / IEEE）。PDF は tectonic を使って LaTeX からコンパイルする必要があります（HTML から PDF への変換は禁止）。APA 7.0 では、バイリンガル対応のため XeCJK を使用し、apa7 ドキュメントクラス（man モード）を使います。フォント構成：Times New Roman + Source Han Serif TC VF + Courier New
2.2	2025-03-05	チェックポイント確認の操作仕様（ユーザーコマンド6種類と、それぞれの明確な動作）；モード切り替えルール（安全／危険／禁止のマトリクス）；スキル失敗時のフォールバックマトリクス（ステージごとの縮退戦略）；状態の所有権プロトコル（書き込みアクセス制御を伴う単一の信頼できる情報源）；素材のバージョン管理（監査証跡付きのバージョン管理済み成果物）；shared/handoff_schemas.md へのスキル間参照
2.1	2026-03	剽窃検出プロトコル（フェーズ D）を追加しました。独自性検証（D1 WebSearch、D2 自己盗用）を含むよう integrity_verification_agent を強化し、両方の検証モードを更新しました。
2.0	2026-02	ステージ 2.5／4.5 のインテグリティチェック、2段階レビュー、必須チェックポイント、Devil's Advocate、再現性の保証、integrity_verification_agent を追加しました。
1.0	2026-02	初版：5+1 ステージのパイプライン