research-review

外部レビュアーバックエンドによるリサーチレビュー（超高度推論）

🔒 このスキルを /loop、/schedule、または CronCreate でラップしないでください。 このスキルは判定を伴い、複数ラウンドにわたるレビュアースレッドの継続性を保ちながら、複数モデルによるレビュー判定を生成します。外部タイマーで壁時計時間に基づいて判定を再実行すると、新たな情報がないままトークンコストが全額発生し、ラウンド間のレビュアーの記憶が失われます。判定ではなく、判定前の 外部の待機時間 をスケジュールしてください（作業の準備完了 → その後、一度だけレビュー）。shared-references/external-cadence.md を参照してください。

選択した外部レビュアーバックエンドから、推論の深さを最大にして、複数ラウンドにわたるリサーチ作業の批判的レビューを受けます。

定数

• REVIEWER_MODEL = gpt-6-astra — Codex バックエンドのデフォルトモデルで、推論の強度は ultra（詳細監査ティア）です。OpenAI モデルである必要があります（例：gpt-6-astra、gpt-6.1-sol）。手動バックエンドではユーザーが選択したモデルを使用します。OpenAI、Anthropic、Google、DeepSeek、Moonshot/Kimi、Qwen の異なるファミリーに属する、認識済みのモデルである必要があります。
• REVIEWER_BACKEND = codex — デフォルト：Codex MCP（ultra）。reviewer_route.py（--host claude-code --tier deep）を使用して、reviewer-backends.md に従い、— reviewer:、プロジェクトの .aris/reviewer.json、このデフォルトの順に解決します。Gemini/Antigravity、Grok、Claude Code では、以下の各呼び出しでこの契約を使用します。従来の Oracle／手動の契約は reviewer-routing.md に記載されています。選択したルートが利用できない場合でも、通知なしにフォールバックすることはありません。

レビュアー呼び出し規約

レビュアーを呼び出す際は、REVIEWER_BACKEND に応じて分岐します。

REVIEWER_BACKEND ∈ {antigravity, grok, claude-code} の場合： reviewer-backends.md に記載された、最初の呼び出し／返信プロトコルを使用します。 レビュープロンプトは同一のものを使い、プライマリファイルを含む明示的な cwd と、 解決済みのプロバイダー固有のモデル／強度を指定します。継続のために ルート、cwd、セッション ID を保存してください。 Claude Code ブリッジでは DeepSeek が実行される場合があります。報告されたモデルからファミリーを判定してください。

REVIEWER_BACKEND = codex の場合： 新しいレビュー スレッドには mcp__codex__codex を使用します。 フォローアップラウンドには mcp__codex__codex-reply を使用し、threadId を再利用します。

REVIEWER_BACKEND = manual の場合： 新しいレビュー スレッドには、次の内容で mcp__manual_review__review を使用します。 prompt: [Codex に送るものと完全に同一のプロンプト] config: {"model_reasoning_effort": "xhigh", "executor_model": "<実際の実行モデル>", "require_reviewer_model": true} 返された threadId を保存します。 フォローアップラウンドには、次の内容で mcp__manual_review__review_reply を使用します。 threadId: [保存した manual-review の threadId] prompt: [フォローアップ用プロンプト] config: {"model_reasoning_effort": "xhigh", "executor_model": "<実際の実行モデル>", "require_reviewer_model": true}

内容の忠実性：手動レビュアーには、Codex が読むものと実質的に同一のレビューブリーフを提示してください。手動 UI がファイルのアップロード／添付に対応している場合は、同じブリーフファイルを使用してください。対応していない場合は、リモートの Web UI からローカルファイルシステムのパスを読み取れないため、ブリーフの内容をインラインで貼り付けてください。レビューの追跡は両方のバックエンドに同様に適用されます。

コンテキスト：$ARGUMENTS

前提条件

• 選択した MCP が利用可能である必要があります。デフォルトの Codex MCP Server の場合：

  claude mcp add codex -s user -- python3 "$HOME/aris_repo/mcp-servers/codex-exec/server.py"   # your ARIS clone's path
  

• これにより、Claude Code から mcp__codex__codex および mcp__codex__codex-reply ツールを利用できるようになります

ワークフロー

ステップ 1：リサーチのコンテキストを収集する

外部レビュアーを呼び出す前に、包括的なブリーフィングをまとめます。

1. プロジェクトの説明資料（例：STORY.md、README.md、論文の草稿）を読む
2. 主要な知見や実験履歴を把握するため、メモリ／ノートファイルを読む
3. 中心的な主張、方法論、主な結果、既知の弱点を特定する

ステップ 2：初回レビュー（ラウンド 1）

選択したバックエンドを使い、詳細で推論を最大限に行うプロンプトを送信します。 codex バックエンドでは、MCP のペイロードを短く保ちます。ブリーフィング全文を RESEARCH_REVIEW_REQUEST.md に書き込み、そのファイルを Codex に参照させてください。

