auto-paper-improvement-loop

論文の自動改善ループ：レビュー → 修正 → 再コンパイル

各レビュースロットの前に、レビュアーの選択に従ってください： 呼び出し方法の解決 → .aris/reviewer.json → Claude Code のデフォルト（Codex MCP） を、正規のヘルパーリゾルバー経由の reviewer_route.py で実行し、この スロットのティア、フレッシュなコンテキスト、ソース／画像入力、決定論的ゲートを維持します。 以下の Codex の例／固定設定は backend=codex の場合にのみ適用されます。他のルートでは、 それぞれ独自の初回呼び出し／返信の契約を使用します。ルートと実際に返された ID を保存してください。 選択したものが利用できない場合は REVIEW_UNAVAILABLE とします。実際の ファミリー／完了状況／スコープに基づいて受け入れを分類します。呼び出し時のレビュアー／モデル／推論強度のオーバーライドは、 レビュアーを使う子プロセスに引き継ぎます。生成ワーカーは変更しません。

🔒 このスキルを /loop、/schedule、CronCreate でラップしないでください。 このスキルは、 独自のラウンド構成と、各ラウンドで意図的に新しいレビュアーを使うバイアス防止策（codex-reply は使用しません）を伴って、 内部で（レビュー → 修正 → 再コンパイル）のループをすでに実行します。 壁時計のタイマーで再び「論文を改善」しても、新しいシグナルは得られません。品質が変わるのは時計が進んだときではなく、 レビューが変わったときです。また、時間を指定して再実行し、停止時期の判断に自分の出力も受け入れるようにすると、 自己弁明（acceptance-gate.md）に踏み込むことになります。スケジュールするのは、改善ループではなく、 その前にある外部の待機です。詳しくは shared-references/external-cadence.mdを参照してください。

次の論文を自律的に改善します：$ARGUMENTS

コンテキスト

このスキルは、ワークフロー 3（/paper-plan → /paper-figure → /paper-write → /paper-compile）の後に実行するよう設計されています。コンパイル済みの論文を受け取り、外部 LLM によるレビューを通じて反復的に改善します。

/auto-review-loop（実験の実施、データの収集、説明の書き直しなど、研究を反復するもの）とは異なり、このスキルが反復するのは論文の執筆品質です。理論上の矛盾を修正し、過大な主張を抑え、不足している内容を追加し、見せ方を改善します。

定数

• MAX_ROUNDS = 2 — レビュー→修正→再コンパイルを 2 ラウンド実施します。経験上、ラウンド 1 では構成上の問題（4→6/10）、ラウンド 2 では残っている表現上の問題（6→7/10）が見つかります。執筆のみの改善では、2 ラウンドを超えると効果が逓減します。
• REVIEWER_MODEL = gpt-6-astra — Codex MCP 経由で論文レビューに使用するモデルです。
• REVIEWER_BIAS_GUARD = true — true の場合、各レビューラウンドでは過去のレビューコンテキストを含まない、新しい mcp__codex__codex スレッドを使用します。レビューラウンドに mcp__codex__codex-reply を使用してはいけません。従来の動作を意図的にデバッグする場合に限り、false に設定します。実証的な根拠： 同じ論文に対して codex-reply を使い、「前のラウンドから今回までに X を実施しました」というプロンプトを与えると、複数のラウンドにわたって実際の 3/10 が見せかけの 8/10 に水増しされました。新しいスレッドに切り替えたところ、本来の 3/10 という評価が得られました。
• REVIEW_LOG = PAPER_IMPROVEMENT_LOG.md — 各ラウンドの累積ログで、論文のディレクトリに保存されます。
• HUMAN_CHECKPOINT = false — true の場合、各ラウンドのレビュー後に一時停止し、スコアと弱点をユーザーに提示します。ユーザーは修正を承認したり、独自の変更指示を出したり、特定の修正をスキップしたり、早期に終了したりできます。false（デフォルト）の場合は、完全に自律して実行します。
• EDIT_WHITELIST = null — 修正実装ステップで変更可能なパスや操作を制限する、YAML／JSON 形式のホワイトリストファイルの任意のパスです。null（デフォルト）の場合、編集に制限はありません。— edit-whitelist <path>（— edit_whitelist <path> も可）で設定すると、ループの起動時にファイルを読み込み、編集の前に毎回参照します。却下された編集は黙って破棄せず、PAPER_IMPROVEMENT_LOG.md に記録します。詳しくは、以下の「任意設定：編集ホワイトリスト」を参照してください。

💡 オーバーライド：/auto-paper-improvement-loop "paper/" — human checkpoint: true

任意：スタイル参照（— style-ref: <source>、オプトイン）

改善中に、参照論文に合わせて構造上の修正のみ（セクションの並べ替えのヒント、段落の長さの調整、図の密度の調整）を行うようユーザーが指定できます。デフォルトではオフです。ユーザーが — style-ref を渡さない場合、以前と何も変わりません。

$ARGUMENTS に — style-ref: <source> が含まれる場合に限り、ループの開始前にヘルパーを最初に実行します。

# Resolve $STYLE_HELPER via the canonical strict-safe chain (see
# shared-references/integration-contract.md §2). Policy A — gate:
# unresolved helper means --style-ref cannot be satisfied, so abort.
cd "$(git rev-parse --show-toplevel 2>/dev/null || pwd)" || exit 1
if [ -z "${ARIS_REPO:-}" ] && [ -f .aris/installed-skills.txt ]; then
    ARIS_REPO=$(awk -F'\t' '$1=="repo_root"{print $2; exit}' .aris/installed-skills.txt 2>/dev/null) || true
fi
if [ -z "${ARIS_REPO:-}" ] && [ -f "$HOME/.aris/repo" ]; then
    ARIS_REPO=$(cat "$HOME/.aris/repo" 2>/dev/null) || true
