kill-argument

キルアーギュメント演習：敵対的な攻撃・防御レビュー

各レビュアーの担当枠の前に、選択可能なレビュアーに従ってください。 呼び出しを解決 → .aris/reviewer.json → Claude Code のデフォルト（Codex MCP） の順に確認し、正規のヘルパーリゾルバーを通じて reviewer_route.py を使用します。その際、 この担当枠のティア、新しいコンテキスト、ソース／画像入力、決定論的なゲートを維持してください。 以下の Codex の例／ピン留め設定は backend=codex の場合に限り適用されます。他のルートでは、 それぞれ独自の初回呼び出し／応答コントラクトを使用します。ルートと実際に返された ID を保存してください。 選択したレビュアーを利用できない場合は REVIEW_UNAVAILABLE とします。実際の ファミリー／完了状況／スコープに基づいて受け入れ可否を分類してください。レビュアーを伴う子プロセスには、 呼び出し時のレビュアー／モデル／effort の上書き設定を引き継いでください。 生成ワーカーに変更はありません。

🔒 このスキルを /loop、/schedule、CronCreate でラップしないでください。 これは 判定を下すスキルです。敵対的な受け入れ／拒否の判定（攻撃 → 判定）を生成します。 壁時計タイマーで再実行しても、新たな情報は得られません（攻撃内容が変わるのは 論文 が変わったときだけです）。 このスキルに先立つ 外部の待機 をスケジュールしてください。原稿が安定したら → 投稿前にこのスキルを 1 回だけ 実行します。 shared-references/external-cadence.mdを参照してください。

論文の主要な主張に対して、考えられる限り最も強力な拒否の論拠でストレステストを行います：$ARGUMENTS

このスキルの目的

標準的なスコアベースのレビュー（/research-review、/auto-paper-improvement-loop）では、バランスの取れた弱点リストが作られがちです。各弱点にはほぼ同程度の注意が払われ、CRITICAL > MAJOR > MINOR の順に順位付けされます。実際には、この方法では特定の失敗モードを見落とします。それは、査読者が却下理由の段落に書くであろう最も致命的な単一の論拠、つまり、シニアエリアチェアが読めば論文を落とすような一文です。

バランス重視の査読者は、「スコープの過大主張のリスク」を、ほかの 3～5 件の MAJOR と並べて挙げても、断定を避けることがあります。敵対的な査読者には断定が求められます。エリアチェアに 200 語で却下を納得させることだけが、その役割です。

このスキルでは、まず意図的に敵対的なレビューを行います。その後、新たなコンテキストを持つ 2 人目の査読者に、各点を順に反論させ、却下理由を「すでに修正済み／一部修正済み／未解決」のいずれかに分類し、実際に論文の成否を左右する要素を明らかにします。

実証的な背景： 実際の投稿作業では、標準的な改善を何度か繰り返した後（スコア 7～8／10）、このキルアーギュメント演習によって、それまでのレビューで見つからなかった論旨の弱点が明らかになりました（たとえば、設定が真に一般的というより条件付きに近かったことや、ベースラインが実システムには関連性を欠いていたこと）。著者側の反論を通じて、スコアベースのレビューだけでは見えていなかった、要旨と考察における明示的なスコープの限定が必要になりました。

他のレビュー用スキルとの違い

スキル	査読者に求めること	出力
標準的なピアレビュー	「この論文を採点し、弱点を深刻度順に列挙してください」	バランスの取れた弱点リスト
/research-review	「手法と主張について、技術的に詳細なレビューをしてください」	構造化された詳細な批評
/proof-checker	「この定理は実際に証明されていますか？」	証明義務の各段階に対する監査
/paper-claim-audit	「論文に報告されている数値は正確ですか？」	主張ごとの証拠検証
/citation-audit	「引用文献は実在し、適切な文脈で使われていますか？」	各項目の KEEP/FIX/REPLACE/REMOVE
/kill-argument	「最も強力な却下理由の段落を 1 つ書き、その後に反論してください」	攻撃メモ＋各点への反論＋未解決点の提示

