write-paper

論文執筆スキル

8 フェーズのパイプライン

フェーズ 0：初期設定

執筆を始める前に、ユーザーから必要な情報を集めます。

必須入力：

1. タイトル（仮題でも構いません）
2. 論文の種類：原著論文、AI 検証、症例報告、症例シリーズ、メタアナリシス、テクニカルノート、動物研究、NHIS コホート、国際比較研究
3. 投稿先ジャーナル：${CLAUDE_SKILL_DIR}/references/journal_profiles/ からプロファイルを読み込みます
4. 研究課題／仮説
5. 利用可能なデータ：すでに存在するデータセット、表、解析

任意のフラグ：

• --no-llm-disclosure：LLM による執筆支援の開示を省略します。デフォルトは ON です。
• --autonomous：ユーザーによる確認（アウトラインの承認、T&F 計画、考察の計画、各セクションのレビュー）をすべて省略して、フェーズ 0～7 を実行します。デフォルトは OFF です。

アクション：

1. ジャーナルのプロファイルを読み込みます。プロファイルがない場合は、語数制限、抄録の形式、引用スタイル、図表の上限、特別な要件を確認します。

2. ${CLAUDE_SKILL_DIR}/references/paper_types/ から論文の種類に応じたテンプレートを読み込みます。

3. 報告ガイドラインを選択します：診断精度 → STARD / STARD-AI · 予測モデル → TRIPOD+AI · 放射線医学 AI → CLAIM 2024 · RCT → CONSORT / CONSORT-AI · システマティックレビュー → PRISMA 2020 · 観察研究 → STROBE · 教育関連 → 該当する場合は SQUIRE。

4. AI／LLM の設計段階における報告項目の対応付け（AI 検証、LLM／MLLM、NLP による抽出、レポート生成）：ドラフトの作成前に、必須の AI 報告項目すべてを原稿のセクションに対応付けます。対象項目は、モデル／バージョン／アクセス日、入力フィールド、プロンプトまたはファインチューニングのプロトコル、適応を主張する場合の同一バックボーンを用いたゼロショット／少数ショットのベースライン、テストデータの独立性／汚染、再現性、およびそれぞれを記載する Methods の小節です。対応付けできない項目がある場合は、フェーズ 7 の限界として埋め込むのではなく、設計を明確化するために作業を中断します。

5. プロジェクトのディレクトリ構成を作成するか、既存のものを確認します。

6. --no-llm-disclosure と --autonomous のフラグの状態を記録し、フェーズ 1～7 の確認ロジックに使用します。

7. バックボーン論文を特定します — まず manuscript/_src/refs.bib を確認し、優先順位（以下の「バックボーン論文の優先順位」）に従って先回りして候補を提示します。候補が見つからない場合に限り、ユーザーに確認します。選んだ citekey を project.yaml::backbone_article に記録します。その後、全文の有無を確認します。全文が抽出されていないバックボーン論文は、名前だけのバックボーンです。これでは抄録に基づくドラフトになってしまいます：

   python3 ${CLAUDE_SKILL_DIR}/scripts/gate_backbone_fulltext.py \
     --project project.yaml --refs manuscript/_src/refs.bib \
     --fulltext-dir pdfs/ --strict
   

   --fulltext-dir 内のファイルがバックボーン論文に該当するのは、ファイル名が <citekey>.md である場合、または References 見出しより前にバックボーンの DOI／citekey が記載されている場合です。参考文献リストでバックボーン論文を引用しているだけの論文は該当しません。既知の制限：別の論文の本文に DOI が記載されている場合でも一致と判定されます。疑いをなくすには、ファイル名を <citekey>.md にするか、--fulltext を指定してください。

   BACKBONE_FULLTEXT_MISSING / BACKBONE_FULLTEXT_THIN → 作業を止めて全文を取得します（/lit-sync のフェーズ 2.7、その後 /fulltext-retrieval の pdf_to_md.py）。この条件を満たすまで Methods の執筆を始めないでください。論文の全文を実際に入手できない場合は、その制限を記録し、抄録のみで作業を進める前にユーザーの確認を得てください。

8. 設定内容（ジャーナルの制約、論文の種類、報告ガイドライン、バックボーン論文、ディレクトリパス、LLM 開示の状態）を要約し、続行する前に確認します。

フェーズ 0 ゲート：Citekey のみの参考文献

Citekey を厳守すれば、引用の捏造は投稿ゲートでブロックできる、目に見えるプレースホルダーになります。

1. 本文中の引用はすべて [@citekey] でなければなりません。citekey は manuscript/_src/refs.bib に存在する必要があります。Pandoc/Quarto のスタイルのみを使用し、「(Smith et al., 2024)」のような自由記述は使わないでください。

2. これから引用する予定だが、まだ取り込まれていない文献には、[@NEW:short-topic]（ケバブケース、30 文字以内、 原稿内で一意）を使用してください。

3. refs.bib に項目がない場合、実在するように見える citekey（[@Smith_2024_AI]）を捏造してはなりません。許可されるプレースホルダーは [@NEW:...] のみです。

