paper-writing

論文執筆スキル

このスキルの仕組み

このスキルには、カリフォルニア大学サンタバーバラ校の Systems and Networking Lab（SNL） の執筆手法が組み込まれています。6本の論文（投稿8回）、7,600件を超える Overleaf の編集、100を超える tex ファイルのバージョン、5回の査読プロセスを詳細に分析して導き出したものです。分析の全文は、論文の背後にある論文をご覧ください。このスキルはすぐに使えます。デフォルトのルールは調整済みで、実証を重ねたものです。

3つのレイヤー

1. パイプライン（固定）：5段階の執筆ワークフローです。ユーザーや論文が変わっても変わりません。

2. 文体と編集ルール（デフォルトを提供、カスタマイズ可能）：文単位の文体、構成ルール、文章の圧縮パターン、セクションごとのチェックリストです。SNL ラボのルールがデフォルトとして含まれています。学生は author_profile/ 内のファイルを編集してカスタマイズできます。変更する内容については README をご覧ください。

3. プロジェクトのコンテキスト（論文ごと）：論文を定義する一文、投稿先、貢献に関する主張、確定済みの決定事項です。論文の作業ディレクトリにある project_context.md に記録します。

このスキルと研究パイプラインのつながり

このスキルは単独で動作するものではありません。3つのスキルで構成されるファミリーの一部であり、ほかの2つのスキルで作成した成果物は、執筆プロセスへの直接的な入力となります。

literature-survey-skill から：

• ギャップ分析 → ブレインストーミングのフェーズ1（問題の発見）に反映されます。サーベイで特定したギャップ、すなわち欠けている象限、破綻する共通の前提、未調査の組み合わせは、論文の動機となる構造的な限界です。
• 執筆技法の抽出（パス3以降） → アーキテクチャ段階と各セクションの執筆に反映されます。研究分野の優れた論文から抽出した序論の構成、評価の構成、設計上の工夫が、自分の論文の構成モデルとなります。
• 競争上の位置づけ → ブレインストーミングのフェーズ4に反映されます。統合によって作成した不変条件マトリックスと依存関係グラフから、既存研究に対する自分の論文の位置づけが明確になります。

data-visualization-skill から：

• 探索（exploration_log.md） → ブレインストーミングのフェーズ3（評価設計）に反映されます。探索では、仮説を立てる前に、複数の視点からデータを見ることになります。予想外の分布や、異なる振る舞いを示すサブグループなど、見つかった意外な点は、どの主張が正当化できるか、真の貢献がどこにあるかを形作ります。
• ブレインストーミング（braindump.md） → 図表の計画に反映されます。各ブレインダンプでは、図が答える問い、予想していた結果、意外に感じる結果を明確にします。これらは、評価で検証すべき仮説です。
• 計画と実行（plot_context.md） → アーキテクチャ段階の図表計画に反映されます。各 plot_context には、意図、変数の対応関係、プロット形式の選択理由、設計上の決定事項が記録されており、論文の図表計画にそのまま記載できます。
• 分析（WALTER のナレーション） → 評価のムーブ4（要点の統合）に反映されます。WALTER の結果にある「要点は何か。仮説とのつながりはあるか」という問いは、その実験群の要点をまとめる段落の初稿となります。

この3つのスキルは閉じたループを形成します。文献サーベイではギャップを明らかにし、採択論文でどのように伝えるかを学びます。データの可視化では、証拠が実際に何を示しているか、どの仮説を検証できるかを理解します。論文執筆では、その両方を出版可能な論旨にまとめます。学生がほかのスキルで作成した成果物を持っている場合、Claude は必ず読み込まなければなりません。

このスキルが起動した場合、Claude は必ず次のことを行います：

1. この SKILL.md を読みます（すでに読み込み済み）
2. author_profile/ 内のすべてのファイルを読みます。これらは編集ルールの一次情報です
3. ユーザーが取り組んでいる論文を尋ねます
4. 論文の作業ディレクトリで project_context.md を探します
5. 見つかった場合は読み込み、拘束力のある制約として扱います
6. 見つからない場合は、以下の構造化ブレインストーミングのワークフローを実行して作成します
7. 関連するスキルの成果物を確認します。craft の抽出を含むサーベイ論文のメモ、exploration_log.md、braindump.md、plot_context.md、WALTER のナレーションを確認してください。見つかった場合は、該当するパイプライン段階の参考資料として読み込みます

---

構造化ブレインストーミング — このスキルの中心

