refactor-structure

構成の再編

言葉ではなく、議論の構成を修正します。論文は文法的で、テンプレートに沿っており、ページ数の上限内に収まっていても、ストーリーが適切でない順序で組み立てられていたり、セクションが役割を果たしていなかったり、序論で約束した内容が本文で示されていなかったり、結論が証拠の範囲を超えていたりすれば、評価に失敗することがあります。このスキルはそうした問題を診断し、それぞれの理由を添えた構成変更計画（移動／統合／分割／削除）を作成します。セクションを書き直す前に、著者の承認を得ます。

構成変更を計画し、承認後に実行します。文の言い換えは行いません（それは polish-prose の役割です）。また、投稿先の規定に論文を適合させることもしません（それは tailor-to-venue の役割です）。

使用するタイミング

• 「構成に違和感がある」／「流れが悪い」／「論文を再構成して」。
• 査読者から、理解しにくい、まとまりがない、ストーリーが不明瞭、貢献が埋もれている、関連研究の配置が不適切、あるセクションが不要といった指摘があった。
• 序論で過剰に約束している（本文にない証明／ユーザー調査／アブレーションを主張している）、または結論で証拠が示されていないことを主張している。
• セクションが重複している（Background セクションが 2 つある）、または 1 つのセクションが 2 つの役割を担っている（Results セクションに Threats-to-Validity が含まれている）。

次の用途には使いません。文の表現や AI らしさの除去（polish-prose）、ページ数の上限／テンプレート／投稿先への適合（tailor-to-venue）、Related Work セクションの内容（draft-related-work）、引用が実在するかどうか（verify-citations）。

入力

• 草稿：メインの .tex ファイル（スクリプトは \input／\include をたどります）。
• 任意：論文の意図する貢献の一覧と対象とする論文の種類。存在する場合は .paper-memory/profile.yml から取得します（理論論文と実証論文では、期待される論の展開が異なります）。存在しない場合は、主張を一文で、貢献を箇条書きで著者に尋ねます。

プロセス

1. 論文を読み直すのではなく、構成を読む

同梱の抽出ツールを実行し、全体の骨組みを 1 画面に表示します。

python3 skills/refactor-structure/scripts/outline_extract.py <main.tex>

このツールは、セクション／サブセクションの階層、各単位の最初の文（トピックセンテンス。適切に構成されたセクションが、その役割を示す文）、および単位ごとの指標（単語数、引用、図表・数式・リストの有無、トピックセンテンスなしで始まる単位）を表示します。--md を使うと構成の骨組みを計画に挿入でき、--json を使うと独自の分析に利用できます。--no-inputs を使うと、単一のセクションファイルを対象に実行できます。入力に問題がある場合は終了コード 2 を返します。これは構成マップであり、評価ではありません。どこに何があるかを示すもので、以下の診断で判断を行います。

2. 意図する論の展開を明確にする

順序を評価する前に、論文が何を論じようとしているかを把握します。貢献の箇条書きとアブストラクトの主張を読みます。問題、主張する貢献、その貢献を裏付けるはずの証拠、そして各貢献によって正当化される結論を、それぞれ一行で書き出します。これが、以降のすべての確認で照合する論文の主軸となります。

3. アーキテクチャチェックリストに照らして診断する

references/architecture-checklist.md に沿って確認します。このチェックリストでは、7 つの失敗パターン（順序の誤り、セクションが本来の役割を果たしていない、欠落、重複、不適切な配置、序論と本文の不一致、貢献 -> 根拠 -> 結論の流れの破綻）と、論文の種類ごとの標準的なセクション構成を扱います。特に価値が高く、客観的に判断しやすいチェック項目は次の 2 つです。

• 約束と実行の対応。 序論にある貢献の箇条書きや「私たちは示す／証明する／評価する」の各項目について、それを実現するセクションを特定します。約束した証明、ユーザー調査、アブレーションがどのセクションにもない場合、読者（および査読者）は論文の欠落として指摘します。逆に、序論で予告していない主要な結果セクションがあれば、すべて列挙します。
• 結論と根拠の対応。 結論のすべての主張は、本文中の結果を根拠としてたどれる必要があります。たとえば、スケーリング実験がないのに「任意の数のノードにスケールする」といった新しい主張を導入する結論は、論旨の流れを断ち切ります。「主張を削除する」か、「それを裏付ける実験が本文に不足している」として指摘します。

各症状を具体的な対処法（移動／統合／分割／削除）に結び付ける方法と、確認すべき波及的な影響（前方参照、「Section~X で示すとおり」といった参照、削除したセクションの引用が残っていないか）については、references/diagnosis-patterns.md を参照してください。

4. 構成変更計画を作成する（編集前に著者の承認を得る）

実行せず、計画を作成します。paper-workspace/writing/restructuring-plan.md に次の内容を記述します。

1. 現在の骨格 — ステップ 1 の --md によるアウトライン。
2. 意図する論旨の流れ — ステップ 2 の骨格。
3. 診断 — 失敗パターンごとに所見を整理し、それぞれについて、問題点、論旨への悪影響、深刻度（理解を妨げる／弱める／軽微）、提案する対処法を記載します。
4. 提案する骨格 — 計画実施後のセクションツリーを示し、著者が新しい順序をひと目で把握できるようにします。
5. 順序付きの移動リスト — 各移動／統合／分割／削除を、個別に元に戻せる手順として記載し、波及的な影響も含め、各手順の間も文書の一貫性が保たれる順序に並べます。

