orchestrate

Orchestrate Skill

medsci-skills バンドル内のリサーチ依頼を適切なスキルに振り分けるか、複数のスキルを正しい順序で連携させます。分類し、計画を立て、委任します。振り分け先のスキルの成果物を自分で作成せず、それを担当するスキルを呼び出してください。

---

Available Skills

スキル	分野	振り分けるタイミング
search-lit	文献	論文の検索、引用の検証、参考文献リストの作成、トピックが研究されているかの確認
design-study	方法論	研究デザインのレビュー、リークやバイアスの特定、報告ガイドラインの選択、解析計画の妥当性確認
intake-project	プロジェクト設定	新規または整理されていないプロジェクトフォルダー、「このプロジェクトは何か」の確認、分類とひな形作成
manage-project	プロジェクト管理	ディレクトリのひな形作成、進捗管理、チェックリストとタイムラインの生成
analyze-stats	統計	診断精度、人口統計、メタ解析統計、評価者間一致、回帰（ロジスティック／線形）、傾向スコア、反復測定のための R／Python コード生成
make-figures	可視化	ROC 曲線、フォレストプロット、フロー図（PRISMA／CONSORT／STARD）、Kaplan-Meier、Bland-Altman、ビジュアル／グラフィカルアブストラクト
meta-analysis	システマティックレビュー	MA の全工程：プロトコル、検索、スクリーニング、抽出、統合、PRISMA-DTA
write-paper	執筆	IMRAD 論文の執筆（8 フェーズのパイプライン）、あらゆるセクションの執筆
self-review	品質	領域別プローブ（サバイバル／SR-MA／ラジオミクス／ナラティブ）による投稿前のセルフチェック。重要な最終 QC パスにはオプションで --panel を指定
check-reporting	コンプライアンス	49 の報告ガイドラインおよびバイアスリスク評価ツールに照らした監査
revise	改訂	査読者コメントの解析、項目別回答の生成、変更箇所の追跡
grant-builder	資金調達	研究助成金申請書の構成：意義、新規性、研究計画、マイルストーン
present-paper	プレゼンテーション	学術発表の準備：論文の分析、発表原稿の下書き、スライドノートの挿入、質疑応答の準備
publish-skill	パッケージング	個人用スキルをオープンソースの配布可能パッケージに変換
calc-sample-size	統計	サンプルサイズ計算（Cox EPV を含む 17 種の検定）、検出力分析、IRB 正当化文書
find-journal	投稿	抄録と投稿範囲の適合性に基づくジャーナル推薦、却下後の再投稿先選定
add-journal	ジャーナル DB	プロファイルデータベースへの新しいジャーナルの追加。投稿規定からメタデータを抽出
fulltext-retrieval	文献	Unpaywall、PMC、OpenAlex API を使用し、DOI に基づいてオープンアクセス PDF を一括ダウンロード
deidentify	データ安全性	LLM で処理する前に、PHI を含む臨床データを匿名化します。単独で動作する Python CLI（LLM 不使用）。
clean-data	データ	データのプロファイリング、欠損値のフラグ付け、外れ値の検出、クリーニングコードの生成
generate-codebook	データ	データセットから引用可能なデータ辞書／コードブックを生成。コード化された変数には [NEEDS DICTIONARY] のフラグを付け、/define-variables に渡します
version-dataset	データ	データセットのコンテンツハッシュマニフェストを作成。ドリフト（スキーマ／行／値）を検証し、バージョン間の差分を確認。再現性を固定
write-protocol	プロトコル	IRB／倫理プロトコルの執筆、4 つの主要セクションと TODO マーカー付きの 6 つの骨組みセクション
define-variables	操作化	文献に基づく変数定義、カットオフ、DB 変数の対応付け。観察研究では /search-lit と /write-protocol の間で実行
verify-refs	参考文献監査	原稿の参考文献を PubMed／CrossRef で読み取り専用監査。筆頭著者の照合を行い、qc/reference_audit.json を書き込む唯一のスキル。参考文献は変更しません
manage-refs	参考文献管理	引用キーの検証、ジャーナル CSL による pandoc レンダリング、原稿と DOCX 間の相互参照 QC、[N] ↔ [@key] マーカー変換、Zotero CWYW フィールドコードの挿入。manuscript_final.docx と qc/xref_audit.json を書き込む唯一のスキル
lit-sync	参考文献同期	Zotero コレクション ↔ Better BibTeX manuscript/_src/refs.bib ↔ Obsidian 文献ノート。refs.bib（自動エクスポート）を書き込む唯一のスキルであり、manage-refs の上流に位置します
obsidian-paper-vault	Vault 構築	PDF フォルダーから、ひな形を使った Obsidian 文献ノートと、それらを横断して統合したアトミックな概念ノートを生成。PDF 側から lit-sync と同じ Vault フォルダーに格納
humanize	品質	AI パターンの密度をスキャン（目標は 1,000 語あたり <2.0）。技術的な正確さを保ちながら、フラグが付いた箇所を書き換えます。write-paper のフェーズ 7.5
academic-aio	可視性	医療 AI 論文向けの AI 検索エンジン最適化（Perplexity、ChatGPT web、Elicit、Consensus、SciSpace、RAG ツール）。任意で使用するチェックリストで、編集は自動適用されません
render-pdf-doc	文書レイアウト	参考文献以外の学術 Markdown を PDF に変換（提案書、ブリーフィング、基準文書、IRB 表紙、参考文献表）。CJK に対応。manage-refs scripts/render_pandoc.sh とは対になる境界
fill-protocol	フォーム入力	IRB／倫理／助成金テンプレート用の機関指定 Word フォーム（.doc／.docx）への入力。write-protocol の内容を機関のテンプレートに反映
fill-icmje-coi	フォーム入力	合成シードから著者ごとの ICMJE COI Disclosure Form を一括生成
sync-submission	投稿	SSOT と投稿内容のドリフト監査。正規の原稿アーティファクトからジャーナル固有の投稿マニフェストを作成
peer-review	査読	外部原稿の査読草案を生成（ジャーナル固有の書式）。他の著者の研究の査読にのみ使用し、セルフレビューには使用しないでください
review-paper	執筆	文献レビュー（ナラティブ／スコーピング PRISMA-ScR／システマティック）のひな形作成／草稿執筆。write-paper（独自研究）および meta-analysis（統合）とは異なります
polish-language	品質	学術英語の一貫性チェックと、非ネイティブ向けの明瞭さの調整（略語、米英綴り、範囲、P/p の大文字・小文字、単位）。文体のみが対象で、humanize（AI 特有の表現の除去）および check-reporting（ガイドライン項目）とは異なります
author-strategy	分析	PubMed の著者プロフィール分析：研究タイプの分類、研究経歴の類型化、著者名に基づく論文発表戦略レポート
batch-cohort	分析	検証済みの方法論テンプレート 1 つ × 複数の曝露／アウトカムの組み合わせから N 個の解析スクリプトを生成（同じ方法で変数を差し替え）し、サマリーマトリックスを作成
replicate-study	分析	異なるデータベースを使って既存のコホート研究の方法論を再現：デザインの抽出、変数調和テーブル、再現時の差異レポート
cross-national	分析	国際比較研究（KNHANES + NHANES + CHNS または並行調査）：変数の調和と並行する重み付け解析
ma-scout	システマティックレビュー	プロトコル作成前のメタ解析トピック発見と実行可能性評価（教授起点のプロファイル→ギャップ、またはトピック起点の問い→ギャップ→共著者）
find-cohort-gap	方法論	縦断コホート DB からの研究ギャップ発見：強みのプロファイリング、PI の専門性との照合、文献の飽和度スキャン、トピック提案の順位付け
design-ai-benchmarking	方法論	人間の専門家パネルを参照基準とする AI システムのベンチマーク設計／妥当性レビュー（評価基準、キャリブレーションプローブ、パネル構成、IRR 目標値）。データ収集前に使用
model-selection	モデリング	画像研究に使用するモデルを選択：論文に基づくアーキテクチャファミリー（タスク + モダリティ + データ規模 + 不均衡 → 候補リスト）を選び、具体的なリポジトリ／チェックポイントを検証（ライセンス、バージョンの固定、重みの来歴）。モデルの開発またはチューニングに使用されたベンチマークでの評価をフラグ付け
imaging-data	モデリング	モデリングの判断を行う前に画像データセットをプロファイリング（間隔／方向、強度領域、ラベルの整合性、前景の割合、対象ボリューム）し、計画に照らして適合性を確認。その後、前処理マニフェストとデータ段階のリークゲートを用いて、DICOM／NIfTI の取り込み、リサンプリング、正規化、拡張を計画／監査してから model-scaffold を実行
model-scaffold	モデリング	再現可能ですぐに実行できる PyTorch 学習リポジトリを生成（患者単位のシード固定分割、タスクモデル、学習／評価スクリプト、再現性記録）。アーキテクチャの選択と学習済みモデルの検証の間で使用
radiomics-ml	モデリング	ラジオミクス／表形式 ML 研究を作成／監査（画像または臨床特徴量 → 罰則付きロジスティック回帰／SVM／RF／勾配ブースティング／MLP → アウトカム）。ネスト化 CV／特徴量安定性／キャリブレーション／外部検証ゲートに対応（GPU 不要）
model-assessment	検証	学習済み画像モデルを検証／評価：分割リークゲートと検証デザイン（内部対外部、比較対象、サンプルサイズ設定）、タスクに適したホールドアウト指標（Dice + 境界、ブートストラップ CI 付き AUROC + AUPRC、FROC／mAP、キャリブレーション、サブグループ）→ 症例別テーブル、デプロイに関する主張のための不確実性／OOD／棄権、Grad-CAM／説明可能性の妥当性チェック + 局在
mllm-eval	評価	LLM／MLLM の臨床タスク（レポート生成、VQA、抽出／分類）向け評価ハーネスを設計／監査（裁定済み参照データ、BLEU／ROUGE を超える臨床的有効性指標、幻覚、汚染、プロンプト感度、読影者研究）
model-card	ドキュメント	エンジニアが構築した画像モデルについて、ユーザー提供の事実から Model Card + Datasheet + データ品質評価を生成し、完全性ゲートを適用
contribute	セットアップ	git を入力せずに、ローカルでの編集（ジャーナルプロファイル、修正）をプルリクエストまたは issue として提案。差分に患者データが含まれる場合は処理を止め、確認されるまで何も送信しません。誤検知や失敗したステップの報告にも使用
setup-medsci	セットアップ	読み取り専用の実行環境診断（Python、R、Node、Claude Code、Git、Zotero、MCP サーバー）。各不足コンポーネントのセットアップ文書とともに合否テーブルを表示