学生にとって最大の障害は、文章を書くことではありません。自分のアイデアが、構造化されていない直感のままになっていることです。 何かがおもしろいことは分かっていても、それがなぜ、どのようにおもしろいのかを言葉にできません。ブレインストーミングのプロセスでは、散らばった考えを、論文の各セクションの指針となる明確なプロジェクトコンテキストへと整理します。

仕組み

Claude は必ず brainstorming_guide.md を読み、6 つのフェーズをインタラクティブに進めます。各フェーズは次のとおりです。

フェーズ	焦点	主な成果
1. 問題の発見	誰が困っているのか、何が機能しなくなるのか、構造的に機能しなくなる理由	冒頭段落で示す重要性と問題のギャップ
2. 貢献の明確化	中心的な主張、見出しとなる数値、主要な抽象化の名称	アイデンティティを示す一文と貢献の一覧
3. 評価の設計	ベースライン、指標、データセット、実験と主張の対応付け	序論で約束できる内容を制約する評価計画
4. 位置付けと枠組み	投稿先との適合性、競争上の位置付け、新たなカテゴリの創出と競争のどちらか	関連研究での位置付けを示す一文
5. アーキテクチャと制約	設計パイプライン、確定済みの決定、未解決の質問	設計セクションの構成とプロジェクトの範囲
6. ナラティブの軸	ストーリーの展開、「必然」と感じる瞬間、ツイートの長さに収まる提案文	各セクションをつなぐ筋道

ブレインストーミングを進める際のルール

• フェーズごとに進めてください。 先に進みすぎないでください。フェーズ 1（問題）が明確になって初めて、フェーズ 2（貢献）の意味が明確になります。
• 「分かりません」も有効な回答です。 未解決の質問として記録し、先に進んでください。今見つかったギャップは低コストで修正できますが、査読中に見つかったギャップの修正には大きなコストがかかります。
• 曖昧な回答には、具体性を求めてください。 「より高速です」→「誰にとって高速ですか？ どの程度ですか？ どのワークロードでですか？」すべての回答は、論文に記載できるだけ具体的であるべきです。
• 構造的なギャップと定量的なギャップを区別してください。 「既存のツールは十分に正確ではありません」は定量的な問題であり、実験の追加が必要になります。「既存のツールは定常性を前提としており、バースト性のあるデータではその前提が成り立ちません」は構造的な問題であり、新しいアプローチの必要性を示します。論文には構造的なギャップが必要です。
• すべてのフェーズが終わったら、examples/project_context.md のテンプレートを使って project_context.md を生成してください。 完成したプロジェクトコンテキストの実例については、examples/netburst_project_context.md を参照してください。

音声と編集のルール

Claude は、このスキルのディレクトリにある以下のファイルを必ず読み込んでください。詳細なルールと例が記載されています。

ファイル	対象
author_profile/editorial_principles.md	証拠を伴う、論文全体に適用される14の原則（導入での二度の紹介、曖昧な表現より固有名詞を優先すること、「何を→なぜ→それが何を意味するか」の見出し、展開してから圧縮することなど）
author_profile/craft_reference.md	書き方（ポジティブな指針）。 文単位のスタイル（平均約21語、主張を先に述べる、能動態、曖昧な表現より固有名詞を優先する、無駄を省く）、構成の技法、3つの文体（基本／簡潔、概念／立場、親しみやすさ／物語）。段落を執筆するときに参照してください。
author_profile/gate_mechanical.md	唯一の機械的な grep ゲート（M1～M18）。 ダッシュ、対句法、強調語、禁止語・大げさな語・凝った動詞、前置き、受動態、冗長な表現、限定表現、用語の揺れを、1つの grep スクリプトで検出します。tex を編集するたびに実行してください。受動態のスキャンは基本ゲートでも実行します。
author_profile/gate_semantic.md	唯一の読者判断ゲート（S1～S31）。 使用前の定義、追いやすさ、構文の理解しやすさ、論旨との結び付き、語彙と分解の一貫性、重複の排除、厳密さと根拠、誠実な位置付け、図、そして結びのゲートを確認します。レッドチーム／ループのパスで実行します。
author_profile/compression_patterns.md	圧縮の7つの手法と、圧縮前後の例および定量的な基準
author_profile/rhetorical_moves.md	セクションをまたいで用いる展開パターン（導入：6つ、設計：5つ、評価：6つ、関連研究：3つ）
author_profile/intervention_types.md	アドバイザーによる介入の7つの種類。草稿へのアドバイザーのフィードバックをシミュレートするときに使用します。
red_team_protocol.md	独立した敵対的レッドチームレビュー（証拠ゲート付き）：機械的監査の後、文章を執筆していないレビュアーが gate_mechanical.md を再実行し、gate_semantic.md を適用します。文章を公開する前に、必ず CLEAN の判定を得てください。
loop_mode.md	再開可能な /loop 監査・修正プロトコル。ディスクに記録する台帳を用い、1回の反復につき1つのセクションを処理し、問題がなくなると自動終了します。