4. [@NEW:...] プレースホルダーはすべて、フェーズ 7 までに解決する必要があります（/search-lit → /lit-sync で確認済みの項目を取り込み、Better BibTeX が refs.bib を更新します）。/search-lit で DOI または PMID が確認された参考文献のみを引用してください。それ以外は [UNVERIFIED - NEEDS MANUAL CHECK] と記してください。

5. 投稿前チェックでは、/sync-submission でパッケージを確定する前に、一致件数がゼロでなければなりません。

   grep -E '\[@NEW:[^]]+\]|\[N\]|\[N–N\]' manuscript/index.qmd
   

   裸の [N] / [N–N] マーカーは、このパイプライン外で（refs.bib なしに）作成され、手法を支える引用が未解決の原稿を意味します。[@NEW:...] と同様にブロックしてください。

refs.bib が存在しない場合は、コメント % refs.bib managed by /lit-sync via Zotero Better BibTeX. Do not hand-edit. を付けて空のファイルを作成し、SSOT.yaml に reference_manager.required_for: project_owner を記録して、作業を続行してください。最初の /lit-sync の実行までは、初期の引用はすべて [@NEW:...] になります。

必要に応じて読む — 論文の種類が判明した後（ステップ 2）、該当する行のみ：

ファイル	読むタイミング
references/phase0_init_detail.md → 症例報告モード	論文の種類が case report の場合 — 語数・抄録・参考文献数の上限に関する例外、CARE の 8 セクション構成案、標準図
references/phase0_init_detail.md → 症例集積モード	論文の種類が case series の場合 — 方法の記述を簡潔にした小規模コホートの構成案、全症例の要約表、率ではなく件数を示す原則
references/phase0_init_detail.md → 基盤文献の順位付け	refs.bib が存在し、基盤文献を提案する場合

---

フェーズ 1：アウトライン

論文の種類に対応するテンプレートのセクション構成に沿って、アウトラインを作成します。まずヘッダーを記載します。内容は、仮題、投稿先ジャーナル、論文の種類、総語数上限（抄録、参考文献、図表説明を除く）です。次に、各セクションの語数配分と、段落または小見出し単位の計画を示し、語数の合計がジャーナルの上限内に収まるようにします。最後に、予定する表、図、補足資料を、それぞれ 1 行ずつ記載します。

ゲート： アウトラインをユーザーに提示してください。ユーザーが承認するか、変更を依頼するまで先に進んではなりません。 自律モード： このゲートを省略し、アウトラインを qc/_pipeline_log.md に記録して、フェーズ 2 に進んでください。

---

フェーズ 2：表と図

本文を書く前に、すべての表と図を設計します。これにより、データに沿った叙述にします。

1. 利用可能なデータをユーザーと確認します。表 1（人口統計学的特性／ベースライン特性 — 必須）、表 2 以降（主要評価項目と副次評価項目）および補足表を計画します。図 1 は研究フロー図（該当する場合は CONSORT／STARD／PRISMA）とし、その後に性能曲線、フォレストプロット、キャリブレーションプロットなどを続けます。
2. 統計解析が必要な場合は /analyze-stats を呼び出します。
3. 研究の種類に必要な図一式を指定して /make-figures を呼び出します。ユーザーに図を一つずつ指定するよう求めないでください。Phase 0 の論文種別／報告ガイドラインに対応する --study-type を渡します：診断精度 → diagnostic-accuracy、予測モデル → ai-validation、システマティックレビュー → meta-analysis、DTA システマティックレビュー → dta-meta-analysis、観察研究 → observational-cohort、RCT → rct、症例報告 → case-report。
4. ビジュアルアブストラクト。 ジャーナルのプロフィールにある「Visual Abstract」セクションで作成が必須または推奨されている場合は、タイトル、Key Points 1 と 3、方法の概要、および視覚要素として最適な研究図を指定して、ビジュアルアブストラクトを /make-figures に依頼します。
5. 図の埋め込み。 analysis/figures/ 内のすべての PNG と PDF を確認します。それぞれについて、Results の適切な位置に ![Figure N. Caption](analysis/figures/filename.png){width=80%} を挿入し、図の種類と解析の内容に基づいて凡例を作成します。
6. マニフェストの検証（HALT ゲート）。 analysis/figures/_figure_manifest.md が存在し、少なくとも 1 件の図のエントリが含まれている必要があります。Phase 7 の DOCX ビルドではこのファイルを基に図が埋め込まれるため、マニフェストがないとすべての図が気付かれないまま除外されます。マニフェストが存在しない、または空の場合：自律モードでは、エラーコード MANIFEST_MISSING で HALT し、qc/_pipeline_log.md に記録し、manuscript/<id>/REPORT.md の Tier-3 セクションに復旧手順を記載します（「/make-figures を再実行するか、_figure_manifest.md を手動で作成する」）。対話モードでは、エラーを報告して、どのように進めるかユーザーに確認します。

ゲート： T&F の計画をユーザーに提示します。ユーザーの承認を得るまで先に進まないでください。 自律モード： このゲートをスキップします。T&F の計画を qc/_pipeline_log.md に記録し、フェーズ 3 に進みます。

---

フェーズ 3：方法

まず方法を執筆します。最も客観的なセクションであり、論文のほかの部分の基盤となるためです。