---

分類ロジック

各リクエストを、以下のいずれかのインテントに分類します。

単一スキルのリクエスト（直接ルーティング）

利用可能なスキルの行と一致するスキルにルーティングします。1行で理由を述べてから、そのスキルを呼び出します。以下の行では、モードやフラグ、似たスキル、英語以外の表現も扱います。

ユーザーの発言例	ルーティング先
「散らかったフォルダーを整理したい」	/intake-project
「新しいプロジェクトをセットアップして」／「プロジェクトのひな形を作成して」	/manage-project init
「投稿前に原稿を確認して」	/self-review
「投稿前に徹底的に／厳しく確認して」／「トップジャーナル投稿前の最終チェック」／「複数査読者／パネル査読」／「統計、臨床、画像診断の観点からレビューして」／「혹독하게 제출 전 점검」	/self-review --panel --json
「他人の原稿を査読して」／「ジャーナルクラブ用の批評原稿」／「외부 논문 리뷰 답변」	/peer-review
「どのジャーナルに投稿すればよい？」／「ジャーナルを探して」／「却下されたので、別の投稿先を探して」	/find-journal
「投稿先を同期して」／「ジャーナルを変更して」／「SSOT のずれを確認して」	/sync-submission
「ジャーナルのプロファイルを追加して」／「저널 프로필 추가」	/add-journal
「PDF をダウンロードして」／「全文を入手して」／「PDF 다운로드」	/fulltext-retrieval
「ビジュアルアブストラクトを作って」／「グラフィカルアブストラクト」／「GA 생성」	/make-figures
「データの匿名化をして」／「PHI を削除して」／「비식별화」／「익명화」／「患者データを匿名化して」	/deidentify
「IRB プロトコルを書いて」／「倫理審査の申請書を下書きして」／「研究プロトコル」	/write-protocol
「IRB プロトコルの書式に記入して」／「기관 양식 채워줘」／「심사면제 요청서 채움」／「동의면제 양식」	/fill-protocol
「変数を定義して」／「カットオフ値の根拠を示して」／「表現型の定義」／「변수 정의 근거」／「ad-hoc 정의 피하기」	/define-variables
「症例報告を書いて」／「興味深い症例がある」	/write-paper（症例報告モード）
「カバーレターを作成して」／「投稿用のカバーレターを書いて」	/write-paper（Phase 8 以降。完成した原稿が必要）
「原稿を DOCX に変換して」／「最終版の .docx を作成して」／「参考文献の形式を一括で変更して」／「ジャーナルの CSL を適用して」／「Vancouver 形式で再レンダリングして」／「회람용 docx」／「Zotero CWYW の挿入」	/manage-refs
「投稿計画書を PDF に変換して」／「アンカードキュメントを PDF に」／「한글 학술 PDF」／「説明資料の PDF」／「IRB カバー PDF」／「参考文献なしの Markdown → PDF」	/render-pdf-doc
「Zotero を同期して」／「refs.bib を更新して」／「Better BibTeX のエクスポート」／「Zotero ↔ Obsidian を同期して」／「文献ノートを作成して」	/lit-sync
「PDF を Obsidian ノートにして」／「論文の要約ノートを作成して」／「このフォルダー内の PDF を整理して」／「論文保管庫を作成して」／「セカンドブレイン」／「論文から概念を抽出して」	/obsidian-paper-vault
「ICMJE COI 書式を一括作成して」／「共著者の COI フォームを作成して」／「開示フォームの一括作成」	/fill-icmje-coi
「AI 検索の最適化」／「Perplexity 向けの抄録」／「RAG での可視性」／「GEO チェックリスト」／「Elicit／Consensus での露出」	/academic-aio
「AI らしいパターンを取り除いて」／「AI らしさを消して」／「このセクションを自然な文章にして」／「GPT の痕跡を消して」	/humanize