このスキルは他のスキルを補完するものであり、置き換えるものではありません。最悪の査読者がどのような段落を書くかを把握したい場合は、標準レビューの後、カメラレディ版の作成や反論の準備に入る前に実行してください。

使用する場面

• /auto-paper-improvement-loop を1～2ラウンド実行してスコアが安定した後、投稿前に使用します。どのような追加修正で、見出しに対する攻撃のギャップを埋められるかを明らかにします。
• 査読への回答を準備する際に、査読者2の最も強い反論を予測し、事前に回答を用意します。
• 実際の定理を過度に単純化している可能性のある、抽象度の高いタイトルを持つ理論論文に使用します（最もよくある不採択につながる攻撃パターンです）。
• 査読者が適用範囲、仮定と主張の不一致、証明義務の欠落、またはエビデンスと見出しのギャップを攻撃する可能性がある論文に使用します。

このスキルは、定理クラスの環境が5つ以上あり、見出しが実際の証明義務に依存する理論論文で最も効果を発揮します。定理のない実証論文には、代わりに /research-review を使用してください。

定数

• REVIEWER_MODEL = gpt-6-astra（デフォルト。最初のモデル機能フォールバックは shared-references/reviewer-routing.md に従い gpt-6.1-sol、gpt-5.4 は明示的なレガシー上書きの場合に限ります）。攻撃／防御／裁定スレッドにおける査読者の推論 effort = ultra（deep-audit tier。機能フォールバックは shared-references/reviewer-routing.md に従い、xhigh を下回らないこと）。Beast-mode の軸プローブは xhigh のままにします。
• CONTEXT_POLICY = fresh（REVIEWER_BIAS_GUARD）。各スレッドは新しい mcp__codex__codex 呼び出しとします。mcp__codex__codex-reply は絶対に使用しないでください。以前の査読要約、修正リスト、または実行者の説明を、どちらのプロンプトにも含めないでください。
• ATTACK_LENGTH = 約200語（250語を超えないこと）。リストではなく、一貫した単一の論旨にします。
• DEFENSE_DECOMPOSITION = 攻撃メモから抽出した、3～7個の独立した不採択理由。それぞれに個別の分類を付けます。
• CLASSIFICATION = answered_by_current_text / partially_answered / still_unresolved。（「修正済み」であることが過去の修正履歴を意味すると裁定者が決めつけないように、この名前を選んでいます。裁定者は新しい査読者と同じように論文を読みます。）
• OUTPUT = 論文ディレクトリ内の、人が読める形式の KILL_ARGUMENT.md と、機械可読形式の KILL_ARGUMENT.json。
• RENDER_HTML = true — true（デフォルト）の場合、レポートの書き込み後に KILL_ARGUMENT.md を HTML に自動レンダリングします。完全な Codex 査読ゲートを使用します（監査クラスの成果物です。完全なレンダリング忠実度チェックは、このスキルのクロスモデル監査の不変条件に適合します。サイドカーの KILL_ARGUMENT.json もレンダラーに渡されます）。false を設定するとスキップします。または — render html: false を渡してください。

ワークフロー

ステップ1：論文ファイルを見つける

論文のディレクトリを特定し、ソースを調べます。

PAPER_DIR="$ARGUMENTS"   # e.g., paper-overleaf/ or paper/
cd "$PAPER_DIR"

# Find the LaTeX entry point
ENTRY=$(grep -lE '^\\documentclass' *.tex 2>/dev/null | head -1)
echo "Entry: $ENTRY"

# Find all source files codex should read
find . -name "*.tex" -not -path "./.git/*" 2>/dev/null
find . -name "*.bib" -not -path "./.git/*" 2>/dev/null
find figures/ -name "*.pdf" -o -name "*.png" 2>/dev/null
ls -la *.pdf 2>/dev/null  # compiled PDF