クイックリファレンス：必ず守る文体ルール

以下は、上記の詳細ファイルから抜粋したものです。内容が矛盾する場合は、詳細ファイルを正とします。

• 文の平均長は約21語です。最大40語（貢献のリストのみ）です。
• トピックセンテンスでは主張を述べます。段落を背景や文脈から始めてはいけません。
• ぼかした表現は一切使いません。「私たちは示します」と書き、「私たちは考えます」とは書きません。「X は Y を13倍削減します」と書き、「X は Y の削減に役立つ可能性があります」とは書きません。
• 例外なく、常に能動態を使います。受動態は行為者を曖昧にし、文章を弱めます。
• 中身のない形容詞は使いません。「novel」「significant」「state-of-the-art」「comprehensive」「robust」「substantial」「promising」「impressive」は使わないでください。具体的な数値に置き換えるか、削除します。
• 主張によって読み手を導きます。セクションの冒頭では、「このセクションでは、X が Y を13倍削減することを示します」のように、そのセクションの結論を述べてもかまいません。ただし、「このセクションでは、〜について説明します」のように、内容を示さない定型句は使いません。確認の基準は、流し読みする読者にも冒頭文からセクションの結論が伝わるかどうかです。
• 感嘆符は使いません。導入以外では、修辞疑問文も使いません。
• 段落は4～6文で構成します。各段落の役割は、主張を述べる、証拠を示す、要点をまとめる、のいずれか1つだけです。
• 見出しはトピックではなく主張を表します。「実験結果」ではなく、「イベント中心の分解が誤差を13倍削減する」とします。
• 曖昧な表現より固有名詞を優先します。あらゆる仕組み、ベースライン、指標には固有の名前が必要です。分野内のどの論文にも当てはまる用語は、この論文では使いません。
• 図は単に参照するのではなく、解釈します。「図3は X を示しており、Y を裏付けています」と書き、「図3を参照してください」とは書きません。
• 評価の各サブセクションは、必ず「要点」の段落で締めくくります。
• 設計上の選択は、その直後に理由を示します。「X を使います」ではなく、「Y のため、X を使います」とします。

会場に合わせた調整

• システム系の会場（NSDI、SIGCOMM、CoNEXT、IMC）：\smartparagraph{} のラベルを使用します。システム評価（レイテンシ、スループット、メモリ）を行います。貢献は運用上の影響として位置づけます。関連研究は評価の後に置きます。
• ML系の会場（NeurIPS、ICLR、ICML）：\smartparagraph は使いません。コロン形式の小見出しを使用します。再現性チェックリストを用意します。手法の進歩として位置づけます。関連研究は本文に統合します。
• ワークショップ／ショートペーパー（HotNets、ANRW）：全体を50％に圧縮します。知的な問題提起を冒頭に置きます。

---

必須スタイル監査（ゲート — すべての tex 編集に適用）

新規または変更した tex コンテンツを提示またはコミットする前に、Claude は必ず文単位のスタイル監査を実行しなければなりません。 これは任意ではなく、ユーザーから指示された場合に限られるものでも、セクション全体の草稿だけに適用されるものでもありません。段落単位の変更、小節の追加、概要の書き直しを含む、すべての編集に適用されます。

監査では、変更したすべての文を author_profile/gate_mechanical.md、author_profile/compression_patterns.md、author_profile/craft_reference.md に照らして確認します。特に、以下をチェックして修正してください。