執筆前： ${CLAUDE_SKILL_DIR}/references/section_guides/methods.md を読み込み、該当する研究タイプの ${CLAUDE_SKILL_DIR}/references/exemplar_methods/（診断精度／STARD、AI 検証／TRIPOD+AI・CLAIM、観察コホート／STROBE、メタ分析／PRISMA 2020、RCT／CONSORT 2010）をざっと確認します。各段落で何を明らかにすべきか、また各タイプで最も頻繁に欠落する要素を確認してください。フェーズ 3～6 で使用する参考例はすべて合成データで、具体的な内容はプレースホルダーです。構成を参考にしてください。本文をコピーするものではありません。

執筆順序：（1）研究デザインと実施環境、（2）参加者／データセット（選択基準／除外基準、募集期間）、（3）手順／介入／AI モデルの説明、（4）評価指標（主要および副次エンドポイント）、（5）統計解析（${CLAUDE_SKILL_DIR}/references/section_templates/methods_statistical.md）、（6）倫理に関する記述、（7）AI／LLM に関する開示（--no-llm-disclosure が指定されていない場合）：投稿先ジャーナルが方法セクションへの記載を求める場合は、LLM 執筆開示の方法セクション用段落を追加します。

AI／LLM 抽出に関する追加事項（該当する場合）：

• データセット／入力では、モデルに与えたテキストフィールドを正確に示し、病歴、 適応、所見、以前の診断、紹介文をマスキングしたかどうかを記載します。提供された フィールドに目的のラベルが含まれる可能性がある場合は、方法でそのフィールドを除外するか、 情報漏洩のないフィールドを用いた感度分析について説明する必要があります。
• AI モデルまたは統計解析では、ファインチューニング、LoRA、プロンプトエンジニアリング、 マルチエージェントラッパーによって性能が向上するという主張をする場合、同一バックボーンを 用いたゼロショット／フューショットの比較対象を含めます。

プロセス： 批評・修正ループ（批評レビュー基準）を実行し、最終版の方法をユーザーに提示します。

---

フェーズ 4：結果

承認済みの表と図に沿って結果を執筆します。結果＝「何が分かったか」 —それ以外は書きません。 すべての文は、数値で裏付けられた事実を述べる必要があります。

執筆前： ${CLAUDE_SKILL_DIR}/references/section_guides/results.md を読み込み（方法との対称性、フローチャート、欠測データ、解釈を避けるためのセルフチェック）、該当する研究タイプの ${CLAUDE_SKILL_DIR}/references/exemplar_results/（同じ5種類。それぞれ方法セクションと同じ順序）をざっと確認します。

ルール：

• 順序：研究対象集団（登録、除外、人口統計 → 表 1）、主要エンドポイントの結果（主要評価項目ごとに 1 段落）、副次エンドポイント、サブグループ／感度分析。
• results.md のセルフチェックをすべての文に適用します。「なぜ」を述べない、先行研究に言及しない、因果関係を示す表現（「引き起こした」「につながった」「～が原因で」など）を使わない（「関連していた」を使用）、解釈を含む留保表現（「示唆する」「意味する」「一致する」「予想どおり」など）を使わない、数値を伴わずに評価的な形容詞を使わない。
• 増分価値は主張するものではなく、実証する必要があります。 論文でモデル／マーカーが既存のツール（臨床スコア、通常の検査、ベースラインモデル）を超えて価値を加えると主張する場合、ネストしたモデルの比較、すなわち通常使用される予測因子によるベースラインモデルと拡張モデルの比較を、増分指標（ΔC-index／ΔAUC（対応のある CI、例：DeLong）、NRI、IDI、または決定曲線のネットベネフィット）とともに結果に報告する必要があります。単独の識別能の数値だけでは、「X を超える」という主張を裏付けられません。研究デザインにベースライン比較対象が含まれていない場合（/design-study のフェーズ 3 を参照）、付加価値があるかのように述べず、単独での性能についての主張にとどめます。

プロセス： 批評・修正ループを実行します。ゲート： 最終版の結果をユーザーに提示します。考察に進む前に確認を取ります。

---

フェーズ 5：考察

執筆前： ${CLAUDE_SKILL_DIR}/references/section_guides/discussion.md を読み込み、${CLAUDE_SKILL_DIR}/references/exemplar_discussion/ にある該当する研究タイプの例に目を通してください（同じ 5 つのタイプがあり、それぞれ、そのタイプで最もよく欠落する要素を示しています）。症例報告の場合は、代わりに ${CLAUDE_SKILL_DIR}/references/exemplar_case_report.md を使用してください（文献の範囲を示す表現、n=1 の因果関係に関する注意、ベッドサイドでの教育的ポイント）。

ステップ 5a：考察の計画（対話形式）

以下の質問をユーザーに尋ねてください。執筆を始める前に、回答を待ってください。

Q1. List the 3-5 key findings of this study in order of importance.
Q2. Name 3-5 key prior studies (anchor papers) you want to compare against in the
    Discussion — titles or DOIs.
    - Studies consistent with your results: ?
    - Studies inconsistent with your results: ?
Q3. Are there methodological or population differences that could explain any disagreement?
Q4. State up to 3 limitations of this study.
    (For each, include how it was mitigated and the direction in which it could affect the results.)