fi
STYLE_HELPER=".aris/tools/extract_paper_style.py"
[ -f "$STYLE_HELPER" ] || STYLE_HELPER="tools/extract_paper_style.py"
[ -f "$STYLE_HELPER" ] || { [ -n "${ARIS_REPO:-}" ] && STYLE_HELPER="$ARIS_REPO/tools/extract_paper_style.py"; }
[ -f "$STYLE_HELPER" ] || {
  echo "ERROR: extract_paper_style.py not resolved at .aris/tools/, tools/, \$ARIS_REPO/tools/, or via ~/.aris/repo." >&2
  echo "       Fix: rerun bash tools/install_aris.sh or smart_update.sh (refreshes ~/.aris/repo), export ARIS_REPO, or copy the helper to tools/." >&2
  echo "       --style-ref cannot be satisfied; aborting." >&2
  exit 1
}
STYLE_STATUS=0
CACHE=$(python3 "$STYLE_HELPER" --source "<source>") || STYLE_STATUS=$?
case "$STYLE_STATUS" in
  0) ;;                                       # use $CACHE/style_profile.md as structural guidance for the FIX phase only
  2) echo "warning: style-ref skipped (missing optional dep)" >&2 ;;
  3) echo "error: --style-ref source failed; aborting loop" >&2 ; exit 1 ;;
  *) echo "error: helper failed unexpectedly; aborting loop" >&2 ; exit 1 ;;
esac

受け付けるソース：ローカルの TeX ディレクトリ／ファイル、ローカルの PDF、arXiv ID、http(s) URL。Overleaf の URL／ID は受け付けません。まず /overleaf-sync setup <id> でクローンし、そのローカルのクローンパスを渡してください。

厳格なルール（契約の全文は tools/extract_paper_style.py の docstring を参照してください）：

• style_profile.md は修正の実装フェーズでのみ使用し、査読者のフィードバックを適用する際の構造上の選択を調整するために使用します。査読者のフィードバックが常に優先されます。スタイル参照は、修正を適用する「かどうか」ではなく、「どのように」適用するかを決める際のタイブレーカーです。
• 修正を実装する際、キャッシュを通じて参照できるものから、文章、主張、例、用語を決してコピーしないでください。
• — style-ref（またはキャッシュの内容）を GPT-6-Astra の査読者サブエージェントに決して渡さないでください。以下の査読者の独立性プロトコルでは、査読者がアーティファクトとユーザーのプロンプトのみを見ることを求めています。スタイル参照を漏らすと、著者側のコンテキストが査読に混入します。このスキルで最も重要な不変条件です。

任意：編集ホワイトリスト（— edit-whitelist <path>、オプトイン）

呼び出し側が、修正の実装ステップ（ステップ 3／ステップ 6）で編集可能なファイルと操作を厳密に制限できます。デフォルトではオフです。ユーザーが — edit-whitelist（またはエイリアスの — edit_whitelist）を渡さない場合、ループはこれまでと同様、制限なく査読者の指摘に基づくすべての編集を適用します。

このパラメーターは、上流のパイプライン（例：/resubmit-pipeline のフェーズ 2）が、テキストのみの再投稿向けの細かな編集を強制するために使用します。.bib の変更、.sty／.bst の変更、過去の投稿ディレクトリの編集、新しい \cite{...}、新しい定理環境、新しい数値的主張を禁止します。

スキーマ

ホワイトリストファイルは YAML または JSON です。4 つのセクションはすべて省略可能です。

allowed_paths:
  - sec/*.tex
  - main.tex
  - figures/*.tex
forbidden_paths:
  - "**/*.bib"
  - "**/*.sty"
  - "**/*.bst"
  - "../OldSubmission/**"
forbidden_operations:
  - new_cite              # blocks \cite{...}, \citep{...}, \citet{...}, \citeauthor{...} additions
  - new_bibitem           # blocks \bibitem{...} additions
  - new_theorem_env       # blocks \begin{theorem|lemma|proposition|corollary} additions
  - numerical_claim       # blocks adding new numbers / percentages / metrics
forbidden_deletions:      # operations that block REMOVALS, not additions
  - delete_existing_cite  # blocks removal of \cite{...} from the body (use citation-audit --soft-only instead)
  - delete_theorem_env    # blocks removal of an existing \begin{theorem|...} block
requires_user_approval_for:  # operations that don't auto-reject but pause for explicit user OK
  - rewrite_abstract      # paraphrasing the entire abstract triggers a checkpoint
  - rewrite_intro_first_para
  - delete_section
max_edits_per_round: 30   # hard cap on number of accepted edits per round (rejections are not counted; if cap is hit, remaining proposed edits are deferred to the next round with a warning)
rationale: "Resubmit mode: text-only microedits, paper structure frozen by user constraint."

解決ルール

• allowed_paths が空で、forbidden_paths も空 → ホワイトリストは何も行いません（参考情報として、ファイルが読み込まれ、rationale がログに出力されますが、パスのフィルタリングは適用されません）。
• allowed_paths が空で、forbidden_paths が空ではない → forbidden_paths に一致しないすべてのパスが変更可能です。
• allowed_paths が空ではなく、forbidden_paths が空 → allowed_paths に一致するパスのみ変更可能です。
• 両方とも空ではない → 対象が allowed_paths に一致し、かつ forbidden_paths に一致しない場合に限り編集が許可されます。重複する場合は、常に forbidden_paths が優先されます。
• forbidden_operations がない、または空 → 操作レベルのガードはなく、パスレベルのフィルタリングのみが適用されます。

Glob のセマンティクス