コンパイル済み PDF が見つからない場合でも、このスキルは .tex ソースのみで実行する必要があります。ただし、存在しない PDF から抽出しようとして査読者の時間を無駄にしないよう、その旨をプロンプトに記載してください。

ステップ2：攻撃メモ（スレッド1、新規 Codex）

mcp__codex__codex（codex-reply ではありません）を呼び出し、以下のプロンプト構造を使用します。

まず、この査読者スロットを解決してください。以下は backend=codex の例です。

mcp__codex__codex:
  model: gpt-6-astra
  config: {"model_reasoning_effort": "ultra"}
  sandbox: read-only
  cwd: <paper directory>
  prompt: |
    You are simulating a hostile NeurIPS / ICLR / ICML reviewer for a paper.
    This is a kill-argument adversarial check — your task is NOT to give a
    balanced review but to construct the **single strongest argument for
    rejecting this paper**.

    ## Files to read
    - LaTeX entry: <ENTRY>
    - All section files under sections/ or wherever they live
    - Macro files (math_commands.tex, etc.)
    - Compiled PDF: <main.pdf> (if available)

    Read the source carefully. Do not consult any prior reviews, fix lists,
    or summaries; this must be a fresh, zero-context adversarial pass.

    ## Your task
    Construct the single best argument to reject this paper in approximately
    200 words. Your goal is to write the worst-case rejection memo a senior
    NeurIPS area chair would produce after reading the paper.

    Focus on these axes (pick the most damaging combination, do not list all):
    1. Theorem validity: are central theorems actually proved as stated?
    2. Assumption-vs-claim mismatch: does the body silently retreat to a
       narrower object than the title/abstract advertise?
    3. Missing proof obligations: is a fundamental lemma invoked but not
       proved (e.g., concentration, generic position, prefactor envelope)
       that the headline depends on?
    4. Limit-order ambiguity: are limits in K/n/d/eps composed in a way the
       paper does not commit to?
    5. Claim-vs-evidence gap: is the empirical/numerical evidence too narrow
       to support the breadth of the stated theorem or take-away?
    6. Scope overclaim: does the title or abstract sell a result substantially
       broader than what the body proves?

    ## Constraints
    - Approximately 200 words total (do NOT exceed 250).
    - Single argument, not a list — pick the most damaging line of attack
      and develop it.
    - Cite specific file:line locations or equation numbers when accusing.
    - Tone: dispassionate but uncompromising. Do NOT hedge. Do NOT acknowledge
      mitigations the paper might have made elsewhere. This is the rejection
      paragraph; the defense gets the next pass.
    - Do NOT reference prior review rounds, fix lists, or any context outside
      the current paper files.

    Output: just the rejection memo, nothing else.

トレース用に返された threadId を保存します。スレッド2には渡さないでください。攻撃メモはそのまま保存します。スレッド2と人が読むレポートの両方で使用します。

ステップ 2.5（任意、beast エフォート）：複数軸への攻撃の振り分け

デフォルトでは無効です。 このスキルの成果物は、最も強力な反論の段落ひとつ、すなわち判定です。そして shared-references/fan-out-pattern.md では、判定を振り分けず、それを裏付ける証拠だけを振り分けることが明示されています。デフォルトの単一の攻撃へのコミットメント（ステップ 2）は意図的なものです。段落ひとつに絞ることで、バランスの取れたリストよりも鋭いフィードバックが得られます（これが存在する理由を参照）。リストに置き換えないでください。

beast エフォートでは、コミットメントを弱めずに、それが根拠とする証拠の幅を広げられます。