Q5. Are there clinical implications you want to emphasize?

ユーザーの回答が一部のみの場合は、得られた情報を使って進め、不足している点を明記してください。 ユーザーが「skip」と言った場合は、/search-lit を使って参考文献リストから基準となる論文を特定し、可能な範囲で妥当なデフォルトを用いて進めてください。

ゲート： ユーザーから回答がある（または明示的にスキップする）まで、考察の執筆を始めないでください。 自律モード： 対話形式の計画をスキップし、「skip」の手順に従ってください。

ステップ 5b：考察の執筆

逆ファネル型で記述してください。

1. 要約（1 段落）：結果からつなげる形で主要な知見を言い換え、数値をそのまま繰り返さないでください。
2. 基準となる論文との比較（2～3 段落、各段落で 1 つのテーマまたは知見を扱う）：各基準論文について、引用を付して先行研究の知見を述べ、自分たちの結果が一致するかを示し、方法論または対象集団の違いによって不一致が生じた理由を説明してください。
3. 臨床的意義（1 段落）：診療または今後の研究にとって何を意味するかを述べてください。
4. 限界（1 段落、重大なものから順に）：各限界について、（a）何が限界なのか、（b）どのように軽減したのか、（c）残存するバイアスの方向を述べてください。「本研究にはいくつかの限界があります」で始めないでください。
5. 強み（任意、1～2 文）：真に新規性のある貢献に限って記述してください。
6. 結論（1～2 文）：最も重要な知見とその意義を、引用可能な記述として示してください。最後の文を「さらなる研究が必要です」としないでください。

ルール：

• 結果に示されていないデータを持ち込まないでください。エビデンスの水準に合わせた表現を用い、主要な知見について別の説明可能性も認めてください。
• エンドポイントと結論の範囲の一致。 臨床的意義と結論の文は、研究デザインおよびエンドポイントが裏付ける範囲を超えてはなりません。横断研究／単回受診／有病率研究では、予後やサーベイランスに関する主張（再スクリーニング間隔、疾患の進行、将来リスクの予測）はできません。これらには縦断的な追跡が必要です。二値の代理エンドポイント（有無、>0、二分化）は、リスク層別化であって、患者ケアに関する指示（治療の延期／保留／開始）ではありません。/self-review §D（check_scope_coherence.py）は CROSS_SECTIONAL_PROGNOSTIC／SURROGATE_CARE_DIRECTIVE を検出します。結論で用いる動詞は、研究デザインが裏付ける範囲内にとどめてください。

初稿の後、ユーザーに、基準となる論文や比較に不足がないか、解釈を変更する必要があるか、どの臨床的意義を強調または弱めるべきかを尋ねてください。フィードバックを反映した後、批評・修正のループを実行してください。

フェーズ 6：序論＋抄録

論文の枠組みを示し、実際に何が明らかになったかを把握してから書く必要があるため、これらは最後に書きます。

執筆前： ${CLAUDE_SKILL_DIR}/references/section_guides/introduction.md と ${CLAUDE_SKILL_DIR}/references/section_guides/title_abstract.md を読み込み、構成モデル ${CLAUDE_SKILL_DIR}/references/exemplar_introduction.md と ${CLAUDE_SKILL_DIR}/references/exemplar_abstract.md に目を通します。症例報告では、IMRAD 抄録モデルではなく、150 語の序論／症例提示／結論という抄録構成の例として ${CLAUDE_SKILL_DIR}/references/exemplar_case_report.md を使用します。

序論（3～4 段落）： 重要性を示す臨床的背景（有病率、負担、現在の診療）→ 本研究が取り組む知識のギャップ → 正確に述べた研究目的（該当する場合は仮説も含む）。AI／LLM 抽出研究では、モデルが機能した場合に変わる臨床または研究のワークフロー上の手順を示し、抽出されたラベルに興味深い点があるという説明だけにとどめず、意思決定への影響経路を明記します。

抄録： 単独で内容が理解できるようにし、すべての数値を本文および表と一致させます。最後の文は臨床的な意義を述べるものとし、「さらなる研究が必要です」とはしません。 最大の効果ではなく、事前に規定した主要推定対象から書き始めます — 批評者やピアシムの実行結果が、最も強い数値を前面に出すよう提案した場合も同様です。効果量の表現を簡潔にするのは問題ありませんが、副次的、探索的、または事後解析による推定値を見出しに格上げするのは、推定対象の選び直しに当たります。抄録の主要結果には、登録またはプロトコルで規定された主要対比、つまりステップ 7.3b で確認するものを使う必要があります。主要結果が帰無または検出力不足の場合は、より都合のよい副次推定値に置き換えず、そのように報告します（/self-review のカテゴリー C、検出力を考慮した帰無結果を参照）。

プロセス： 批評者と修正者の反復ループ。

---

フェーズ 7：仕上げ

最終的な品質確認です。厳密に順番どおりに実行してください。次のステップを開始する前に、各ステップを必ず完了する必要があります。 HALT が発生するたびにパイプラインを停止します。いずれも単なる参考情報ではありません。