複数スキルのワークフロー（計画後、順番に実行）

Nodes 列には、インタラクティブモードで表示する判断の分岐が記載されています（以下の対話プロトコルを参照）。N1～N11 は ${CLAUDE_SKILL_DIR}/references/dialogue_nodes.md で定義されています。

シナリオ	スキルチェーン	ノード
新規プロジェクト、これまでの作業なし	intake-project -> search-lit -> design-study -> manage-project init	N1、N2（ユーザーが原稿の出力を希望する場合）、N3
データの準備が完了し、論文が必要	manage-project init -> analyze-stats -> make-figures -> write-paper	N6（PHI ゲート）、N3、N4（投稿先ジャーナルの選定時期）、N2
草稿があり、投稿準備をする	self-review -> check-reporting -> verify-refs -> humanize -> academic-aio（オプトインの --aio） -> manage-refs（DOCX ビルド + 相互参照の品質チェック --strict） -> manage-project checklist	N4（まだ確定していない場合）、N8（self-review が致命的な問題を返した場合のみ）
投稿用のレンダリングと連続したフォーマット変更	manage-refs（ワークフロー A の pandoc citeproc、または B の Zotero CWYW） -> manage-refs scripts/check_xref.py --strict -> verify-refs -> sync-submission build	N10（ワークフロー A と B の選択 — manage-refs SKILL.md の決定ツリーを参照）
リジェクト後、連続投稿先を変更	find-journal（リジェクトした投稿先を除外） -> manage-refs（新しい CSL で再レンダリング） -> write-paper Phase 8+（新しいカバーレター） -> sync-submission build --journal {new}	N4
書誌情報を含まない学術成果物（提案書／ブリーフィング／アンカードキュメント）	write-protocol -> fill-protocol（機関の様式が利用可能な場合） ⫶ render-pdf-doc（Markdown のみ、様式なし）	N11（様式の有無）
参考文献の整理サイクル	lit-sync（Zotero ↔ refs.bib の自動エクスポート） -> manage-refs scripts/check_citation_keys.py -> verify-refs --strict（筆頭著者の相互確認）	—
ICMJE COI の一括処理（複数著者の投稿）	fill-icmje-coi（合成シードから著者ごとの docx を生成） -> 手動で回覧	—
医療 AI 論文の AI 検索可視性チェック	self-review -> humanize -> academic-aio（タイトル、抄録、サマリーボックス、README / CITATION.cff / HF カード）	N4、N9（再編集範囲を決めるためのセクション入力）
査読者コメントを受け取った	revise -> analyze-stats（新たな分析が必要な場合） -> make-figures（新たな図表が必要な場合）	N1
メタ分析を一から実施	meta-analysis（独自のパイプラインを処理します。プロトコルの作成後、登録が提出されるまで、または登録なしで進める選択をユーザーが記録するまで停止し、その後 search-lit で検索し、fulltext-retrieval で全文を取得します。search-lit は論文を選定して結果を抽出するため、meta-analysis より先にいずれも実行しないでください）	N2（MA の種類）、N5（統合の範囲）
助成金申請書の作成	search-lit -> grant-builder	N2（オプション 5）
学会発表	present-paper（独自のパイプラインを内部で処理します）	N1
新規研究で IRB プロトコルが必要	search-lit -> design-study -> calc-sample-size -> define-variables -> write-protocol	N3、N2（オプション 4 — プロトコル）
観察コホート研究（後ろ向き／スクリーニング／レジストリ）	intake-project -> design-study -> search-lit -> define-variables -> write-protocol -> analyze-stats -> write-paper	N1、N2、N3
PHI を含むデータで、全工程が必要	deidentify -> clean-data -> analyze-stats -> make-figures -> write-paper	N6（必須）、N3、N4
データの準備が完了し、まずクリーニングが必要	clean-data -> analyze-stats -> make-figures -> write-paper	N6、N3、N4
投稿までの全工程	write-paper -> self-review -> check-reporting -> find-journal -> write-paper（Phase 8+ のカバーレター） -> manage-project checklist	N4、N8（リカバリーが開始された場合）、N9（再開時）
リジェクト後の再投稿	find-journal（リジェクトした投稿先を除外） -> write-paper（Phase 8+ の新しいカバーレター）	N4
症例報告のパイプライン	search-lit（類似症例） -> write-paper（症例報告モード） -> self-review -> check-reporting（CARE） -> find-journal	N2（オプション 2）、N4
パネルモード（/self-review --panel）はオプトインであり、自動ではありません。 上記のチェーンでは、単一パスの self-review を使用します。--panel は、ユーザーが重要度の高い最終チェックを求めた場合に限り追加してください。複数のレビュアーエージェントとエディターが起動するため、トークン消費量が数倍になります。--e2e を含め、デフォルトで有効にしてはいけません。--panel と --fix を組み合わせてはいけません。パネルは診断と優先順位付けを行い、修正ループは別のパスです。