1. 軸ごとのプローブ（証拠の幅）。 6 つの攻撃軸（定理の妥当性／仮定と主張の区別／欠落している義務／極限の順序／主張と証拠の区別／スコープの過剰な主張）を、それぞれ個別の新規 codex プローブとして実行し、各軸だけに基づく最も強力な約 120 語の主張を求めます。これらは判定ではなく、証拠の収集です。プローブは xhigh（ultra ではなく）で実行します。委任呼び出しを 6 回逐次実行すると、いずれにせよ ultra ティアのコミットメントで再評価される証拠のためにコストが増大するためです。
   • これらは Claude のサブエージェントではなく、意図的に Agent の許可もありません。 各プローブは新規の mcp__codex__codex 呼び出しです。敵対役はクロスモデル（Claude 以外）でなければなりません。Codex MCP は逐次実行です（codex 呼び出しを並行実行すると停止するため）。そのため、プローブは順番に実行され、ファンアウトの段階ではティア 3 に当たります。これが、kill-argument の allowed-tools に Agent が含まれていない理由です。何も起動せず、codex 呼び出しをつなぐだけです。
2. コミットメント（判定、単一のまま）。 最後に、新規 codex による統合処理で 6 つのプローブと論文を読み、最もダメージの大きい約 200 語の反論段落ひとつにコミットする必要があります。軸は最大 2 つまで選んで統合し、6 つすべてを列挙してはいけません。ステップ 2 のコミットメント要件に変更はありません。プローブは、コミットする前に見落とした軸がないことを確認するためだけのものです。

その後の裁定（ステップ 3）は、デフォルトのフローと同様に、この確定した攻撃に対して実行します。コスト：beast では codex 呼び出しがさらに約 6 回、逐次で追加されます。日常的には使わず、重要度の高い論文の投稿前最終チェックに使用してください。

トレース：各プローブの threadId（axis_probe_thread_ids[]）と統合処理の threadId を、ステップ 2～3 でスレッド ID を保存するのと同様に記録します。ステップ 3 で使用するのは、コミットした攻撃メモであり、6 つのプローブではありません。

ステップ 3：裁定メモ（スレッド 2、攻撃と論文を渡す新規 codex）

2 回目の mcp__codex__codex 呼び出しを実行します（引き続き codex-reply ではありません。スレッド 2 はスレッド 1 の codex 履歴から独立しています）。

まずこの査読者スロットを解決してください。以下は backend=codex の例です。

mcp__codex__codex:
  model: gpt-6-astra
  config: {"model_reasoning_effort": "ultra"}
  sandbox: read-only
  cwd: <paper directory>
  prompt: |
    You are an independent area-chair adjudicator examining whether the
    current paper text answers a hostile reviewer's rejection memo.
    You are NOT the paper's defender — your job is to read the attack
    point-by-point and rule, from the current source files alone,
    whether each point stands or falls. Fresh, zero-context adjudication;
    do not reference any prior reviews / fix lists.

    ## Paper files
    [list paths same as Step 2]

    ## The hostile reviewer's rejection memo (the "attack")
    > <attack memo verbatim from Thread 1>

    ## Your task
    The attack is one continuous argument, but it makes multiple distinct
    rejection points that you must adjudicate separately. Decompose the
    attack into its atomic rejection points (3-7 of them), then for each
    point classify it:

    - answered_by_current_text: the current paper source already mitigates
      this point (cite specific file:line evidence)
    - partially_answered: paper has some response but not enough to refute
      the attack as written
    - still_unresolved: paper has no effective response

    The label `answered_by_current_text` is intentional — "fixed" implies
    history of patching and biases toward optimism. You are reading the
    paper as a reviewer would, with no knowledge of prior round drafts.

    For each rejection point, output:
    ### Point P_n: <short label>
    **Attack claim**: <the specific accusation, ~30 words>
    **Verdict**: answered_by_current_text | partially_answered | still_unresolved
    **Evidence (or lack of)**: <cite file:line, ~50 words>
    **Severity if unresolved**: critical | major | minor
    **If unresolved, recommended fix**: <one specific actionable sentence>

    After per-point analysis, output:

    ## Summary
    Total rejection points: N
    - answered_by_current_text: X
    - partially_answered: Y
    - still_unresolved: Z

    ## Net assessment
    <one short paragraph: would this paper survive a senior area-chair read
    of the attack memo, given only what is in the current source? Be honest —
    if Y or Z > 0 and they hit the headline, say so.>

    ## Top action items (in priority order, max 3)
    1. ...
    2. ...
    3. ...

    ## Constraints
    - Do NOT consult any prior round reviews or fix lists. Adjudication must
      be made strictly from current paper files.
    - If the paper cannot refute a point, do NOT minimize — keep severity
      honest.
    - If a point reflects an author-chosen position (e.g., conscious title
      scope decision), classify as `partially_answered` with a note that the
      position is intentional, AND say whether this position is sustainable
      under the attack — do NOT auto-grade as `answered_by_current_text`
      just because it is intentional.
    - Be specific. No flattery, no hedging, no rationalizing on the paper's
      behalf.