7.1 — AI パターンのスキャン。 AI による執筆パターン（下記の「AI パターン回避」を参照）を取り除き、manuscript/manuscript.md を直接編集します。次に、決定論的なクラシカルスタイルのリンターを実行します。 python3 "${CLAUDE_SKILL_DIR}/../self-review/scripts/check_classical_style.py" --manuscript manuscript/manuscript.md --strict. MA／システマティックレビューの場合、または上級共著者によるレビューが想定される場合は、references/section_guides/step7_1_classical_qc.md の 7 つの grep チェックリストも実施します。本文のパターン 19～21 の書き換え（§、自己言及、AI 開示の定型文）は /humanize に回します。

HALT — AI 開示のメタ適用性。 AI／LLM 使用の開示自体も、原稿が批評する項目（FLAIR F1.6、TRIPOD-LLM、MI-CLEAR-LLM）を満たす必要があります。バージョン、アクセス経路、対象期間、責任者を記載し、[version]／TODO のプレースホルダーを一切残さないでください。論文は、自身が批評する枠組みの項目に違反してはなりません。（クラシカルな記載箇所：本文ではなくタイトルページ。）

7.2 — 報告ガイドラインの確認。 /check-reporting を呼び出します。fixable_by_ai が true の MISSING 項目のみ自動挿入します。外部情報を必要とする項目（IRB／登録番号など）を作り出してはいけません。挿入した項目はすべて qc/_pipeline_log.md に記録します。

7.3 — 引用文献の検証。 最初にプレースホルダーのゲートを確認します — grep -nE '\[@NEW:[^]]+\]' manuscript/index.qmd manuscript/manuscript.md で該当が見つかった場合は必ず停止し、/search-lit → /lit-sync に戻ります。続いて /verify-refs を実行し、qc/reference_audit.json を解析します。submission_safe: false の場合はパイプラインを停止し、すべての FABRICATED／MISMATCH と duplicate_findings[] を明示します。 7.3a / 7.3b / 7.3c — 整合性監査。 7.3 と 7.4 の間に 3 つすべてを実行します。それぞれ HALT を発生させて 7.4a に振り分ける場合があります。7.3a 数値の主張（本文 ↔ 表 ↔ 抽出 CSV、および一次情報源の確認。方向の逆転、または p<0.05↔p≥0.05 の境界越えは P0 ブロッカーです）。7.3b 推定対象の来歴（/self-review 2.5f に委譲します。PRIMARY_REASSIGNED、EVALUE_ARITHMETIC、EVALUE_NON_PRIMARY は P0 です）。7.3c 参考文献の妥当性（名称が挙がっている方法はすべて引用します。/search-lit → /lit-sync → /verify-refs --strict で解決し、決して捏造しないでください）。phase7_integrity_audits.md を参照してください。

7.4 — セルフレビューと修正ループ。 /self-review --json --fix を呼び出します。レビューを実施し、fixable_by_ai の編集を適用して再レビューします（最大 2 回の反復）。PASS になった場合はそこで終了します。スコア、判定、反復回数、残存する問題を記録します。severity: "fatal" の問題が 1 つでも残る場合は 7.4a に進み、7.5 には進まないでください。

7.4a — 監査リカバリーブランチ。 問題が構造的なもの、つまりデータ、プロトコル、または分析スクリプトに誤りがある場合、文章を磨いても、壊れた土台の上に整った原稿ができるだけです。 本文中のテキストを直接修正することは禁止です。リカバリーでは、再抽出、再分析、または再登録を行います。7.5〜7.6 を中断し、このブランチを記録して、振り分け先のスキルを呼び出し、7.3 から再開します。 ループの上限は 1 サイクルです。振り分け先は references/section_guides/step7_4a_audit_recovery.md です。

7.5 — 成果物の生成。 manuscript/manuscript.md、manuscript/title_page.md、qc/reporting_checklist.md、qc/self_review.md、qc/_pipeline_log.md を生成します。著者の所属に手作業で番号を振らないでください。scripts/build_title_page_affiliations.py --check title_page.md --strict を使って生成・検証します（Nature Portfolio / npj の技術チェック項目です）。

7.6 — DOCX のビルド。 analysis/figures/_figure_manifest.md から図を埋め込み、その後レンダリングします。参考文献が 5 件を超える投稿では、/manage-refs（pandoc + citeproc + journal CSL）を優先し、参考文献リストを手入力しないでください。

7.6a — 相互参照の QC。 ビルド後、最終ゲートの前に実行します。

python3 "${CLAUDE_SKILL_DIR}/../manage-refs/scripts/check_xref.py" \
  --md manuscript/manuscript.md --docx manuscript/manuscript_final.docx \
  --out qc/xref_audit.json --strict

本文中の引用が誤ったレンダリング済みキャプションに対応している場合に検出します。MISSING_DOCX／MISSING_BODY／MISMATCH のいずれかがあれば、submission_safe: false となり、終了コード 1 で HALT します。本文のキャプションが SSOT です。ビルドパイプラインを修正し、逆の修正は決して行わないでください。

7.7 — 最終ゲート。 自律実行の場合：完了を記録し、語数、図の数、セルフレビューのスコア、報告基準への準拠率、FATAL フラグを報告します。対話型の場合：概要を提示し、確認を待ちます。