曖昧なリクエスト（振り分けの前に確認する）

意図が本当に不明確な場合は、確認の質問を1つだけしてください。同じターンで2つ質問してはいけません。妥当な推測ができる場合は、それに基づいて対応し、確認してください。パイプライン内では、質問する代わりに該当するノードを表示してください。例：

• "Help with my paper" -> 質問：「執筆を始めたいですか、既存の草稿をレビューしたいですか、それとも査読者のコメントに対応したいですか？」
• "What should I do next?" -> まず作業ディレクトリで project_state.json または STATUS.md を確認します。見つかった場合は読み込み、次に進むべき論理的なステップを提案します。見つからない場合は、何に取り組んでいるのかを尋ねます。

---

ワークフローの実行 — 対話プロトコル（デフォルト）

--e2e を指定せずに複数スキルのチェーンを実行する場合は、分岐ごとに1つの判断ノードを進めます。ノードを計画の箇条書きと「進めてもよいですか？」に置き換えてはいけません。論文の種類、研究デザイン、投稿先ジャーナル、復旧ブランチがひそかに確定されてしまうためです。また、write-paper に組み込まれているゲート（アウトラインの承認、考察の計画）でも一時停止します。

現在のセッションでパイプラインが初めて判断分岐に入った時点で ${CLAUDE_SKILL_DIR}/references/dialogue_nodes.md を読み込みます。このファイルには、各ノードの選択肢、表示テンプレート、自律的なデフォルトが記載されています。