0. 機械的ゲート（gate_mechanical.md）— grep を使って最初に実行します。 ダッシュ（---、—、--）は禁止です。対句・対称表現（「X ではなく Y」、「何と呼ばれようと」）、論評的な締めくくり（「節約することが重要です」、「本物ではありません」）、空虚な強調表現（「実質的に」、「本質的には」）、三項並列による装飾、前置きだけの導入（「さらに」、「特筆すべきことに」）、禁止語・大げさな語・凝った語、内容のない書き出し（「本稿では、私たちは……」）は禁止です。平易で短い断定的な文体（craft_reference.md）を目指してください。そのファイルの grep ゲートを実行せずに、監査に合格したと報告してはいけません。
1. 否定から始める構文：「X ではない」や「X ではなく」のように、本来は何であるかを肯定的に述べるべき文を確認します。肯定的な表現に書き換えてください。
2. 前置きだけの表現：「この問題に対処するために」、「この問題に対処するには」、「〜するために」、「特筆すべき点は」、「注意してください」など。削除し、行動を示す表現から始めてください。
3. 曖昧な表現：「潜在的に可能性がある」、「期待できる」、「削減に役立つ可能性がある」、「〜の可能性がある」など。断定的な表現（「実現します」、「削減します」、「達成します」）に置き換えてください。
4. 一般的な形容詞：「重要な」、「大幅な」、「非常に望ましい」、「新規の」、「堅牢な」、「包括的な」など。具体的な数値に置き換えるか、削除してください。
5. 文の長さ：40 語を超える文に印を付けてください。分割するか、簡潔にしてください。
6. 受動態：「X によって精度が達成された」→「X が精度を達成します」。「X で実験が行われた」→「X で評価します」。例外なく、方法や評価を含めて、すべて能動態にしてください。この基本ゲートでは、受動態検出の grep（gate_mechanical.md §Part C、M11）を実行してください。該当箇所はすべて修正するか、使用理由を説明してください。
7. 引用の欠落：他のセクションの技術的主張を再掲する場合、引用も引き継いでください（原則 14）。

手順：執筆後、（a）gate_mechanical.md Part C の grep ゲートを実行し、該当箇所をすべて修正します。次に（b）変更箇所を一行ずつ読み、上記の項目を確認します。違反の種類と件数をまとめた表を報告してください。grep の件数（ダッシュ、対句・対称表現）も含め、「監査済み」とだけ報告してはいけません。監査を頭の中だけで済ませ、合格したと主張してはいけません。最後に（c）独立した敵対的レッドチーム監査（red_team_protocol.md）を実行します。執筆者ではないレビュー担当者が gate_mechanical.md を再実行し、author_profile/gate_semantic.md（定義より前の使用、追いやすさ、論旨との結び付き、語彙と構成の一貫性、重複の有無、対応付けの可能性、誠実な位置付け、締めくくりのゲート）を初見の読者の視点から適用し、可否だけでなく指摘事項の一覧を返します。（a）＋（b）＋（c）を通過し、grep の出力を根拠として貼り付けたテキストのみを提示またはコミットできます。gate_semantic.md の締めくくりのゲート（S31）に従い、最終レビュー担当者が重大度 CRITICAL または MAJOR の指摘をゼロとするまで、内容に実質的な変更を加えるたびにレッドチーム監査を繰り返してください。残った項目を「完了」として先送りしてはいけません。

このゲートは、以下の構成に関するチェックリストとは別個に、追加で適用されます。

ループモード。 /loop 経由で呼び出された場合（例：「論文執筆スキルを反復適用する」、「ループで監査する」）、loop_mode.md に従ってください。監査 → レッドチーム監査 → 修正のサイクルを台帳で追跡し、再開可能な形で実施します。各反復では 1 セクションずつ処理し、対象範囲のすべてのセクションが問題のない状態になったら自動的に停止します。実行するチェックや停止のタイミングをユーザーが指定する必要はありません。プロトコルがそれらを定めます。

セクションのチェックリスト

セクションの草稿を生成した後は必ず、対応する構成チェックリストも読み、実行してください。

セクション	チェックリストファイル
Introduction	writing_checklists/intro_questions.md
Evaluation	writing_checklists/evaluation_questions.md
Design / Method	writing_checklists/design_questions.md
Related Work	writing_checklists/related_work_questions.md

草稿を提示する前に、すべての違反を指摘してください。重大度は次のとおりです。CRITICAL（構成上の問題 — 却下につながります）、MAJOR（査読者に明らかな問題）、MINOR（仕上げレベルの問題）。

セクションの修辞的な展開

各セクションの種類における展開の順序について詳しくは、section_rhetorical_moves/ を参照してください。

セクション	ファイル	主要な展開
Introduction	section_rhetorical_moves/introduction.md	重要性 → 問題の空白 → 主要な抽象化 → 設計の直感 → 貢献 → 結果の概要
Evaluation	section_rhetorical_moves/evaluation.md	設定の説明 → 直接比較 → 詳細分析 → 要点の統合 → アブレーション → 堅牢性
Design	section_rhetorical_moves/design.md	抽象化の導入 → 設計の正当化 → コンポーネントのアーキテクチャ → 主要な設計判断 → 堅牢性
Related Work	section_rhetorical_moves/related_work.md	カテゴリごとの分類 → カテゴリごとの限界 → 位置づけを示す文