ファイル	読むタイミング
references/phase7_polish_detail.md	ビルド手順（7.5〜7.6a）に進んだとき、HALT が発生したとき、または原稿に AI 開示の段落があるとき
references/phase7_integrity_audits.md	7.3a / 7.3b / 7.3c を実行するとき
references/section_guides/step7_4a_audit_recovery.md	7.4 で致命的な問題が見つかったとき

---

フェーズ 8 以降（任意）：カバーレターの生成

ユーザーが明示的にカバーレターを求めた場合（たとえば /find-journal で投稿先を選んだ後）のみ実行し、自動では生成しません。必要な入力の確認事項、レターの構成、査読者と COI の照合（メタ分析では必須）、過剰な主張を防ぐためのガードについて、${CLAUDE_SKILL_DIR}/references/phase8_cover_letter.md を読んでください。

---

査読者の評価基準

フェーズ3～6では、それぞれ執筆者→査読者→修正者の順に作業します。セクションの草稿を作成し、査読者が行単位のフィードバックとともにレビューし、修正して、最大3ラウンドまで繰り返します。3ラウンドを経ても合格しない場合は、最善の版を残っている問題の一覧とともにユーザーに提示し、指示を求めます。

査読者は、行単位のフィードバックを付けて次の6つの観点を評価します。正確性（すべての主張がデータや表と一致しているか、効果の方向が正しいか）、完全性（報告ガイドラインの全項目と小節が含まれているか）、明瞭さ（一読で理解できるか、指示対象が曖昧でないか）、簡潔さ（不要な記述や重複する曖昧表現がなく、語数の上限を守っているか）、報告要件（このセクションに関するSTARD／TRIPOD／CLAIMなどの項目に対応しているか）、人間らしさ（AIパターン回避の基準に抵触していないか）。学術誌の査読者が問題視するような指摘がどの観点にもなければ、そのセクションは合格です。そうでなければ、修正ラウンドを実施します。

**セクションの境界（フェーズ4、5の合否判定）：**結果では、解釈、「なぜ」の説明、先行研究への言及、数値を伴わない評価的な形容詞を含めてはいけません。考察では、結果にないデータや、エビデンスの水準を超える過剰な主張を含めてはいけません。査読者は違反する文をすべて指摘しなければならず、修正者がその文を移動または書き換えるまで、セクションは合格になりません。

各ラウンドは ## Critic Report: {Section} -- Round {N} の形式で報告し、優先度順に次の形式で問題を記載します：[観点] 箇所：問題 -> 修正案。最後に Verdict: PASS | REVISE と記載します。

---

原稿執筆ルール

• 文章のみで記述します。 原稿の各セクション（方法、結果、考察、序論）では、箇条書きや番号付きリストを絶対に使用しないでください。箇条書きが認められるのは、学術誌の書式で必要とされる場合の構造化抄録のみです。
• 文体と時制。 能動態を優先します（「私たちは分析した」ではなく、「分析が実施された」とするのではなく）。受動態は、エージェントが本当に関係しない場合に限って使用します。方法と結果は過去形、考察と序論は確立された事実には現在形、研究固有の知見には過去形を使用します。抄録は、記述するセクションの時制に合わせます。
• 数値。 本文の数値はすべて、対応する表のセルと完全に一致させ、異なる丸め方をしてはいけません。割合も一致させます。例：150人中23人の場合は「23（15.3%）」と記載し、計算を確認してください。すべての主要評価項目について、効果量と95%信頼区間を報告してください。p < 0.001の場合を除き、しきい値（p < 0.05）ではなく正確なp値（p = 0.032）を報告してください。
• 臨床上の定義、診断基準、ガイドラインの推奨事項を決して捏造しないでください。 確信が持てない場合は、[VERIFY] と記してユーザーに確認してください。
• 学術誌の要件への準拠。 読み込まれた学術誌のプロファイルに記載された語数制限を守ってください（セクションの草稿が上限を超えた場合は、超過分を報告し、具体的な削減案を提示してください）。構造化抄録の形式を正確に守り、学術誌固有の必須項目（例：AJRの「Key Points」、RYAIのAI研究におけるCLAIMチェックリスト）を含めてください。

AI パターンの回避

原稿には、AI生成と判定されやすい次のパターンを含めないでください。

禁止表現：「In conclusion」（「In summary」に置き換えるか、別の表現にしてください） · 「It is worth noting that」 · 「It is important to note that」 · 「Notably,」 · 「Interestingly,」 · 「Importantly,」 · 文頭の「Furthermore,」 または「Moreover,」（「In addition,」に置き換えるか、文の構成を変えてください） · 「plays a crucial role」 · 「a comprehensive analysis」 · 「delve into」 · 「leverage」（「use」または「apply」に置き換える） · 「utilize」（ 「use」に置き換える） · 「in the realm of」 · 「underscores the importance of」 · 「sheds light on」 · 「paves the way for」 · 「a nuanced understanding」 · 「the landscape of」 · 「a paradigm shift」 · 「robust」（ 統計手法を表す場合を除く）。

禁止する構成パターン： 3項目を並べる文（段落をまたいで「X, Y, and Z」を繰り返すこと）、過度に慎重な表現の連鎖（「may potentially be associated with possible」など）、異なる内容に同じひな型を当てはめた対称的な段落、壮大ぶった書き出し（「In the rapidly evolving landscape of...」など）。