分岐ごとの実行手順：

1. 分岐のノードを特定します（Multi-skill workflows テーブルの Nodes 列）。
2. 参照ファイルの §「Rendering Template」に従って表示します。約15行以内とし、各選択肢の unlocks / locks / recovery_cost を示し、自律的なデフォルトを明示します。
3. 数値の選択肢または制御語を待ちます。1ターンにつき1つのノードのみです。2つを続けて提示してはいけません。
4. スキルを呼び出す前に、ロック内容を1行で復唱します（「確定：CARE reporting guideline； abstract = structured 250w.」）。
5. 選択されたオプションに対応する下流のスキルを呼び出し、次の分岐では手順1に戻ります。
6. スキルの出力に応じて対応を調整します。以前のロックが無効になった場合（例：/self-review で Step 7.4a のトリガーが見つかった場合）は、チェーンを続けずに復旧ノード（N8）に進みます。

制御語。 back は前のノードに戻ります。pause はパイプラインを停止し、制御をユーザーに戻します。skip は、locks の範囲が空のノード（まれ）の場合に限り使用できます。それ以外の場合は、スキップできない理由を説明してください。

---

フルパイプラインモード

ユーザーが「フルパイプラインを実行して」などと依頼した場合は、以下の標準パイプラインを実行します。

--e2e フラグ

事前検証（--e2e の開始時に1回実行）

--e2e モードで後続のスキルを呼び出す前に、以下の4項目を確認します。いずれか1つでも失敗した場合、パイプラインを停止します。4項目すべての結果を、そのまま manuscript/<id>/REPORT.md の Frozen / Version status と Source artifacts checked の下に記録してください（「REPORT.md Generation」を参照）。

1. STATUS / project_state：作業ディレクトリにある STATUS.md または project_state.json を読み込み、現在のフェーズを確認します。どちらも存在しない場合、ユーザーが --no-status を指定していなければ、STATUS_MISSING で停止します。
2. 凍結済みアーティファクト：manuscript/<id>/v_*_package/ をスキャンします。最新の v_N に _FROZEN マーカーファイルがあるか、INDEX.md::frozen=true の場合、この実行では v_(N+1)_package/ ブランチのみが許可されます。v_N に直接書き込もうとした場合、FROZEN_VIOLATION で停止します。
3. 必須入力：要求されたフェーズの入力アーティファクトが存在することを確認します。例：Phase 4 の図には analysis/_analysis_outputs.md が必要です。Phase 7 のセルフレビューには manuscript/manuscript.md が必要です。欠落している場合、REQUIRED_INPUT_MISSING: <path> で停止します。
4. 依存フェーズの未完了：ユーザーがフェーズ k を要求したものの、前のフェーズが未完了の場合、デフォルトでは DEPENDENCY_MISS: [Phase i, Phase j] で停止します。ユーザーが明示的に --auto-extend を指定した場合に限り、オーケストレーターは未完了フェーズを先行させて続行できます。