返された threadId を保存してください。

ステップ 4：KILL_ARGUMENT.md と KILL_ARGUMENT.json を作成する

人が読めるレポート <paper-dir>/KILL_ARGUMENT.md を作成します。

# Kill Argument Report — <paper title>

**Date**: <YYYY-MM-DD>
**Reviewer model**: <resolved pair that actually ran — target gpt-6-astra ultra>, fresh threads (no codex-reply)
**Attack thread**: <threadId 1>
**Adjudicator thread**: <threadId 2>
**Verdict**: <PASS / WARN / FAIL / NOT_APPLICABLE / BLOCKED / ERROR> (`reason_code: <...>`)

## Net assessment

<paragraph from adjudicator memo's "Net assessment">

## Attack memo (verbatim)

> <attack memo from Thread 1>

## Adjudication (per-point)

<copy verbatim from Thread 2 — uses labels answered_by_current_text / partially_answered / still_unresolved>

## Top action items

<copy from Thread 2>

## Recommendation

If P_4 (or whatever still_unresolved critical) is research-level, record
it as a known open problem in the conclusion / limitations. If it is
writing-level, queue for next /auto-paper-improvement-loop round.

ARIS Audit Artifact Schema（shared-references/assurance-contract.md）に従って、機械可読な <paper-dir>/KILL_ARGUMENT.json を作成します。

{
  "audit_skill": "kill-argument",
  "verdict": "PASS | WARN | FAIL | NOT_APPLICABLE | BLOCKED | ERROR",
  "reason_code": "<see verdict mapping below>",
  "summary": "<one-line summary, ~80 chars>",
  "audited_input_hashes": {
    "main.tex":                          "sha256:<...>",
    "sec/0.abstract.tex":                "sha256:<...>",
    "sec/<each-section>.tex":            "sha256:<...>",
    "references.bib":                    "sha256:<...>",
    "main.pdf":                          "sha256:<...>"
  },
  "trace_path": ".aris/traces/kill-argument/<date>_run<NN>/",
  "thread_id": "<defense threadId — primary; attack threadId in details>",
  "reviewer_model": "<resolved — the model that actually ran (target: gpt-6-astra)>",
  "reviewer_reasoning": "<resolved — the effort that actually ran (target: ultra)>",
  "generated_at": "<UTC ISO-8601>",
  "details": {
    "attack_thread_id": "<threadId 1>",
    "defense_thread_id": "<threadId 2 — same as top-level thread_id>",
    "attack_memo": "<verbatim>",
    "decomposed_points": [
      {
        "id": "P_1",
        "label": "<short label>",
        "attack_claim": "<...>",
        "verdict": "answered_by_current_text | partially_answered | still_unresolved",
        "evidence": "<file:line citation>",
        "severity_if_unresolved": "critical | major | minor",
        "recommended_fix": "<...>"
      }
    ],
    "counts": {
      "answered_by_current_text": <int>,
      "partially_answered":       <int>,
      "still_unresolved":         <int>
    },
    "net_assessment": "<adjudicator memo's net assessment>",
    "top_action_items": ["...", "...", "..."]
  }
}