codex バックエンドの場合：

mcp__codex__codex:
  model: gpt-6-astra
  config: {"model_reasoning_effort": "ultra"}
  prompt: |
    Read the review brief at <absolute path to RESEARCH_REVIEW_REQUEST.md>.
    Executor notes are not evidence beyond the files they cite, so verify the
    referenced artifacts before judging.
    Please act as a senior ML reviewer (NeurIPS/ICML level). Start from the
    assumption that the work is broken somewhere — your job is to find where.
    Be adversarial. Trust nothing the author tells you — verify everything
    yourself. Identify:
    1. Logical gaps or unjustified claims
    2. Missing experiments that would strengthen the story
    3. Narrative weaknesses
    4. Whether the contribution is sufficient for a top venue

    === SCOPE LIMITS (these bound what you PROPOSE, never what you look for) ===
    Report anything that is actually wrong here — including a rare-looking case, if
    this repo actually produces it. Then keep the fix in scope:
    1. This is a RESEARCH-WORKFLOW tool, not a security paper. Verification is
       welcome; over-defense is not. Assume a cooperating operator on their own
       machine — a malicious local user is NOT in the threat model.
    2. Do NOT propose SHA / hash / content-fingerprint / digest-binding schemes.
       Reporting a real defect in hashing code that already exists is fine.
    3. NO speculative machinery: do not add feature flags, migration frameworks,
       compat layers, wrappers, pins, or similar mechanisms unless evidence shows
       a current repo defect they fix or an explicit existing invariant they must
       preserve. "Load-bearing", "compatibility", and "not scaffolding" are labels,
       not evidence. Point to the failing path/artifact or invariant, and check the
       proposal's factual premises, such as whether a named package version exists.
    4. NO corner-case obsession: exotic encodings, symlink races, RTL text and
       millisecond races are out of scope unless you can show the case arises here.
    5. Where a rubric or checklist is genuinely needed, do not over-mechanize
       judgement. A clear sentence a human reads beats a scored table nobody
       maintains.
    Exception: code that runs remote commands, starts a network service, or installs
    an MCP server runs on the user's machine with their credentials — trust-boundary
    findings there are in scope and the default is strict.
    Say plainly when something is correct. Do not manufacture findings.
    Be brutally honest. If, after genuinely trying to break it, the work
    holds up and is ready, say so clearly.

Antigravity、Grok、または Claude Code の場合は、選択した初回呼び出しツールを使って同じプロンプトを送信してください。Codex の config を別のツールにコピーしないでください。応答を解釈する前に、正常に完了したことと、実際に対象ファイルが網羅されていることを確認してください。

レビュー用ブリーフには、調査の背景全体、具体的な質問、およびレビュアーが確認すべき主要な成果物／生データのパスを含めてください。

手動バックエンドの場合： 同じブリーフの内容を指定して mcp__manual_review__review を使用してください。手動レビュー UI で添付ファイルをサポートしている場合は、RESEARCH_REVIEW_REQUEST.md を添付してください。サポートしていない場合は、ブリーフをインラインで貼り付けてください。返された threadId を保存してください。

ステップ 3：反復対話（ラウンド 2～N）

codex バックエンドの場合：返された threadId を指定して mcp__codex__codex-reply を使用してください。 manual バックエンドの場合：同じ threadId を指定して mcp__manual_review__review_reply を使用してください。 Antigravity、Grok、または Claude Code の場合：保存したルートの継続プロトコルを reviewer-backends.md で確認してください。モデルと cwd を維持し、Claude では cwd とツールも繰り返し指定してください。 会話を続けるには、適切なツールを使用してください。Codex のフォローアップラウンドでは、RESEARCH_REVIEW_ROUND_2.md のような更新版ブリーフを作成し、パスのみを送信してください：

mcp__codex__codex-reply:
  threadId: [saved reviewer threadId from Step 2]
  # replies inherit the thread's model/effort (gpt-6-astra ultra)
  prompt: |
    Read the updated review brief at <absolute path to
    RESEARCH_REVIEW_ROUND_2.md>.
    Focus on unresolved weaknesses and whether the revision actually fixed them.

手動のフォローアップラウンドでは、可能であれば同じ更新版ブリーフを添付してください。添付できない場合は、インラインで貼り付けてください。

各ラウンドで：

1. 批判に応答し、根拠や反論を示します
2. 的を絞った追加質問を、最も対応可能な指摘について行います
3. 具体的な成果物を依頼します：実験計画、論文のアウトライン、主張マトリックス

主なフォローアップのパターン：

• 「X を Y として再構成した場合、評価は変わりますか？」
• 「懸念 Z を解消するための最小限の実験は何ですか？」
• 「追加実験の最小パッケージを設計してください（GPU 週あたりの採択可能性向上が最大となるもの）」
• 「NeurIPS／ICML の模擬査読とスコアを作成してください」
• 「実験結果の各パターンについて、結果から主張への対応マトリックスを作成してください」