--e2e パイプラインの動作

--e2e が指定された場合（またはユーザーが「end-to-end」、「Arm A」、「fully autonomous」と伝えた場合）：

1. --e2e モードを ON にします。
2. /write-paper の呼び出し時に --autonomous を渡します。
3. /self-review と /check-reporting の呼び出し時に --json を渡します。
4. オーケストレーターによる確認（「続行しますか？」）はすべて省略し、Dialogue Protocol のノードは一切表示しません。
5. インタラクティブに表示されるはずの各ノードについて、dialogue_nodes.md に記載された default を適用し、選択内容を qc/_pipeline_log.md に次の形式で記録します： [orchestrate] N{id}: defaulted to option {n} ({label}) — {autonomous_rationale}。
6. データ安全性のゲート（PHI Safety Gate / node N6）は必ず尊重します。PHI の状態が不明な場合、1回だけ確認を求めて自律実行を停止します。事前検証の通過後に自律モードを中断し得るのは、PHI とシステマティックレビューの登録だけです。/meta-analysis はプロトコルを作成した後、プロジェクトに登録申請日が記録されているか、登録せずに進めるというユーザー自身の選択が記録されていない限り、検索前に REGISTRATION_PENDING で停止します（Phase 2 の開始時チェック）。オーケストレーターが登録申請を行うことはなく、この停止を越えて先に進むこともありません。登録前に実施したスクリーニングやデータ抽出は、後から前向き研究として扱うことができないためです。
7. Audit Recovery（node N8）：ルーティングされたリカバリースキルを自動的に呼び出します。ルートの検証に2回失敗した場合、ログに RECOVERY_HALT_HUMAN_DECISION を記録して停止します。
8. AIO（academic-aio）は、--e2e ではデフォルトで OFF です。AI 検索での可視性は投稿前に検討すべき事項であり、自律実行のたびに実行するとトークンを浪費するうえ、スキルの「黙って編集しない」という契約に違反する、通知のない書き換えを招くためです。ユーザーが明示的に --aio を追加した場合（または投稿と並行してプレプリント／GitHub README／HF card を準備する場合）に限り、有効にします。有効な場合は /humanize の後に実行し、チェックリストの基準を QC 確認済みで人が読める文章に合わせます。PASS/PARTIAL/FAIL のレポートをユーザーに提示し、編集を自動適用することは決してありません。
9. 各スキルの完了後、スキル後検証を実行します（以下を参照）。検証に通過したら、確認を求めずに次のスキルへ進みます。

標準パイプライン：データ → 論文原稿