ハッシュ対象（audited_input_hashes）：論文からの相対パスを使用し、監査で使用したすべての .tex と、references.bib、および存在する場合はコンパイル済みの main.pdf の sha256 を記録します。検証ツールは verify_paper_audits.sh の実行時にこれらを再ハッシュし、監査の実行後にユーザーが論文を編集していた場合は STALE と判定します。

判定マッピング（すべての（件数、重大度）タプルは、以下のいずれか 1 行にのみ該当する必要があります）。

判定	reason_code	条件
FAIL	unresolved_critical	重大度が critical の still_unresolved が 1 件以上
WARN	unresolved_major_or_minor	重大度が major または minor の still_unresolved が 1 件以上（critical はなし）
WARN	partial_critical_or_repeated_major	still_unresolved が 0 件、かつ重大度が critical または major の partially_answered が 1 件以上
PASS	defense_survives_with_minor_partial_only	still_unresolved が 0 件、かつ partially_answered が 1 件以上で、すべての重大度が minor
PASS	defense_survives	still_unresolved が 0 件、かつ partially_answered が 0 件
NOT_APPLICABLE	not_theory_or_scope_paper	論文内の \begin{theorem|lemma|proposition|corollary} が 2 件未満で、要旨にスコープまたは一般性に関する主張がない
NOT_APPLICABLE	headline_unstable	タイトルまたは要旨が直近 2 回のコミット内で変更された — タイトルと要旨が安定してから再実行してください
BLOCKED	paper_compile_failed	コンパイル済み PDF が存在せず、かつ main.tex のコンパイルも正常に完了しない — 判定にはソースの忠実性が必要です
BLOCKED	source_files_missing	main.tex が見つからない、または sec/*.tex ファイルがない
ERROR	codex_api_error	mcp__codex__codex 呼び出しが失敗した
ERROR	decomposition_parse_failed	判定スレッドから解析可能な項目別の構造が返されなかった
ERROR	trace_save_failed	トレースディレクトリへの書き込みに失敗した

PASS には still_unresolved == 0 が必要です。still_unresolved == 0 の場合でも、重大度が major 以上の partially_answered が 1 件でもあれば、得られる最善の判定は WARN です。PASS にはなりません。

判定は項目別の件数から計算します。防御スレッドにトップレベルの判定を直接出力させないでください（自己採点が可能になってしまいます）。判定マッピングはスキルコードが実行します。

ステップ 5：概要を出力する

ユーザーに対して：

🗡  Kill Argument complete.

  Attack: <one-sentence summary of the rejection thrust>

  Adjudication breakdown:
    answered_by_current_text:   X
    partially_answered:         Y
    still_unresolved:           Z   ← critical: <names>

  Verdict: <PASS / WARN / FAIL / NOT_APPLICABLE / BLOCKED / ERROR>
  Reason:  <reason_code, e.g., defense_survives, unresolved_critical>

  Top action items:
  1. ...
  2. ...
  3. ...

  Full report: <paper-dir>/KILL_ARGUMENT.md

出力要件

• <paper-dir>/KILL_ARGUMENT.md — 人が読めるレポート
• <paper-dir>/KILL_ARGUMENT.json — 機械可読な台帳
• .aris/traces/kill-argument/<date>_runNN/ — スレッドごとの Codex トレース（攻撃メモ＋判定メモ）
• 任意：ユーザーが明示的に要求した場合は修正を適用します。デフォルトでは検出のみを行い、自動変更はしません。
• <paper-dir>/KILL_ARGUMENT.html（RENDER_HTML = true の場合。デフォルトで有効）— /render-html "<paper-dir>/KILL_ARGUMENT.md" --json "<paper-dir>/KILL_ARGUMENT.json" で自動生成する単一ファイルの HTML ビューです。完全なレビューゲートが適用されます。.review.json サイドカーには、レンダリングの忠実性に関する判定が記録されます。ブロック対象外：/render-html が失敗した場合（ヘルパーの不在、Codex MCP の利用不可、ファイル書き込みエラー）、失敗を記録してスキルを完了扱いにします。HTML ビューは利便性のためのものであり、反証レポートの判定に必須ではありません。

主要ルール

• 呼び出しごとに新しいスレッドを使用します。 攻撃と判定の両方で mcp__codex__codex を使用し、codex-reply は使用しません。スレッド 1 とスレッド 2 で Codex のコンテキストを共有してはいけません。
• 過去のコンテキストは一切渡しません。 どちらのスレッドにも、過去のラウンドのレビュー、修正リスト、実行担当者の要約、改善ループのログを渡しません。
• 攻撃では必ず論点を断定します。 引数は 1 つだけで、約 200 語です。「ほかにも検討できる」といった曖昧な表現は避けます。レビュー担当者に最も重大な一文を選ばせることが、この手法の要点です。
• 判定者は問題を過小評価せず、分類します。 論文に有効な対応がなければ、still_unresolved と判定するのが誠実です。根拠が実際にある場合を除き、partially_answered に格下げしてはいけません。
• 著者が選んだ立場（意図的なタイトルの範囲や、限定語を意図的に省いた場合など）は、立場が意図的であることを注記して partially_answered とし、その立場が攻撃に耐えられるかどうかも明記します。意図的であるというだけで、自動的に answered_by_current_text と判定してはいけません。
• 最終判定はスキルが算出し、判定者は算出しません。 Codex スレッドは各論点の分類を出力し、スキルのコードがステップ 4 の表に従って、それらを 6 種類の監査判定のいずれかに対応付けます。判定者が最上位の判定を独自に付けることは決してありません。
• 直接呼び出す場合は検出のみです。 /auto-paper-improvement-loop のステップ 5.5 から呼び出すこともでき、その場合は未解決の指摘が修正リストに統合されます。ユーザーが /kill-argument paper/ を直接実行した場合、出力は情報提供のみであり、対応するかどうかは人間が判断します。自動改善ループ内から呼び出された場合、ループは KILL_ARGUMENT.json を読み取り、既存の弱点リストと重複する項目を除外し、新たな still_unresolved の論点をステップ 6 の修正に取り込みます。/kill-argument 自体が論文ファイルを編集することはありません。

使用しない場合

• 定理やスコープに関する主張のない実証論文 — /research-review のほうが有用です。この場合、スキルは reason_code: not_theory_or_scope_paper とともに NOT_APPLICABLE を出力します。
• 見出しがまだ定まっていない初期段階の草稿 — まず見出しを修正してください。タイトルまたは要旨が直近 2 回のコミット内で変更されている場合、スキルは reason_code: headline_unstable とともに NOT_APPLICABLE を出力します。
• 実験を継続中の論文 — 結果が安定してから実行してください。
• （/auto-paper-improvement-loop のステップ 5.5 では以前、このプロトコルをインラインで実行していました。2026 年 5 月以降は /kill-argument を呼び出して KILL_ARGUMENT.json を読み取る方式に変更されているため、「自動改善ループ内から呼び出さない」という制限はなくなりました。）

レビューの追跡

mcp__codex__codex のレビュアー呼び出しごとに、shared-references/review-tracing.md に従ってトレースを保存してください（ポリシー C — フォレンジック。黙って省略してはいけません）。save_trace.sh（shared-references/integration-contract.md §2 のチェーンに従って解決）を使用するか、.aris/traces/kill-argument/<date>_run<NN>/ にファイルを直接書き込みます。両方のスレッドの生の応答を保存してください。

注記

このスキルは、スコアベースのレビューでは見逃されていた見出しと本文のスコープの不一致を表面化させるうえで有効だとわかったため、2026 年 5 月に /auto-paper-improvement-loop のステップ 5.5 から独立したプリミティブとして切り出されました。攻撃してから反論するパターンがそのまま維持されたのは、「却下理由のメモを書く」ようモデルに求めた場合は「レビューして採点する」よう求めた場合とは質的に異なるフィードバックが得られるという実証的な根拠があったためです。前者は断定を促し、後者は曖昧な表現を招きます。