ここには、採択・却下されたシステムおよびML論文から得られた、効果的な例とそうでない例を含む、実践的なガイダンスが記載されています。

---

5段階のパイプライン

各論文は、以下の段階を順番に進みます。Claude はユーザーがどの段階にいるかを特定し、その段階のルールを適用します。

Stage 1: 構造化ブレインストーミング → プロジェクトコンテキストの作成

ゲート：ユーザーは、1文のアイデンティティステートメントと、結果として記述された貢献の主張を用意している必要があります。用意できていない場合は、brainstorming_guide.md を読み、6つのフェーズすべてを対話形式で進めてください。急がないでください。これは最も重要な段階です。プロジェクトコンテキストが曖昧だと、論文も曖昧になります。

ブレインストーミングの後、examples/project_context.md のテンプレートを使って project_context.md ファイルを生成し、論文の作業ディレクトリに保存してください。実例については、examples/netburst_project_context.md を参照してください。

重要： project_context.md の作成後、このファイルをプロジェクトの .gitignore に追加してください（ファイルが存在しない場合は作成してください）。このファイルには戦略的な位置づけに関するメモやアドバイザーのコメントが含まれているため、共有リポジトリにデフォルトでコミットしてはいけません。

Stage 2: アーキテクチャ

ゲート：セクションの概要。主張の割り当て、セクションごとのストーリー展開、図表の計画、評価の構成、ページ数の配分を含めます。

執筆技法の参考資料：学生が文献調査を実施している場合（literature-survey-skillを使用、または手動で実施）、執筆技法の抽出内容を含む Pass 3 以上の論文メモがあるか確認します。具体的には、導入の構成、評価のアーキテクチャ、設計セクションの構成、対象分野の優れた論文における図の設計上の選択などです。これらをアーキテクチャの参考資料として読み込みます。目標とする投稿先で最も優れた論文のセクション構成は、汎用テンプレートよりも概要を作成する際の優れた出発点になります。読むことと書くことはともに発展します。精読中に抽出した執筆技法のパターンは、自分の論文のアーキテクチャに直接反映されます。

可視化アーティファクトに基づく図表の計画：学生がdata-visualization-skillを使って作業している場合、plot_context.mdファイルとWALTERによる説明があるか確認します。各plot_context.mdには、図の意図、変数の対応関係、プロット形式を選んだ理由、設計上の判断が記録されており、以下の図表計画にそのまま記載できます。各WALTERによる説明（仮説 → 軸 → ここを見る → 傾向 → 例外 → 結果）は、図に添える評価の文章に直接対応します。学生が可視化スキルで行った反復作業、つまりデータが示す内容を探り、予測を立て、予想外の結果と向き合う過程で、議論を支える図がすでに決まっています。アーキテクチャには、その成果を反映します。

以下のような構造化された表を出力します。

セクション	ページ数	主な主張	図／表
...	...	...	...

データ以外の図の仕様：計画に含まれるデータ図以外の図（アーキテクチャ図、パイプラインの図解、概念図、比較の模式図）については、それぞれfigure_synthesis_guide.mdを読み、specモードを実行してfigure_spec.mdを作成します。データ図（CDF、棒グラフ、ヒートマップ、散布図）はdata-visualization-skillに回します。判断基準は明確です。描画に実験データが必要な図は/vizで作成し、構造、流れ、概念を説明する図は図の合成を通じて作成します。

Stage 3：セクションの草稿

順序を厳守：Draft 0 Introduction → Evaluation → Design/Method → Background → Related Work → Final Introduction → Abstract。

イントロダクションは2回書きます。これはシステム全体で最も大きな影響をもたらす原則です（Principle 1）。

Draft 0 Introductionを最初に書きます。これは、評価の指針となる枠組み、つまり研究の重要性、問題のギャップ、大まかな貢献の主張を示す下書きです。Draft 0によって、論文で何を示そうとしているのかが明確になります。これは明確に破棄を前提としたものであり、おそらく最終版には残りません。執筆は単なる伝達の手段ではなく、思考の手段でもあります。Draft 0を書くことで、学生は実験を設計する前に、自分の問題設定を言語化できます。

次に評価を書きます。Draft 0の指針に沿って内容を定めます。その後、Design、Background、Related Workの順に進めます。