代わりに： 文の構成や長さに変化をつけ、具体的で明確な表現を優先し、データそのものを示してください。「モデルは目覚ましい性能を示しました」ではなく、「AUCは0.92でした」とします。

再開

ユーザーが作業途中の原稿に戻ってきた場合は、ワークスペースに既存の草稿があるかを確認し、最後に完了したフェーズを特定して、進捗を要約したうえで、どこから再開するかをユーザーに尋ねてください。

---

LLMによる執筆の開示

有効な場合（デフォルト）、このスキルはICMJEの勧告とCOPEに準拠した透明性に関する記述を生成します。ICMJEや主要な学術誌がAIによる執筆支援の開示を求めており、開示しないと却下や撤回のリスクがあるため、デフォルトで有効になっています。開示方針のない学術誌の場合、またはLLMによる支援が最小限だった場合は、--no-llm-disclosure で無効にできます。

開示の掲載箇所

開示をどこに記載するかは投稿先の学術誌によって異なり、学術誌ごとに方針が異なります。Methodsを求める学術誌もあれば、Acknowledgments、カバーレター、タイトルページ、投稿フォームのみを求める学術誌もあります。読み込んだ学術誌プロフィール（以下の学術誌ごとの上書き設定）に記載された場所を使い、その学術誌が指定する場所のテンプレートのみを使用してください。投稿先の学術誌が記録されていない場合は、ICMJEに従い、執筆支援についてはAcknowledgments、データ収集・分析・図表作成での使用についてはMethods、どちらの場合もカバーレターに記載します。ただし、掲載箇所は未確認として扱います。Phase 7.1 のチェック（check_classical_style.py、INBODY_AI_DISCLOSURE）では、投稿先が設定されるまではMinor項目として報告され、投稿先が本文中での開示を認めていない場合はMajor項目として報告されます。

著者が行ったこと（確認、検証、承認、およびツールを使用しなかった用途）についての記述は、著者自身が作成する必要があります。[TODO authors confirm: …] マーカー内に記述し、著者が解決できるようマーカーを残してください。TODO、未入力のテンプレート項目（[tool]、[version]、[developer]、[Claude/tool name]、[Journal Name]、[statistician/author]、{version} など）、または [VERIFY…] や [UNVERIFIED - NEEDS MANUAL CHECK] マーカーが残っている間は、check_placeholders.py によって投稿がブロックされます。

1. Methodsセクション — 最終段落

投稿先の学術誌がMethodsでの記載を求めている場合は、倫理に関する記述の後、Methodsセクションの末尾に記載してください。

テンプレート（詳細に合わせて調整してください）：

[AI-Assisted Writing Disclosure]
An artificial intelligence language model ([tool] [version], [developer]) was used to assist
with [tasks actually performed, e.g. structuring sections, refining prose, checking the
internal consistency of reported statistics]. [TODO authors confirm: All content was
critically reviewed, verified against source data, and approved by all authors. The tool was
not involved in study design, data collection, data analysis, or interpretation of results.]

カスタマイズのルール：

• [tool] [version], [developer] を、実際に使用したツール名に置き換えます。
• LLMが実行した具体的なタスク（草稿の作成、編集、文献検索、統計コードの作成など）を列挙します。
• LLMをデータ分析にも使用した場合（例：/analyze-stats による統計コードの生成）は、その旨を明記します。「統計分析コードの生成にも使用し、そのコードは[統計担当者／著者]が確認および検証しました。」
• 2～3文にまとめ、詳しく説明しすぎないでください。

2. Acknowledgmentsセクション

テンプレート：

The authors acknowledge the use of [Claude/tool name] ([Anthropic/developer]) for
writing assistance in preparing this manuscript. The authors retain full responsibility
for the content.

3. カバーレター — AI開示の段落（Phase 8以降）

テンプレート：

In accordance with [Journal Name]'s policy on AI-assisted writing, we disclose that
[tool] [version] was used to assist with manuscript preparation, specifically
[list tasks: drafting, language editing, statistical code review]. [TODO authors confirm:
All authors have reviewed and take responsibility for the final content. The AI tool was
not listed as an author and did not contribute to study conception, design, or data
interpretation.]

開示してはいけない内容

• 文法チェッカー（Grammarly、Word のスペルチェック）の通常の使用は開示しないでください。現在の ICMJE の指針では、これらは生成 AI とはみなされません。
• LLM が分析コードを生成した場合を除き、文献管理ツール（Zotero、EndNote）や統計ソフトウェア（R、Python）の使用は開示しないでください。

ジャーナル固有の上書き設定

フェーズ 0 でジャーナルプロファイルが読み込まれたら、プロファイル内の ## AI Writing Disclosure Policy セクションを確認してください。構造化フィールドである Requirement level（Required / Recommended / Not specified）、Permitted scope（All tasks / Language editing only / Not permitted）、Disclosure location（Methods / Acknowledgments / Cover letter / Submission form）、AI-generated images（Allowed / Banned / Not specified）、Policy URL に基づき、開示文言が自動的に設定されます。主な既知のポリシーは次のとおりです。