より手間の少ない方法も明示したうえで診断を提示します。多くの場合、順序の変更と 2 つのセクションの統合で、書き直し以上の改善が得られます。症状に複数の解釈がある場合（ユーザー調査が本当に欠けているのか、単にラベルが付いていないだけなのかなど）は、両方の可能性を示して著者に確認します。\input ファイルに該当セクションが含まれている可能性があるのに、あるものとして黙って決めつけてはいけません。

5. 承認後、1 ステップずつ実行する

著者の承認を得てから、順序どおりに移動を適用します。構造を変更するたびに outline_extract.py を再実行し、骨格が提案どおりになっていることを確認するとともに、計画に記載した波及的な影響（相互参照、「Section~X を参照」といった記述、移動したセクションのラベル）を修正します。文章の移動は機械的に行います。文章を黙って言い換えてはいけません。新たなつなぎの文章が必要な箇所は著者に指摘するか、polish-prose に引き継ぎます。削除によって孤立した参照（参照先のなくなった \cite）は verify-citations に回します。根拠を失った主張（例：ステップ 3 の結論と根拠の不一致）は、適切な主張→根拠の監査を行うため verify-claims に回します。どちらの場合も、穴埋めのために引用や結果を捏造してはいけません。

出力

• レビュー可能な paper-workspace/writing/restructuring-plan.md：現在の骨格 -> 意図する論旨の流れ -> 診断 -> 提案する骨格 -> 順序付きの移動。
• 承認後、適用した変更と、結果を確認するために再抽出した骨格、および波及的な影響のチェックリスト（相互参照、参照記述、ラベル）。
• 変更の一つひとつは著者が決定します。この作業で文単位の書き直しは行いません。

専門分野に合わせる

失敗パターンは分野を問わず共通ですが、期待される展開はそうではありません。 references/architecture-checklist.md には、コンピューターサイエンス論文向けの展開（システム／機械学習の実証研究／理論）が記載されています。自分の分野に合わせてフォークしてください。 実験科学の IMRaD、関連研究の配置の変更、結果の前に方法を置くか結果と交互に配置するかという慣習、人文科学におけるエッセイ形式の論証構成などが考えられます。

ガードレール

• 論文に手を加える前に計画を立ててください。 診断と変更リストを先に作成し、セクションを移動、統合、分割、削除する前に著者の承認を得ます。
• 構成を変更するのであり、表現を書き換えるのではありません。文単位の編集には polish-prose を、投稿先／トラック／ページ数への適合には tailor-to-venue を使用してください。移動した文章を黙って書き換えないでください。継ぎ目が不自然な箇所は著者に伝えます。
• 「不足を埋める」ために、結果、セクション、引用を決して捏造しないでください。ユーザー調査がない場合は、その事実を報告します。修正するには調査を追加するか、その約束を削除するかのどちらかであり、決してでっち上げてはいけません。
• 著者が必要とする可能性のある内容を決して削除しないでください。削除は提案であり、削除したテキストは復元できるように、移動先を記録して保持します。
• 診断は投稿先の規則や記憶ではなく、構成を読み取って行います。抽出結果と草稿を正とします。構成変更によって論文が採択されると断言することはありません。
• 著者に代わって、どこにも何も提出しないでください。

他のスキルとの関係

• tailor-to-venue — 投稿先／トラックへの適合、ページ数の制限、テンプレート、匿名化レベルに対応します。論旨が整った後に実行します。順序は「構成を整えてから適合させる」であり、その逆ではありません。
• polish-prose — 文単位の表現、断定の緩和、AI 特有の不自然さに対応します。残す文章を磨けるよう、構成が確定した後に実行します。
• draft-related-work — 関連研究セクションの内容に対応します。このスキルが判断するのは、そのセクションの配置と役割を果たしているかどうかだけです。
• verify-claims — 結論の主張が証拠を超えている場合（展開の破綻）、このスキルは構成上の破綻を指摘し、verify-claims は主張が実際に裏付けられているかを監査します。verify-citations は別途、.bib エントリーが解決されるかどうか（たとえば、削除によって孤立した参考文献）を確認します。
• simulate-reviewers / assess-paper — 模擬レビューで「理解しにくい」と指摘された場合、このスキルで修正します。

メモリ

ユーザーの論文ディレクトリで、共有の .paper-memory/ 規約を使用します （完全な仕様：paper-memory-convention.md）。

• 開始時： profile.yml（論文の種類によって期待される展開が決まります）と lessons.md を読み、すでに記録されている繰り返しの構成上の傾向（例：「Threats to Validity をいつも Results に埋もれさせてしまう」）があれば、それを最初に取り上げて優先的に確認します。
• 終了時： reflect-and-improve の reflect_log.py append を使い、共有形式 - [YYYY-MM-DD] (refactor-structure | <scope>) pattern -> recommendation で、今後も役立つ知見を追記します。草稿をまたいで見られる傾向は recurring、一度限りの傾向は this-paper とします。通常の単発の変更は記録しません。
• .paper-memory/ がなければ必要に応じて作成し、プロジェクトの .gitignore への追加を提案します。このディレクトリはローカルにのみ存在し、アップロードもこのリポジトリへのコピーも行いません。