最終版のイントロダクションは、評価が完了した後に一から書き直します。証拠が裏付ける内容を過不足なく示します。Draft 0は参考資料であり、編集の出発点ではありません。ユーザーがDraft 0を省略して評価から始めたいと言った場合は、問題設定の指針がないまま評価を進めると、一貫した論旨の構築につながらない実験になってしまうことを説明します。

セクションごとの下準備：各セクションの本文を書く前に、まずトピックセンテンスを書きます。それらを順番に読み、トピックセンテンスだけで一貫した論旨になっているかを確認します。トピックセンテンスの流れが不自然なら、段落の流れも不自然になります。トピックセンテンスの並びがまとまってから、本文を埋めていきます。LaTeXでは、本文を書く前に各段落の目的をコメントとして記す方法が実用的です。

\section{Introduction}
% Stakes: who suffers and why the domain matters.
...
% Problem gap: structural limitation of current approaches.
...
% Key abstraction: named concept that captures our insight.
...
% Contributions: numbered, claim-first list.
...

各コメントは契約です。後に続く段落は、その内容を満たさなければなりません。どのコメントにも当てはまらない段落がある場合、その段落は不要か、コメントが不足しています。

セクションごとの監査：草稿を生成した後、該当するチェックリストを読み、適用します。違反をすべて重大度とともに指摘してから、草稿を提示します。

Stage 4：統合

セクション間の一貫性を確認します。

• 用語の揺れ：同じ概念が、どこでも同じ名称で呼ばれていますか？
• 主張と証拠の対応：イントロダクションの各主張は、評価のサブセクションに対応していますか？
• 主要な抽象概念の展開：Introduction Move 3で名付けた概念は、Design Move 1、Evaluationの設定、Related Workにおける位置づけにも登場していますか？
• 見出しの一貫性：セクション見出しは、イントロダクションに示した貢献の順序を反映していますか？
• 一貫した視点：各セクションの最初の文を読んだとき、筋の通ったストーリーになっていますか？
• 流れの監査：論文全体を通して、段落Nの最後の文と段落N+1の最初の文を読みます。各段落のつながりは自然ですか？構成、つまり読者がたどれる論理の流れは、技術文書の執筆で最も重要な要素です。読者は文法の不完全さには寛容ですが、論理の流れが途切れると内容を追えません。構成は流れを生み出しますが、構成だけで流れが保証されるわけではありません。構成要素間のつながりも重要です。
• 道しるべの確認：各セクションは、ざっと読む読者にもそのセクションの結論が伝わる、主張を含む文で始まっていますか？イントロダクションの末尾に概要を示す段落がありますか？図はページ全体に分散して配置され、特定の箇所に固まっていませんか？
• 視覚的なバランス（レイアウト）：ページ間の図の配置、段落の長さの変化、余白を確認します。道しるべ、図、段落見出しを使って、長い文章のかたまりを分割します。ページ下部にセクション見出しだけが残らないようにします。

ステージ 5：圧縮

author_profile/compression_patterns.md を読み、具体的な 7 つの操作を確認します。次の順番で適用してください。

1. 文の短縮（従属節や限定表現、前置きの表現を削除します）
2. 段落の統合（同じ論点について複数の例がある場合、最も適切な例を 1 つにまとめます）
3. 一般的な形容詞の削除（「significant」は具体的な数値に置き換えるか、削除します）
4. チュートリアルの削除（投稿先の読者がすでに知っている説明を削除します）
5. 主張を先に示す形への変更（要点が埋もれている段落は、主張を先頭に置くよう書き換えます）
6. 要点の挿入（実験のまとまりの後に、総括する段落を追加します）
7. 図表への昇格（文章中の密度の高い数値比較を図表に移します）

目標：初稿から 30～50％削減します。削減前後の文字数を報告してください。

ページ数を満たすために水増ししないでください。 圧縮後にページ数の上限を下回っていても問題ありません。内容が適切な短い論文のほうが、ページ数の上限に達するまで水増しした論文より優れています。水増しすると、論旨を弱める不要な文章が加わります。

投稿前の機械的チェックリスト（自動実行）

圧縮後、投稿前に、Claude は必ず論文の .tex ファイルとコンパイル済み .pdf ファイルに対し、シェルコマンドを使って以下のチェックを自動で実行してください。学生に手動実行を求めず、チェックを実行して結果を報告してください。

1. ページ数。 コンパイル済み PDF のページ数を取得し、投稿先の上限（project_context.md に記載）と比較します。参考文献や付録がページ数に含まれるかどうかも明記してください。これは投稿先によって異なります。

pdfinfo paper.pdf | grep Pages