• Radiology/RSNA：必須、言語編集のみ、Methods + Acknowledgments、AI 画像は禁止。
• RYAI/RSNA：必須、言語編集のみ、Methods + Acknowledgments、AI 画像は禁止。
• JAMA/AMA：必須、言語編集のみ、Methods + Cover letter。
• Lancet：必須、言語編集のみ（「読みやすさと言語」）、Acknowledgments + プロンプトの開示が必要。
• BMJ：必須。すべてのタスクで使用できますが、開示が必要です。Methods + Acknowledgments。テキスト、画像、データ、図に適用されます。
• Nature/Springer Nature：必須、言語編集のみ、Methods、AI 画像は禁止。
• Science/AAAS：最も制限が厳しいポリシーです。LLM の使用は制限されており、開示がない場合は不正行為とみなされる可能性があります。

読み込まれたジャーナルプロファイルに AI Writing Disclosure Policy セクションがない場合は、Disclosure Locations に記載されている ICMJE の配置に従ってください。ICMJE は開示を義務付けていますが、AI の用途は制限していません。そのため、使用範囲の制限についてはジャーナルのポリシーに従ってください。

---

ゲート

重大度：ENFORCED ＝失敗するとパイプラインが停止します（次のフェーズに進めません）。ADVISORY ＝警告が記録され、ユーザーは上書きできます。OPT-IN ＝明示的に呼び出された場合にのみ実行されます。

フェーズ	ゲート	重大度	トリガー	失敗時のアクション
0	背骨となる論文の自動提案（フェーズ 0「背骨となる論文を特定する」アクション）	ADVISORY	refs.bib に方法論が類似する候補がある	ユーザーに提示し、ユーザーが承諾または辞退
7.0	引用キーの解決（/manage-refs scripts/check_citation_keys.py に委任）	ENFORCED	UNDEFINED キーが存在する	停止し、/lit-sync で解決してから再実行
7.0	[@NEW:topic] の解消（/manage-refs に委任。check_citation_keys.py はこれらを UNDEFINED として報告し、終了コード 1 を返す）	7.6 の開始時に ENFORCED	[@NEW:topic] マーカーが残っている	DOCX をレンダリングする前に、それぞれを解決
7.1	古典的スタイルの QC（check_classical_style.py）	ENFORCED	§ セクションへの相互参照。本文中の AI に関する開示は、対象の配置が判明している場合（--profile または --disclosure-placement）にのみ停止の対象となります。上記の 7.1 の呼び出しではどちらも渡されないため、Minor として報告され、停止しません。散文中の全角ダッシュが 25 個を超える場合も Minor として報告され、停止しません	自動修正するか、上級 MA レビュアーによる準備のために HALT
7.2	報告ガイドラインへの準拠（/check-reporting）	投稿時に ENFORCED	必須項目の充足率が 100% 未満	MISSING を自動修正し、部分的な場合は ADVISORY
7.3	参考文献の監査（/verify-refs --strict）	ENFORCED	submission_safe: false（FABRICATED または MISMATCH の行がある、あるいは duplicate_findings[] が空でない）、またはいずれかの UNVERIFIED 行（これらも --strict で終了コード 1 を返す）	停止し、Zotero で修正して、/lit-sync で refs.bib を再レンダリング
7.4	自己レビューの修正ループ（/self-review --json --fix）	ENFORCED	2 回の反復後もスコアがしきい値を下回る	ステップ 7.4a の監査リカバリーに移行
7.4a	監査リカバリー分岐（MA 原稿の場合は /meta-analysis フェーズ 10 に移行）	--e2e では ENFORCED	自己レビューで構造上のデータ問題が見つかった	リカバリー検証が 2 回失敗した場合は RECOVERY_HALT_HUMAN_DECISION で HALT
7.5	人間らしさの密度（/humanize）	ADVISORY	AI パターンが 1000 語あたり 2.0 を超える	一通り修正し、残りにフラグを付ける。ユーザーがレビュー
7.5a	AIO チェックリスト（/academic-aio --aio） — /humanize の後に実行します。投稿と併せてプレプリント／GitHub README／CITATION.cff／HF カードを準備する場合にも実行します。決して黙って実行しないでください。academic-aio のコミュニケーションルールで禁止されています。	OPT-IN	ユーザーが --aio フラグを指定	PASS/PARTIAL/FAIL レポートを出力し、自動適用は行いません
7.6	DOCX のビルド（/manage-refs scripts/render_pandoc.sh に委任）	ENFORCED	レンダリングの終了コードが 0 以外	停止し、stderr をユーザーに報告
7.6a	相互参照の QC（/manage-refs scripts/check_xref.py --strict に委任）	ENFORCED — 投稿ゲート	MISSING_DOCX / MISSING_BODY / MISMATCH が 0 より大きい（--allow-separate-attachments の場合：MISMATCH、または float が DOCX 内にある MISSING_BODY）	停止し、references/phase7_polish_detail.md に従って修正に移行
7.7	最終投稿ゲート	ENFORCED	上記 7.0～7.6a のいずれかが失敗	submission_safe: true としてマークすることを拒否
8+	カバーレターの生成	OPT-IN	ユーザーが --cover-letter を呼び出す	ジャーナルのプロファイルに合わせてレンダリング