ステップ 4：収束

次の条件を満たしたら反復を終了します：

• 中心的な主張とその根拠の要件について、双方が合意している
• 具体的な実験計画が確立されている
• 論旨の構成が定まっている

ステップ 5：すべてを記録する

やり取り全体と結論を、プロジェクトのルートにあるレビュー文書に保存します：

• ラウンドごとの批判と応答の要約
• 主張、論旨、実験に関する最終合意
• 主張マトリックス（結果の各パターンで認められる主張）
• 優先順位付き TODO リストと推定計算コスト
• 議論した場合は論文のアウトライン

レビューの重要な結論を、プロジェクトのメモリ／ノートにも反映してください。

コンポーズモード — — composed: <canonical-report-path> を指定して呼び出された場合（/idea-discovery のようなオーケストレーターから渡されます）、プロジェクトのルートに単独のレビュー .md を書き出さないでください。生の会話はすでに .aris/traces/… に保存されています（下記の レビューのトレース を参照。監査用コピーはすべてのモードで保持されます）。レビューの結論（合意事項、主張マトリックス、優先順位付き TODO）をオーケストレーターの正式レポートに取り込み、そこにトレースのパスを記載してください。デフォルト（— composed: ディレクティブなし）：上記のとおり、単独のレビュー文書を書き出してください。 レポートファイルが存在するだけでコンポーズモードだと推測してはいけません。詳細なルール： shared-references/output-composition.md。

主なルール

• Codex のデフォルトルートでは、model: gpt-6-astra と config: {"model_reasoning_effort": "ultra"}（ディープ監査ティア。機能上のフォールバックは reviewer-routing.md に従い、xhigh を下回らない）を固定してください。選択したその他のルートでは、解決済みのモデル／推論レベルを使用してください。
• manual では、上記の識別情報を含む設定を使用してください。ツールのフィールドは各プロバイダーの契約に属するため、ブリッジ間でペイロードをコピーしないでください。
• レビューの概要には、包括的なコンテキストを記載してください。絶対パスを渡せば Codex はローカルファイルを読めますが、通常、手動レビュー担当者は読めないため、同じ概要を添付するか貼り付けてください。
• 弱点を隠さず、正直に伝えてください。隠すと、フィードバックの質が低下します。
• 同意できない批判には反論しつつ、妥当な批判は受け入れてください。
• 実行可能なフィードバックに重点を置いてください。「どのような実験を行えば改善できるか」を考えてください。
• 将来的に再開できるよう、threadId を記録してください。
• レビュー文書は自己完結している必要があります（会話を読まなくても理解できる内容にしてください）。

プロンプトテンプレート

初回レビューの場合：

「完全な ML 研究プロジェクトを提示するので、批判的にレビューしてください。NeurIPS／ICML レベルのシニア ML レビュアーとして対応してください……」

実験設計の場合：

「GPU 週あたりの採択可能性向上が最大になる、追加実験の最小構成を設計してください。計算リソースは以下のとおりです：[説明]。設定を具体的に示してください。」

論文の構成の場合：

「セクションごとの主張と図の計画を含む、具体的な論文のアウトラインを作成してください。」

主張マトリックスの場合：

「結果と主張の対応マトリックスを作成してください。実験 X と Y の各結果に対して、どの主張が許容されるかを示してください。」

模擬レビューの場合：

「以下を含む NeurIPS の模擬レビューを作成してください：概要、強み、弱み、著者への質問、スコア、確信度、採択に近づくために必要なこと。」

レビューのトレーサビリティ

各レビュアーの呼び出し後、shared-references/review-tracing.md（ポリシー C — フォレンジック。暗黙に省略しない）に従ってトレースを保存してください。選択したルート／セッション／作業ディレクトリ、要求したモデルと報告されたモデル、実際の推論レベル、生の応答、完了状況と対象範囲、判定、独立性、および reviewer-backends.md に基づく受け入れ可否を記録してください。save_trace.sh（shared-references/integration-contract.md §2 のチェーンに従って解決）を使用するか、.aris/traces/<skill>/<date>_run<NN>/ に直接ファイルを書き込んでください。--- trace: パラメーター（デフォルト：full）に従ってください。 判定を含む手動レビュー応答は、必ず Reviewer-Model: <exact-model-id> で始めてください。executor_model には、このセッションが実際に実行されているモデルを渡してください。識別情報が欠落している、不明である、または同一ファミリーである場合、無罪とは認められません。推測せず、REVIEW_UNAVAILABLE を出してください。実行モデルの名前を特定できない場合、手動レビューでファミリーをまたぐ主張は証明できません。主張するのではなく、その旨をレポートに記載してください。