1. /analyze-stats → analysis/tables/*.csv、analysis/figures/*、analysis/_analysis_outputs.md、analysis/analyze.py
2. /make-figures --study-type {type} → analysis/_analysis_outputs.md を読み込み → analysis/figures/*.pdf、analysis/figures/*.png、analysis/figures/_figure_manifest.md
3. /write-paper --autonomous（--e2e の場合）→ analysis/ を読み込み → manuscript/manuscript.md（DOCX のレンダリングはステップ 7 に委任）
   • フェーズ 7.4 では内部で /self-review --json --fix を呼び出します → qc/self_review.md
4. /check-reporting → manuscript/manuscript.md を読み込み → qc/reporting_checklist.md + qc/reporting_checklist.json（Part D JSON。write-paper のフェーズ 7 内で呼び出されますが、オーケストレーターが出力を検証します）
5. /verify-refs → manuscript/manuscript.md を読み込み → qc/reference_audit.json（唯一の出力。行レベルのステータスは records[] に記録）
6. /self-review --json --fix → manuscript/manuscript.md を読み込み → qc/self_review.md + 自動修正（write-paper のフェーズ 7.4 内で呼び出されますが、オーケストレーターが最終出力を検証します）
7. /manage-refs（ワークフロー A：pandoc citeproc、または B：Zotero CWYW）→ manuscript/manuscript.md + manuscript/_src/refs.bib を読み込み → manuscript/manuscript_final.docx + qc/xref_audit.json。投稿ゲート：check_xref.py --strict の合格が必須です（MISSING_DOCX / MISSING_BODY / MISMATCH がないこと）。

スキル実行後の検証

各スキルの実行後、想定される出力ファイルが存在することを確認し、見つかったファイルパスをコンテキストとして次のスキルに渡してください。検証に失敗した場合はエラーを報告し、次のスキルには進まないでください。

スキル	想定される出力	検証
/analyze-stats	analysis/tables/*.csv に少なくとも1つのファイル、または analysis/_analysis_outputs.md	ファイルの存在と空でないことを確認
/make-figures	エントリーが1件以上記載された analysis/figures/_figure_manifest.md	マニフェストを解析し、記載されたファイルが存在することを確認
/write-paper	manuscript/manuscript.md（必須）	ファイルの存在と空でないことを確認してください。DOCXはここでは必須にしないでください。manuscript_final.docx は後で /manage-refs（ステップ7）が生成するため、必須にするとDOCXができる前に --e2e の実行が停止してしまいます
/check-reporting	qc/reporting_checklist.md と qc/reporting_checklist.json（Part D JSON）	JSONを解析してください。ファイルが存在しない、解析できない、または整数の missing がない場合は、ファイル名を示して停止してください。missing > 0 または action_items[].status == "MISSING" の項目がある場合は、REPORTING_ITEMS_MISSING として停止し、該当する各項目を列挙して、ステップ7に進まず、不足分を /write-paper Phase 7 に回してください。ファイルを書き出していないインラインレポートは合格とみなしません
/verify-refs	qc/reference_audit.json（唯一の出力）	JSONを解析してください。submission_safe == false（つまり、FABRICATED / MISMATCH の件数が0より大きい、または duplicate_findings[] が空でない）の場合は停止してください
/self-review	Phase 3cのJSONブロック（--json）を含む qc/self_review.md	JSONブロックを解析してください。ブロックが存在しない、解析できない、または整数の fatal_count がない場合は、ファイル名を示して停止してください。fatal_count > 0 または issues[].severity == "fatal" の項目がある場合は、ステップ7に進まず、N8（監査リカバリー）に回してください。致命的な問題がない REVISE 判定は停止せず、スコア、判定、件数を qc/_pipeline_log.md と REPORT.md に記録してください。--panel が issues に追加する任意の consensus 配列と R1/R2/R3 の帰属情報は、追加項目として後方互換で受け入れてください
/manage-refs	manuscript/manuscript_final.docx、qc/xref_audit.json	DOCXが存在し、空でないこと。xref_audit.json の submission_safe: true（P0ブロッカー行なし）
/lit-sync	manuscript/_src/refs.bib（mtimeが更新済み）、references/zotero_collection.json	refs.bib のmtimeがコレクションのスナップショットより新しいこと。コレクションJSONで refs_bib_refreshed: true になっていること

検証に失敗した場合：

• 失敗したスキル、不足している出力、エラーメッセージがあれば、それを記録します。
• --e2e モードの場合：エラーを qc/_pipeline_log.md に報告して停止します。次のスキルには進みません。次のように出力します："Pipeline halted at {skill}: {missing output}. Check the skill's output and re-run."
• 対話モードの場合：エラーを報告し、どのように進めるかユーザーに尋ねます。

REPORT.md の生成

すべての --e2e 実行の終了時に、パイプラインが完了した場合、プリフライトで停止した場合、またはスキル実行後の検証で停止した場合のいずれであっても、Worker はテンプレート ${CLAUDE_SKILL_DIR}/references/report_template.md を使用して manuscript/<id>/REPORT.md を必ず作成しなければなりません。

• テンプレートのすべてのセクションをそのままコピーしてください。セクションを削除してはいけません。空のフィールドには (none) または (unknown) を記入してください。省略や統合はしないでください。
• §「Pipeline log」の項目には、qc/_pipeline_log.md の5行の要約を記載してください（Dialogueノードに適用された既定値、スキルの呼び出し、停止理由があればその理由）。ログ全体を貼り付けないでください。
• §「Tier-3 Blocked Items」のフックとプロンプトガードの区分は必須です。下記の §「Tier-3 Worker Guard」を参照してください。
• §「Next safe command」の行には、次のフェーズを再開するためにユーザーがコピーできるコマンドをそのまま記載してください。説明を加えないでください。
• REPORT.md はユーザーが確認する唯一の成果物です。その他のすべてのQC出力は、REPORT.md からリンクしてください。

Tier-3 ワーカーガード

以下の操作は --e2e 自律フロー内では恒久的に禁止されています。 検出されると、ワーカーはパイプラインを停止し、試行を REPORT.md §"Tier-3 Blocked Items" に tier3_pending: <command> として記録します。フックで確認されたブロックとプロンプトのみのブロックは別々に記載されるため、将来フックに不具合が生じても、プロンプトのみのブロックがひそかに解除されることはありません。

フックで確認済み（Tier-3 確認フックがインストールされている場合）：

• gws gmail +send / +reply
• YouTube へのアップロード

プロンプト／スキルガードのみ（フックによる保護なし — ワーカーのプロンプトで強制）：

• git push、gh pr create
• MCP Gmail の送信、MCP Calendar の送信
• MCP GitHub の create-pr
• /sync-submission build の外部公開パス
• Phase 8 の投稿 DOCX 自動ビルド／ジャーナルへの投稿
• シニアメンターによるメールの自動返信

git commit は許可されていますが、その後に git push を試みると停止します。回覧メールは Gmail の下書きとしてのみ保存され、送信されることはありません。

データフロー契約

スキルを連携させる際に、読み取りまたは書き込みの対象を確認する必要がある場合は、${CLAUDE_SKILL_DIR}/references/data_flow_contract.md を読んでください（上記の標準パイプラインには、それ自体が扱うファイルがすでに記載されています）。

E2E 後：ジャーナルの選定と投稿準備

E2E パイプライン完了後（またはユーザーがジャーナルの選定を依頼した場合）、このワークフローを利用できます。ユーザーによるジャーナルの選定が必要なため、--e2e の一部ではありません。明示的にユーザーが呼び出した場合にのみ実行されます。

1. /find-journal → manuscript/manuscript.md の要旨に基づく上位 5 件の推薦
2. /verify-refs → パッケージ化する前に、捏造または不一致のある参考文献をブロック
3. ユーザーがジャーナルを選択 → submission/{journal_short}/ ディレクトリを作成
4. /sync-submission build --journal {journal_short} → 正本の原稿から派生した原稿パッケージを作成または更新
5. submission/{journal_short}/ 内に生成：
   • cover_letter.md：/write-paper Phase 8 以降を使用
   • checklist.md：ジャーナル固有の投稿チェックリスト
   • manuscript_final.docx：対象ジャーナルに合わせて /manage-refs で再レンダリング（形式が異なる場合）
6. 選択したジャーナルを対象に /self-review を実行 → ジャーナルの対象範囲を考慮した最終確認（他の著者の著作のみをレビューする /peer-review は使用しません）

---

PHI 安全ゲート

データを扱うスキル（clean-data、analyze-stats、make-figures）に処理を振り分ける前に、データに PHI が含まれている可能性があるか確認してください。

1. タスクで読み取る各 CSV／Excel ファイルについて、それ自体が *_deidentified.* の出力（あるファイルの匿名化済みコピーがあっても、他のファイルについては何も示しません）ではない場合、次のように尋ねてください。 「データに患者識別情報（PHI）は含まれていますか？（氏名、国民 ID／RRN、生年月日、連絡先など）」

   • はいの場合 → まず /deidentify に処理を振り分け、その後、*_deidentified.* の出力ファイルを使って、最初に依頼されたスキルを続行します
   • いいえの場合、またはユーザーがデータはすでに匿名化済みだと確認した場合 → そのまま続行します

2. 匿名化は、研究者の積極的な参加が必要な対話型プロセスです。 次のように警告してください。「匿名化には研究者本人による直接の確認が必要です。ターミナルでスクリプトを実行し、各項目を確認してください。」

---

コンテキストの検出

振り分ける前に、作業ディレクトリ内のコンテキストの手がかりを確認してください。

見つかったファイル	示唆されること
project_state.json	管理中のプロジェクトが進行中です。現在のフェーズを把握するため、ファイルを読み込んでください
STATUS.md	ステータス追跡を行っているプロジェクトです。現在の段階と阻害要因を確認してください
PROJECT.md	プロジェクトの概要が存在します。コンテキストとして使用してください
CLAIMS.md	主張と結果の対応表が存在し、執筆が進行中です
REVIEW_LOG.md	改訂サイクル中であり、/revise が必要な可能性があります
*.qmd または *.tex ファイル	原稿の執筆が進行中です
*.bib ファイル	参考文献が存在し、検証が必要な可能性があります
PRISMA_*.md または QUADAS*.md	メタ分析またはシステマティックレビューです
編集決定通知または査読者の PDF	/revise に振り分けてください
分析スクリプトを伴わない CSV／Excel データファイル	未加工データのクリーニングが必要な可能性があります。まず /clean-data を提案してください
*_deidentified.* または audit_log.csv	一部のデータは匿名化されています。PHI 安全ゲートを省略できるのは *_deidentified.* の出力のみです。タスクで読み込むその他すべてのデータファイルに対して実行してください
protocol_draft.md	プロトコルの作成が進行中であり、/write-protocol が必要な可能性があります
sample_size_*.csv または sample_size_*.R	サンプルサイズの計算が完了しています。次にプロトコルまたは原稿が必要か確認してください

---

ガードレール

• スキルを決して捏造しないでください。 Available Skills の表に記載されたスキルにのみ振り分けてください。
• 既存の状態を尊重してください。 プロジェクトのひな形が存在する場合、再初期化しないでください。