bash の extglob／Python の fnmatch.fnmatch のセマンティクスを使用します。** は任意の深さ（ディレクトリ階層が 0 個以上）に一致します。パターンは論文ディレクトリを基準とする相対パスに照合されます（例：論文ディレクトリが paper/ の場合、paper/sec/intro.tex は sec/*.tex に一致します）。

禁止操作の検出器

各編集候補の差分（追加される新しい行のみ。削除は対象外）に対し、ループは次の正規表現チェックを実行し、禁止操作に一致するものがあれば拒否します。

操作	検出器（追加行のみ）
new_cite	\\cite[a-zA-Z]*\{[^}]+\}（\cite、\citep、\citet、\citeauthor、\citeyear、\citealp などを検出）
new_bibitem	\\bibitem\{[^}]+\}
new_theorem_env	`\begin{(theorem
numerical_claim	削除／置換された行に存在しなかった新しいトークン \b\d+(\.\d+)?%?\b（既存の数値の編集ではなく、新たに追加された数値）

ループ開始時の動作（Round 1 の修正実装前）

1. $ARGUMENTS に — edit-whitelist <path> が含まれている場合は、EDIT_WHITELIST = <path> に設定します。
2. ファイルを読み込みます（yaml.safe_load を使用し、失敗した場合は json.loads にフォールバックします）。読み込みに失敗した場合は、明確なエラーを表示してループを中止します。制約なしで処理を続行してはいけません。
3. rationale がある場合は、その内容を PAPER_IMPROVEMENT_LOG.md の新しい「Edit Whitelist」前置きセクションに記録し、編集に制約を設けた理由が監査証跡に残るようにします。

修正実装中の動作（Step 3 および 6）

提案された編集を適用する前に、次の手順を実行します。

1. 対象ファイルのパスを論文のディレクトリを基準に解決します。
2. パスを確認します。allowed_paths が空でない場合、対象は少なくとも 1 つのパターンに一致する必要があります。次に、forbidden_paths が空でない場合、対象はいずれのパターンにも一致してはいけません。どちらかの条件を満たさない場合は、path 違反として却下します。
3. 操作を確認します。提案された編集の unified diff（または新たに追加される行の集合のみ）を作成します。forbidden_operations の各項目について、その検出器を追加行に対して実行します。いずれかの検出器が一致した場合は、operation 違反として却下します。
4. すべての確認に合格した場合は、通常どおり編集を適用します。
5. 却下した場合は、次のスキーマに従って PAPER_IMPROVEMENT_LOG.md の ## Rejected by edit_whitelist (Round N) 見出しの下に項目を追加します。

   - file: <relative path>
     reason: path | operation
     pattern: <the offending forbidden_path glob, OR the offending forbidden_operation name + the matched substring>
     reviewer_concern: <the original Round-N weakness that motivated this edit>
   

6. そのラウンド内の残りの編集を続行します。1 件の却下を理由にラウンド全体を中止してはいけません。

ラウンド終了時の通知

各ラウンドの終了時（再コンパイル後、次のラウンドに進む前）に、そのラウンドの修正ステップで却下された編集がある場合は、次の処理を行います。

• ラウンドのチェックポイント出力に、次の 1 行の要約を表示します。Edit whitelist rejected N edits this round (M path, K operation). See PAPER_IMPROVEMENT_LOG.md "Rejected by edit_whitelist (Round N)".
• HUMAN_CHECKPOINT = true の場合は、次のラウンドの修正を承認する前に、ユーザーに表示するチェックポイントに却下リストを含めます。

実行例

# Resubmit-pipeline Phase 2 caller (text-only mode):
/auto-paper-improvement-loop "paper/" — edit-whitelist .resubmit/edit_whitelist.yaml

# Aliased form is accepted:
/auto-paper-improvement-loop "paper/" — edit_whitelist .resubmit/edit_whitelist.yaml

# Combined with other flags:
/auto-paper-improvement-loop "paper/" — human checkpoint: true — edit-whitelist constraints.yaml

理由

ホワイトリストがない場合、レビュアーの指摘に基づくループの修正ステップでは、引用の追加、新しい定理環境の導入、数値に関する主張の調整を自由に行えます。これらは初回投稿の仕上げには妥当ですが、論文の構成が外部制約によって固定されている再投稿、カメラレディ版、反論のみのモードでは禁止されています。制約を（LLM が「やらないように覚えておく」ことに頼るのではなく）第一級のパラメーターとして指定することで、制約を確実に適用し、PAPER_IMPROVEMENT_LOG.md による監査を可能にし、各ラウンドのチェックポイントでユーザーに提示できます。

入力

1. コンパイル済みの論文 — paper/main.pdf と LaTeX ソースファイル
2. すべてのセクションの .tex ファイル — レビュープロンプト用に結合したもの

状態の永続化（コンパクト化からの復旧）

ループの途中でコンテキストウィンドウがいっぱいになると、Claude Code は自動的にコンパクト化します。復旧できるよう、このスキルは各ラウンドの後に PAPER_IMPROVEMENT_STATE.json を書き込みます。

{
  "current_round": 1,
  "threadId": "019ce736-...",
  "last_score": 6,
  "status": "in_progress",
  "timestamp": "2026-03-13T21:00:00"
}

起動時：PAPER_IMPROVEMENT_STATE.json が存在し、"status": "in_progress" で、かつ timestamp が 24 時間以内の場合は、ファイルと PAPER_IMPROVEMENT_LOG.md を読み込んでコンテキストを復旧し、次のラウンドから再開します。それ以外（ファイルが存在しない、"status": "completed"、または 24 時間より古い）の場合は、最初から開始します。

各ラウンドの後：状態ファイルを上書きします。完了時："status": "completed" に設定します。

レビュアーの独立性に関するプロトコル

レビュアーは毎回、事前の文脈を知らない状態でレビューする必要があります。前のラウンドの要約、修正リスト、実行者の説明は根拠にはなりません。これらは確証バイアスの原因になります。変更点を伝えると、原稿自体が実質的に改善されていなくても、評価が上がる傾向があります。

ルール：

• すべてのラウンドは、mcp__codex__codex-reply ではなく mcp__codex__codex から開始します。
• 次のレビュー用プロンプトに、前の threadId を渡してはいけません。
• レビュアーへのプロンプトに、「前回から」「修正しました」「適用後」「修正の要約」を含めてはいけません。
• 改善を示す根拠として認められるのは、現在の .tex ソースとコンパイル済み PDF のみです。
• ファイル内で確認できない修正について、レビュアーに伝えてはいけません。
• クラッシュ復旧のために復旧メタデータが必要な場合は、返された threadId を保存します。ただし、レビューの文脈を引き継ぐために使用してはいけません。

デバッグのために従来の文脈引き継ぎ動作を明示的に使いたい場合のみ、REVIEWER_BIAS_GUARD = false に設定します。

ワークフロー

ステップ 0：原本を保存する

cp paper/main.pdf paper/main_round0_original.pdf

ステップ 1：論文のテキストを収集する

すべてのセクションファイルを連結し、レビュー用プロンプトに渡す単一のテキストブロックを作成します。

# Collect all sections in order
for f in paper/sections/*.tex; do
    echo "% === $(basename $f) ==="
    cat "$f"
done > /tmp/paper_full_text.txt

ステップ 2：第 1 ラウンドのレビュー

論文の全文とコンパイル済み PDF を GPT-6-Astra xhigh に送信します。

まずこのレビュアー枠を確保してください。以下は backend=codex の例です。

mcp__codex__codex:
  model: gpt-6-astra
  config: {"model_reasoning_effort": "xhigh"}
  prompt: |
    You are reviewing a [VENUE] paper. Please provide a detailed, structured review.

    Judge claim calibration in BOTH directions. Recommend narrowing only when the
    current scope or modality exceeds the evidence; do not ask for extra hedges
    around a supported result. Flag stacked hedges, self-defence ("we do not
    claim"), instruction confessions ("we do not address X"), and generic caveats
    outside Limitations as writing defects to remove. Tone fixes must never alter
    facts, negation, modality, scope, comparison direction, or numbers.
    Also flag narrative defects: a progress-report structure ("we first tried
    A, then B"), a story built on a metric the method loses, results narrated
    as defeats ("underperforms", "fails to surpass") instead of explained as a
    goal difference or tradeoff, experiments with no argumentative duty, an
    abstract or introduction that opens on background or implementation
    instead of problem -> gap -> idea -> strongest result, and a conclusion
    that ends on new self-negation. The fix is reframing and cutting where
    the evidence supports the reframing; a genuine weakness is stated
    neutrally and kept in Limitations. Never delete unfavorable numbers from
    tables, and never dress a weakness as a tradeoff.

    ## Paper Files:
    - LaTeX source: [list all section .tex files]
    - Compiled PDF: paper/main.pdf
    - Figures: [list figure files]

    Read BOTH the LaTeX source (for content/logic) AND the compiled PDF (for visual presentation).

    ## Review Instructions
    Please act as a senior ML reviewer ([VENUE] level). Provide:
    1. **Overall Score** (1-10, where 6 = weak accept, 7 = accept)
    2. **Summary** (2-3 sentences)
    3. **Strengths** (bullet list, ranked)
    4. **Weaknesses** (bullet list, ranked: CRITICAL > MAJOR > MINOR)
    5. **For each CRITICAL/MAJOR weakness**: A specific, actionable fix
    6. **Missing References** (if any)
    7. **Visual Review** (from the PDF):
       - Figure quality: readable? labels legible? colors distinguishable in grayscale?
       - Figure-caption alignment: does each caption match its figure?
       - Layout: orphaned headers, awkward page breaks, figures far from references?
       - Table formatting: aligned columns, consistent decimals, bold for best results?
       - Visual consistency: same color scheme across all figures?
    8. **Verdict**: Ready for submission? Yes / Almost / No

    Focus on: theoretical rigor, claims vs evidence alignment, writing clarity,
    self-containedness, notation consistency, AND visual presentation quality.

第 2 ラウンド用に threadId を保存します。

ステップ 2b：人による確認ポイント（有効な場合）

HUMAN_CHECKPOINT = false の場合はスキップします。

レビュー結果を提示し、ユーザーの入力を待ちます。

📋 Round 1 review complete.

Score: X/10 — [verdict]
Key weaknesses (by severity):
1. [CRITICAL] ...
2. [MAJOR] ...
3. [MINOR] ...

Reply "go" to implement all fixes, give custom instructions, "skip 2" to skip specific fixes, or "stop" to end.

/auto-review-loop と同様に、ユーザーの応答を解析します：承認／個別の指示／スキップ／停止。

ステップ 3：ラウンド 1 の修正を実施する

レビューを解析し、重要度に応じて修正を実施します。

優先順位：

1. CRITICAL の修正（前提の不一致、内部矛盾）
2. MAJOR の修正（過大な主張、内容の欠落、表記の問題）
3. MINOR の修正（時間があれば）

編集許可リストによるゲート（設定されている場合）： EDIT_WHITELIST が設定されている場合、提案された編集を適用する前に、「Optional: Edit Whitelist」セクションに従って、対象パスを allowed_paths／forbidden_paths と照合し、新しい行の差分を forbidden_operations と照合してください。却下した内容は PAPER_IMPROVEMENT_LOG.md の ## Rejected by edit_whitelist (Round 1) の下に、ファイル、理由（path または operation）、該当するパターン、元のレビュアーの懸念を記録します。残りの編集を続行してください。却下によってラウンドを中断してはいけません。ラウンドの最後に、却下の概要を示してください。

修正を適用する前に： 主張を証拠に合わせて調整し、直接的に述べてください。一般的な留保事項は「Limitations」にのみ記載します。執筆上の指示は決して論文の内容に含めません。文体の編集によって、論文が把握している事実を変えてはいけません。

一般的な修正パターン：

問題	修正パターン
前提とモデルの不一致	前提をモデルに合うように書き換え、その隔たりを埋める形式的な命題を追加する
実際に過大な主張	主張そのものを、裏付けられる範囲や様相に限定する。範囲、比較、集約の問題を修正せずに、響きが柔らかい類義語に置き換えてはならない
裏付けのある主張に留保が重ねられている	冗長な留保を取り除き、主張を正しくする範囲の限定は残す
一般的な留保事項が散在している	「Limitations」にまとめ、重複を削除する
成績の悪い指標を軸にした論旨、または結果を敗北として説明している	論文が勝る点を軸に再構成する。証拠が裏付ける場合は、差を目標の違いやトレードオフとして説明する。そうでなければ中立的に述べ、主張の範囲を限定する。表の数値はすべて残す
議論上の役割がない実験	削除、短縮、付録への移動、または手法、メカニズム、対象シナリオでの価値を証明する、あるいは別の説明を排除するよう再設計する
指標の不足	パラメーター数と留保事項を正確に示した定量表を追加する
自己完結していない定理	依存関係をすべて列挙した「解釈」の段落を追加する
表記の混乱	混同される記号を全体で改名し、「表記」の段落を追加する
参考文献の不足	references.bib に追加し、適切な箇所で引用する
理論と実践の隔たり	理論を理想化されたものとして明示し、合成データによる検証の小節を追加する
証明の欠落（理論論文）	PROOF_AUDIT.md がまだ存在しない場合は /proof-checker を実行し、FATAL／CRITICAL の問題を修正する
文章の冗長さ／受動態	sciwrite の 5 段階監査を適用する：冗長さの抽出 → 能動態 → 文の構成 → キーワードの一貫性 → 数値の整合性。「paper-write」のステップ 5 を参照
数値の不一致（論文と結果）	PAPER_CLAIM_AUDIT.md が存在しない場合は /paper-claim-audit を実行し、number_mismatch または aggregation_mismatch の主張を修正する
キーワードの不統一	「バナナルール」：Methods で「肥満グループ」と記載した場合、Results で「体重の重いグループ」と記載してはいけません。主要な用語を抽出し、すべてのセクションで一貫していることを確認する

ステップ 4：ラウンド 1 を再コンパイルする

cd paper && latexmk -C && latexmk -pdf -interaction=nonstopmode -halt-on-error main.tex
cp main.pdf main_round1.pdf

確認事項：未定義の参照が 0 件、未定義の引用が 0 件。

Step 4.5: 再記述回帰テスト

再コンパイルのたびに、定理の記述の一貫性チェックを再実行し、修正ラウンドで付録との不整合が再発しないようにします。Step 4 の後と Step 7 の後、最終フォーマットチェックの前に実行してください。

対象範囲

• 証明本文ではなく、定理／補題／命題／系の記述のみを比較します。
• main.tex の入力順に従ってファイルを分類します。\appendix より前のファイルは本文、\appendix より後のファイルは付録です。

正規化された比較ロジック

• コメント、\label{...}、\ref{...}、\eqref{...}、\cite...{...}、および空白のみの差異を除去します。
• \emph{}、\textbf{}、\textit{}、\mathrm{}、\mathbf{}、\mathcal{}、\operatorname{} など、書式設定のみを行うマクロは中身に置き換えます。
• 量化子、場合分け、仮定、定義済みオブジェクトのリテラル名は保持します。
• 定理ラベルがある場合はラベルで、ない場合は定理の種類と出現順で比較します。
• 仮定、場合分け、量化子の順序、用語（stationary と terminal）に変更があれば、記述の不整合として検出します。

python3 - <<'PY'
import re
def normalize(s):
    s = re.sub(r'%.*', '', s)
    s = re.sub(r'\\label\{[^}]*\}', '', s)
    s = re.sub(r'\\(?:ref|eqref|cref|Cref|cite[a-zA-Z]*)\{[^}]*\}', '', s)
    s = re.sub(r'\\(?:emph|textbf|textit|mathrm|mathbf|mathsf|mathcal|operatorname)\{([^{}]*)\}', r'\1', s)
    s = re.sub(r'\\begin\{[^}]+\}|\\end\{[^}]+\}', '', s)
    s = re.sub(r'\s+', ' ', s)
    return s.strip().lower()
# Compare normalized theorem blocks from the current main-body files
# against their appendix restatements. Any mismatch blocks completion.
PY

実証的な動機： 実際の投稿時に、本文では重要な定理が複数の場合に分けて記述されている一方、付録では単一の場合のみを述べていました。また、重要な変数の名前が本文と付録で異なっていました。自動チェックで回帰を検出できなかったため、修正ラウンドを重ねるうちに、こうした不整合が何度も再発しました。

任意の詳細チェック：/proof-checker --restatement-check

上記のインライン Python チェックはデフォルトで使用され、通常の本文と付録の一貫性チェックには十分です。より広範囲を確認する場合は、/proof-checker --restatement-check（PR #189 で追加）も実行できます。このチェックでは、比較対象が次のように拡張されます。

• 要約表、概要、「Key Contributions」のリスト、考察セクションにおける再記述（本文と付録の比較だけではありません）。
• レビュアーによって分類された、名前付きの 6 種類の不整合パターン：conditional_loss、scope_change、quantifier_loss、regime_envelope_change、constant_change、variable_rename。
• PROOF_AUDIT.json の details.restatement_drift[] として出力される構造化された検出結果。後続のツールや監査記録で利用できます。

これはあくまで補助的なチェックです。インラインの Step 4.5 チェックが引き続きデフォルトであり、ループの各ラウンドで実行されます。（a）本文と付録以外の箇所間での不整合（たとえば、概要で定理の記述を過度に主張している場合）が疑われるとき、または（b）単なる文字列の不一致ではなく、レビュアーが評価する不整合パターンを確認したいときは、/proof-checker --restatement-check の実行を検討してください。両方を実行することもできます。両者は独立しており、インラインチェックは文字列の不一致を即座に検出し、proof-checker の処理は意味上の分類に基づく不整合を明らかにします。

Step 5: 第 2 ラウンドのレビュー

REVIEWER_BIAS_GUARD = true（デフォルト）の場合、第 2 ラウンドでは新しい mcp__codex__codex スレッドを使用します。プロンプトの送信に第 1 ラウンドの threadId を再利用しないでください。返された threadId は復旧用の記録としてのみ保存してください。

まずこのレビュアー枠を解決してください。以下は backend=codex の例です。

mcp__codex__codex:
  model: gpt-6-astra
  config: {"model_reasoning_effort": "xhigh"}
  prompt: |
    You are reviewing a [VENUE] paper. This is a fresh, zero-context review.

    Judge claim calibration in BOTH directions. Recommend narrowing only when the
    current scope or modality exceeds the evidence; do not ask for extra hedges
    around a supported result. Flag stacked hedges, self-defence ("we do not
    claim"), instruction confessions ("we do not address X"), and generic caveats
    outside Limitations as writing defects to remove. Tone fixes must never alter
    facts, negation, modality, scope, comparison direction, or numbers.
    Also flag narrative defects: a progress-report structure ("we first tried
    A, then B"), a story built on a metric the method loses, results narrated
    as defeats ("underperforms", "fails to surpass") instead of explained as a
    goal difference or tradeoff, experiments with no argumentative duty, an
    abstract or introduction that opens on background or implementation
    instead of problem -> gap -> idea -> strongest result, and a conclusion
    that ends on new self-negation. The fix is reframing and cutting where
    the evidence supports the reframing; a genuine weakness is stated
    neutrally and kept in Limitations. Never delete unfavorable numbers from
    tables, and never dress a weakness as a tradeoff.
    Ignore any prior review rounds, prior fix lists, or executor explanations.
    Judge the paper only from the current LaTeX source and compiled PDF.

    ## Paper Files:
    - LaTeX source: [list all section .tex files]
    - Compiled PDF: paper/main.pdf
    - Figures: [list figure files]

    Read BOTH the LaTeX source (for content/logic) AND the compiled PDF (for visual presentation).

    ## Review Instructions
    Please act as a senior ML reviewer ([VENUE] level). Provide:
    1. **Overall Score** (1-10, where 6 = weak accept, 7 = accept)
    2. **Summary** (2-3 sentences)
    3. **Strengths** (bullet list, ranked)
    4. **Weaknesses** (bullet list, ranked: CRITICAL > MAJOR > MINOR)
    5. **For each CRITICAL/MAJOR weakness**: A specific, actionable fix
    6. **Missing References** (if any)
    7. **Visual Review** (from the PDF):
       - Figure quality: readable? labels legible? colors distinguishable in grayscale?
       - Figure-caption alignment: does each caption match its figure?
       - Layout: orphaned headers, awkward page breaks, figures far from references?
       - Table formatting: aligned columns, consistent decimals, bold for best results?
       - Visual consistency: same color scheme across all figures?
    8. **Verdict**: Ready for submission? Yes / Almost / No

    Focus on: theoretical rigor, claims vs evidence alignment, writing clarity,
    self-containedness, notation consistency, and visual presentation quality.

REVIEWER_BIAS_GUARD = false（レガシーなデバッグ時のみ）の場合は、保存した threadId を使って mcp__codex__codex-reply を使用します。これは推奨される方法ではありません。

ステップ 5.5：論点を崩す演習（理論中心／スコープに関する主張が多い論文のみ）

論文が理論中心（ソース内に \begin{theorem}|\begin{lemma}|\begin{proposition}|\begin{corollary} 環境が 5 つ以上ある）であるか、タイトル／概要にスコープまたは一般性に関する明示的な主張があり、かつ最終の予定ラウンド（current_round == MAX_ROUNDS）の場合にのみ実行します。

/kill-argument に委任します — 正式な実装は skills/kill-argument/SKILL.md にあります（2026 年 5 月に抽出）。このステップでは Attack-and-Adjudication プロンプトテンプレートを再実装しません。代わりに、スキルを呼び出して出力を読み取ります。

# Invoke the canonical adversarial-review primitive on the current paper.
# /kill-argument runs two fresh-thread codex gpt-6-astra ultra calls and writes
# KILL_ARGUMENT.{md,json} into the paper directory. It is detect-only —
# it never edits the paper itself.
/kill-argument "$PAPER_DIR"

# Read the structured verdict.
KILL_VERDICT=$(jq -r '.verdict' "$PAPER_DIR/KILL_ARGUMENT.json")
KILL_REASON=$(jq -r '.reason_code' "$PAPER_DIR/KILL_ARGUMENT.json")

マージ規則（auto-loop の責任です — /kill-argument 自体は検出のみを行います）：

• KILL_ARGUMENT.json から details.decomposed_points を読み取ります。
• severity_if_unresolved == "critical" で、verdict == "still_unresolved" または verdict == "partially_answered" の各論点について、次のように処理します。
  • Round 2 の弱点リストと意味的な重複がないか確認します（類似度のしきい値は約 85%）。
  • 新規の論点であれば、推奨される修正をアクションの説明として Step 6 の修正リストに追加します。
• 判定結果が answered_by_current_text の場合は、引用されたファイルと行の根拠を自分で検証してから、既存の弱点項目の評価を下げます。
• KILL_ARGUMENT.md とマージの判断の両方を PAPER_IMPROVEMENT_LOG.md に記録します。
• HUMAN_CHECKPOINT = true の場合は、ユーザーに続行を求める前に、マージした指摘事項をチェックポイントの概要に含めます。

このフェーズの結果は Step 6 に直接反映されます。マージした指摘事項は、最終的な再コンパイルの前に反映されていなければなりません。

/kill-argument が verdict: NOT_APPLICABLE を返した場合（論文がこの確認を必要とするほど理論中心でもスコープに関する主張が多くもない場合）、Step 5.5 全体をスキップして Step 6 に進みます。BLOCKED または ERROR が返された場合は、理由を PAPER_IMPROVEMENT_LOG.md に記録し、マージを行わずに進みます — 実行できない敵対的チェックでループを停止させてはいけません。

実証的な動機： 実際の投稿作業では、標準的な改善を何ラウンドか行った後（スコア 7～8／10）、kill-argument 演習によって、それまでのレビューでは見つからなかった論述上の弱点が明らかになりました（例：設定が真に一般的というより、ほぼ条件付きであることや、ベースラインが実システムに対して無関係であることなど）。著者の反論を受け、概要と考察でスコープに関する限定を明示する必要が生じました。

ステップ 5b：人によるチェックポイント（有効な場合）

HUMAN_CHECKPOINT = false の場合はスキップします。 Step 2b と同様に、Round 2 のレビューを提示し、ユーザーの入力を待ちます。

ステップ 6：Round 2 の修正を実施する

Step 3 と同じ手順です。Round 2 での一般的な修正は次のとおりです。

• 理論を検証するための、制御された合成実験を追加する
• 両方向から較正を再確認します。根拠を超える主張は適切に範囲を狭め、裏付けのある主張は明確に述べ、散在する一般的な注意書きを「Limitations」にまとめます。また、証拠によってすでに裏付けられている主張を再び弱めないようにします。
• 非形式的な論証を形式化します（例：切り詰めから形式的な命題へ）
• 重大な制約が欠けている場合に限り、「Limitations」をより具体的にします

編集許可リストのゲート（設定されている場合）： Step 3 と同様に、EDIT_WHITELIST が設定されている場合は、提案された編集を適用する前にパスと禁止操作のチェックを実行します。却下された編集は PAPER_IMPROVEMENT_LOG.md の ## Rejected by edit_whitelist (Round 2) に記録し、ループを続行します。ラウンドの最後に却下内容の概要を提示します。

ステップ 7：Round 2 を再コンパイルする

cd paper && latexmk -C && latexmk -pdf -interaction=nonstopmode -halt-on-error main.tex
cp main.pdf main_round2.pdf

ステップ 8：フォーマットチェック

最終再コンパイル後、位置情報を考慮したフォーマット準拠チェックを実行します。

# If the log lacks file/line data, rerun the final compile once with -file-line-error.
cd paper && latexmk -pdf -file-line-error -interaction=nonstopmode -halt-on-error main.tex

# 1. Page count vs venue limit
PAGES=$(pdfinfo paper/main.pdf | grep Pages | awk '{print $2}')
echo "Pages: $PAGES (limit: 9 main body for ICLR/NeurIPS)"

# 2. Duplicate labels: HARD BLOCK
DUP_LABELS=$(grep -Rho "\\\\label{[^}]*}" paper/main.tex paper/sections 2>/dev/null | sort | uniq -d || true)
if [ -n "$DUP_LABELS" ]; then
    echo "Duplicate labels found (BLOCKING):"
    echo "$DUP_LABELS"
fi

# 3. Overfull warnings with location classification
OVERFULLS=$(grep -n "Overfull \\\\hbox" paper/main.log 2>/dev/null || true)

# Main body = source files before \appendix in main.tex.
# Appendix = source files after \appendix, or files whose path contains "appendix".
# Bibliography = paper.bbl, references.bib, or bibliography-generated output.
MAIN_BODY_OVERFULL=$(echo "$OVERFULLS" | grep -v -E 'appendix|paper\.bbl|references\.bib' || true)
APPENDIX_OVERFULL=$(echo "$OVERFULLS" | grep -E 'appendix' || true)
BIB_OVERFULL=$(echo "$OVERFULLS" | grep -E 'paper\.bbl|references\.bib' || true)

echo "Main-body overfulls (any size BLOCKS):"
echo "$MAIN_BODY_OVERFULL"
echo "Appendix overfulls (>10pt blocks):"
echo "$APPENDIX_OVERFULL"
echo "Bibliography overfulls (>20pt blocks):"
echo "$BIB_OVERFULL"

停止基準：

• 重複したラベルがある場合、完了できません。
• 本文にオーバーフルが1つでもある場合、サイズにかかわらず完了できません。
• 付録のオーバーフルは、10ptを超える場合、または目に見える形ではみ出している場合にのみ、完了を妨げます。
• 参考文献のオーバーフルは、20ptを超える場合、または目に見える形ではみ出している場合にのみ、完了を妨げます。
• アンダーフルの hbox は、明らかなレイアウト上の問題を引き起こさない限り、警告のままにします。

自動修正パターン（位置情報を考慮）：

問題	修正
数式の本文オーバーフル	aligned／split／multline を使って分割するか、表記を短くします
表の本文オーバーフル	フォントを小さくする、表のサイズを変更する、または複数行に分割します
テキストの本文オーバーフル	表現を言い換えます。グローバルな \sloppy で隠してはいけません
付録のオーバーフル ≤ 10pt	目に見える形ではみ出していない限り、警告のみとします
付録のオーバーフル > 10pt	はみ出しが目に見える場合は、同じ修正を適用します
参考文献のオーバーフル ≤ 20pt	不正なエントリが原因の場合、またははみ出しがある場合を除き、警告のみとします
参考文献のオーバーフル > 20pt	不正なエントリ、URL、または DOI のフォーマットを修正します
ページ数の上限超過	内容を付録に移す、表を圧縮する、図のサイズを小さくする

位置情報に基づく解釈：

• -file-line-error ログに報告されたソースファイルに基づいて分類します。
• 警告を分類できない場合は本文として扱い、修正します。

経験に基づく理由： 実際の投稿作業では、付録の証明に100ptを大きく超えるものを含む、数十件のオーバーフル hbox 警告が、複数回の改善を経ても残っていました。以前の一律な「オーバーフルが 10pt を超えたら停止」というルールは緩すぎ、場所の違いを考慮していなかったためです。

ステップ 9：結果を記録

論文のディレクトリに PAPER_IMPROVEMENT_LOG.md を作成します。

# Paper Improvement Log

## Score Progression

| Round | Score | Verdict | Key Changes |
|-------|-------|---------|-------------|
| Round 0 (original) | X/10 | No/Almost/Yes | Baseline |
| Round 1 | Y/10 | No/Almost/Yes | [summary of fixes] |
| Round 2 | Z/10 | No/Almost/Yes | [summary of fixes] |

## Round 1 Review & Fixes

<details>
<summary>GPT-6-Astra xhigh Review (Round 1)</summary>

[Full raw review text, verbatim]

</details>

### Fixes Implemented
1. [Fix description]
2. [Fix description]
...

## Round 2 Review & Fixes

<details>
<summary>GPT-6-Astra xhigh Review (Round 2)</summary>

[Full raw review text, verbatim]

</details>

### Fixes Implemented
1. [Fix description]
2. [Fix description]
...

## PDFs
- `main_round0_original.pdf` — Original generated paper
- `main_round1.pdf` — After Round 1 fixes
- `main_round2.pdf` — Final version after Round 2 fixes

ステップ 9：まとめ

ユーザーに次の内容を報告します：

• スコア推移表
• 各ラウンドで修正した CRITICAL／MAJOR／MINOR の問題の数
• 最終ページ数
• 残っている問題（あれば）

Feishu 通知（設定されている場合）

各ラウンドのレビュー後と最終完了時に、~/.claude/feishu.json を確認します：

• 各ラウンド後：review_scored を送信します — 「ラウンド N：X/10 — [主な変更点]」
• 最終ラウンド後：pipeline_done を送信します — スコア推移表 + 最終ページ数
• 設定ファイルが存在しない場合、またはモードが "off" の場合：完全にスキップします（何もしません）

出力

paper/
├── main_round0_original.pdf    # Original
├── main_round1.pdf             # After Round 1
├── main_round2.pdf             # After Round 2 (final)
├── main.pdf                    # = main_round2.pdf
└── PAPER_IMPROVEMENT_LOG.md    # Full review log with scores

主要なルール

• 大きなファイルの処理：ファイルサイズが原因で Write ツールが失敗した場合は、直ちに Bash（cat << 'EOF' > file）を使ってチャンク単位で書き込みを再試行してください。ユーザーに許可を求めず、何も伝えずに実行してください。

• すべての PDF バージョンを保持する — ユーザーは推移を比較する必要があります

• レビューの生テキスト全体を保存する — GPT-6-Astra の回答を要約または途中で切り詰めないでください

• レビュアーの独立性（ラウンド 2 以降）：REVIEWER_BIAS_GUARD = true（デフォルト）の場合、レビューのラウンドごとに新しい mcp__codex__codex スレッドを使用してください。mcp__codex__codex-reply は使用せず、プロンプトに「前回のラウンド以降」や修正の要約を含めないでください。上記のレビュアー独立性プロトコルのセクションを参照してください。

• 修正後は必ず再コンパイルする — 次に進む前にエラーが 0 件であることを確認してください

• 実験結果を捏造しない — 合成検証では、数値を作り出さず、方法論を説明してください

• 論文の主張を尊重する — 真に過剰な主張は範囲を狭めて修正し、裏付けのない新たな主張を追加しないでください。また、裏付けのある主張は、新たな留保表現で包まずに明確に述べてください

• 全体の一貫性 — 表記を変更したり、主張の範囲を変えたりする場合は、すべてのファイル（要旨、序論、手法、実験、理論の各セクション、結論、表、図のキャプション）におけるすべての言い換えが意味的に一貫するようにしてください。一貫性とは、注意書きの文言をあらゆる箇所にコピーすることではなく、範囲を一致させることです

• 編集ホワイトリストによる却下は記録するものであり、黙って破棄するものではありません — EDIT_WHITELIST が設定されており、パスまたは禁止操作への違反を理由に編集が却下された場合は、ファイル、理由、該当するパターン、元のレビュアーの懸念を PAPER_IMPROVEMENT_LOG.md に必ず追記してください。ループでは各ラウンドの終了時（および HUMAN_CHECKPOINT = true の場合はチェックポイントにも）に却下の概要を報告します。ホワイトリストによる却下を黙って無視しないでください。監査証跡を残すことが、このパラメーターの目的です。

一般的なスコアの推移

実際の理論論文での一連のテストに基づきます。

ラウンド	スコア	主な改善点
ラウンド 0	4/10（内容）	ベースライン：仮定とモデルの不一致、過剰な主張、表記の問題
ラウンド 1	6/10（内容）	仮定を修正し、主張を控えめにし、解釈を追加し、表記を変更
ラウンド 2	7/10（内容）	合成検証、形式的な切り捨て命題、より強い制限事項を追加
ラウンド 3	5→8.5/10（形式）	目玉図を削除し、付録を追加し、結論を圧縮し、はみ出した hbox を修正

3 ラウンドで +4.5 ポイント（内容 2 ラウンド＋形式 1 ラウンド）は、構成はしっかりしているものの粗削りな初稿としては一般的です。投稿時の最終状態では、はみ出した hbox の数が 0 で、投稿先のフォーマットに準拠した長さになっています。

レビューの追跡

mcp__codex__codex または mcp__codex__codex-reply のレビュアー呼び出しの後は毎回、shared-references/review-tracing.md（ポリシー C — フォレンジック）に従ってトレースを保存してください。黙って省略してはいけません。save_trace.sh（shared-references/integration-contract.md §2 に記載された順序で解決）を使用するか、.aris/traces/<skill>/<date>_run<NN>/ にファイルを直接書き込んでください。--- trace: パラメーター（デフォルト：full）に従ってください。