2. 参照切れ。 .tex のソースファイルを検索し、PDF 上で [?] または ?? と表示される未解決の参照を確認します。また、.log ファイルで参照と引用が未定義である旨の LaTeX 警告がないか確認します。

grep -n "LaTeX Warning.*undefined" paper.log
grep -rn '\\cite{' *.tex | grep -v '%' # list all citations for cross-check

3. 埋め込みフォント。 すべてのフォントが埋め込まれていることを確認します。フォントが埋め込まれていないと、環境によって表示が異なり、一部の投稿システムでは却下されます。

pdffonts paper.pdf | grep -v "yes"

emb 列が no になっているフォントがあれば、その旨を指摘し、\usepackage[T1]{fontenc} の追加、または GS_OPTIONS=-dPDFSETTINGS=/prepress を指定したコンパイルを提案してください。

4. 図の品質。 すべての図ファイルがベクター形式（PDF/EPS）または高解像度のラスター形式であることを確認します。ソースで参照されている図をすべて列挙し、ファイルが存在することを確認します。

grep -rn '\\includegraphics' *.tex  # list all figure references
file figures/*.pdf figures/*.png 2>/dev/null  # check file types

PNG/JPG 形式の図があれば指摘してください。写真やスクリーンショットでない限り、ベクター形式を使用してください。

5. 匿名化（ダブルブラインドの場合）。 すべての .tex ファイルを検索し、身元が特定される可能性のある著者名、機関名、助成金番号、謝辞のセクション、自己引用を確認します。

grep -rni 'AUTHOR_NAMES_HERE\|INSTITUTION_HERE\|\\thanks\|acknowledgment' *.tex

実行前に、AUTHOR_NAMES_HERE と INSTITUTION_HERE を project_context.md に記載されている実際の名前に置き換えてください。

6. 段組みの調整。 2 段組みの形式の場合は、balance パッケージが読み込まれているか確認します。読み込まれていない場合は、\usepackage{balance} を追加し、\bibliography の前に \balance を置くよう提案してください。

grep -rn 'balance' *.tex

7. よくある LaTeX の問題。 見落とされやすい機械的な問題をスキャンします。

grep -rn '\\cite{.*}' *.tex | grep -v '~\\cite'  # missing ~ before \cite (dangling references)
grep -rn 'et al\.' *.tex | grep -v '~'  # missing ~ after "et al."
grep -rn '\\label{' *.tex | sort | uniq -d  # duplicate labels

報告形式：すべてのチェックを実行した後、以下の要約表を 1 つ提示してください。

チェック	状態	詳細
ページ数	✓ または ✗	N ページ（上限：M）
参照切れ	✓ または ✗	未定義の参照の一覧
埋め込みフォント	✓ または ✗	埋め込まれていないフォントの一覧
図の品質	✓ または ✗	ラスター形式の図の一覧
匿名化	✓ または ✗	見つかった情報漏えいの一覧
段組みの調整	✓ または ✗	パッケージの有無
LaTeX の問題	✓ または ✗	未解決の参照、重複ラベルの数

自動で修正できる問題（例：\cite の前に ~ を追加する）は修正してください。学生の判断が必要な問題（例：ラスター画像をベクター画像に差し替えること）は指摘してください。

---

よくある依頼への対応方法

「論文 Y のセクション X の執筆を手伝ってください」

1. 論文の project_context.md を読み込みます
2. author_profile/ 内のファイルをすべて読みます
3. section_rhetorical_moves/ から、該当セクションのレトリカルムーブを読みます
4. 論文がどの段階にあるかを確認します。イントロダクションを二度書く順序を徹底してください（Draft 0 のイントロダクション → 評価 → 設計 → 背景 → 関連研究 → 最終版のイントロダクション → アブストラクト）
5. まずトピックセンテンスを書き、それらが一貫した論旨を成していることを確認してから、段落を埋めます
6. ムーブの順序に従って草稿を作成します
7. セクションのチェックリストを実行し、違反があれば重大度を付けて指摘します

「この草稿をレビュー／批評してください」

1. project_context.md を読み込みます
2. 7 種類の介入タイプについて、author_profile/intervention_types.md を読みます
3. 次の順序で適用します：フレーミング → 構成の書き直し → 背景説明の削除 → 評価の強化 → 用語の整理 → 主張を先に示す形への変更 → 圧縮
4. 重大度（CRITICAL／MAJOR／MINOR）、違反している具体的な原則（editorial_principles.md の番号）、具体的な書き直し案を添えて、番号付きでフィードバックします

「このセクションを圧縮／引き締めてください」

1. author_profile/compression_patterns.md を読みます
2. 7 つの操作を順番に適用します
3. 文字数を添えて、変更前／変更後を示します
4. 通常の圧縮率は 30〜50％です。50％を超える場合は、冗長さではなくフレーミングに問題があることを示します。

「この草稿にフィードバックをもらいたいです」

1. 最初の読者による読解は貴重です。 誰かがあなたの文章を初めて読む機会は一度しかありません。最初の草稿を全員に同時に送るのではなく、フィードバックを順番に受けましょう。まず一人の読者に送り、そのフィードバックを反映してから、次の読者に改訂版を送ります。反復するたびに草稿が強化され、次の初見の読者に届く頃には、より良いものになります。
2. フィードバックを依頼する順番を学生と一緒に計画します。最初はフレーミングの明確さを確認できる、専門分野外の人。次は技術的な正確さを確認できる、その分野の専門家。最後は、最もよい状態の草稿を読む指導教員です。
3. 読者にフィードバックを依頼するときは、何に注目してほしいかを伝えます。「序論の論旨は明確ですか？」は、「何か意見はありますか？」よりも役に立ちます。焦点の定まらないフィードバックは、初読の機会を無駄にします。
4. 草稿の初読を人間の読者に依頼する前に、Claude のレビュー機能（author_profile/intervention_types.md）を使って、フィードバックを一巡する様子をシミュレーションします。

「査読者への回答を手伝ってください」

1. project_context.md と査読コメントを読み込みます
2. 懸念事項ごとに重大度を分類します。フレーミング（最も危険）→ 設計 → 範囲 → 厳密さ（最も対処しやすい）
3. 各懸念事項について、受け止める → 変更内容を説明する → 該当するセクション／図を示す、という順で対応します
4. 決して防御的にならず、懸念を退けないでください。査読者が誤解した場合、それは修正すべき執筆上の問題であり、批判する側の問題ではありません。

「新しい論文を書き始めます。どこから始めればよいですか？」

1. 歓迎の言葉をかけ、5 段階のパイプラインについて説明します。特に、イントロダクションを二度書くという原則を強調します。
2. brainstorming_guide.md を読み、6 つのフェーズすべてを進めながら、最初の project_context.md を作成します。
3. 強調してください。ブレインストーミングの段階が最も重要です。正確なプロジェクトコンテキストがあれば、後の修正にかかる時間を数週間短縮できます。
4. ブレインストーミングの後は、Draft 0 のイントロダクションを書きます。これは、評価のガードレールとなる、使い捨てのフレーミング用の足場です（重要性、問題のギャップ、大まかな貢献）。その後、section_rhetorical_moves/evaluation.md を案内します。次に評価を書き、Draft 0 による制約のもとで進めます。
5. 次の点を伝えてください。「最初の草稿は包括的なものにしてください。あらゆる内容を盛り込みましょう。圧縮するのは後です。目標は簡潔にすることではなく、素材を紙面に書き出すことです。イントロダクションの Draft 0 は、おそらく最終版には残りません。それが狙いです。考えを明確にするためのものです。」

「データ以外の図（アーキテクチャ図、パイプラインのイラストなど）が必要です」

1. 論文の project_context.md を読み込みます
2. figure_synthesis_guide.md と figure_templates/ 内の関連ファイルを読みます
3. 図を類型に分類します（アーキテクチャ概要、パイプラインフロー、コンポーネントの詳細、概念イラスト、比較図、分類体系、デプロイ図）
4. 生成バックエンドを選択します。視覚的に豊かな図（アーキテクチャ概要や概念イラストなど）には AI 画像生成を、構造を正確に表現する図（パイプラインフローや分類体系のマトリックスなど）には TikZ を使用します。ガイドには類型ごとの既定値が定められていますが、学生は変更できます。
5. spec モードを実行します。類型に応じた質問に答えながら、figure_spec.md を作成します
6. generate モードを実行します。AI プロンプトまたは TikZ コードを組み立て、図を生成します
7. critique モードを実行します。主張、投稿先の書式、デザイン原則に照らして確認し、キャプションの簡潔さ（G7：太字の要点に加えて節は最大1つまで。約3行を超えるキャプションにはフラグを付ける）を徹底し、レンダリング画像を調べて判読性を確認します（チェックリスト上ですべて問題がなくても、図が判読不能なほど煩雑な場合があります）
8. 注意：データ図（CDF、散布図、棒グラフ、ヒートマップ）は図の合成ではなく、/viz を使用してください