Get a deep critical review of research from an external reviewer backend (Codex or manual). Use when user says "review my research", "help me review", "get external review", or wants critical feedback on research ideas, papers, or experimental results.

Research Review via External Reviewer Backend (ultra reasoning) 🔒 Do not wrap this skill in /loop , /schedule , or CronCreate . It is verdict bearing — it produces a cross model review verdict, multi round with reviewer thread continuity. An external timer re fires the verdict on wall clock time and breaks the reviewer's round to round memory: zero new signal, full token cost. Schedule the external wait that precedes it (work ready → then review once), not the verdict. See [ shared references/external cadence.md ](../shared references/external cadence.md). Get a multi round critical review of research work from the selected external reviewer backend with maximum reasoning depth. Constants REVIEWER MODEL = gpt 6 astra — Default model for the Codex backend, reasoning effort ultra (deep audit tier). Must be an OpenAI model (e.g., gpt 6 astra , gpt 6.1 sol ). Manual backend uses a model the user chooses — it must be a recognized model from a different family (OpenAI, Anthropic, Google, DeepSeek, Moonshot/Kimi, Qwen). REVIEWER BACKEND = codex — Default: Codex MCP (ultra). Resolve — reviewer: , project .aris/reviewer.json , then this default using reviewer route.py ( host claude code tier deep ), per [reviewer backends.md](../shared references/reviewer backends.md). Gemini/Antigravity, Grok, and Claude Code use that contract at every call below. Legacy Oracle/manual contracts remain in reviewer routing.md ; unavailable selected routes do not silently fall back. Reviewer Calling Convention When calling the reviewer, branch on REVIEWER BACKEND: If REVIEWER BACKEND ∈ {antigravity, grok, claude code}: Use the selected first/reply protocol in reviewer backends.md , with the same review prompt, explicit cwd containing the primary files, and resolved provider specific model/effort. Save route, cwd and session id for continuation. A Claude Code bridge may run DeepSeek; derive family from its reported model. If REVIEWER BACKEND = codex : Use mcp codex codex for new review threads. Use mcp codex codex reply for follow up rounds (reuse threadId). If REVIEWER BACKEND = manual : Use mcp manual review review for new review threads with: prompt: [exact same prompt that would go to Codex] config: {"model reasoning effort": "xhigh", "executor model": "<actual executor model ", "require reviewer model": true} Save the returned threadId . Use mcp manual review review reply for follow up rounds with: threadId: [saved manual review threadId] prompt: [follow up prompt] config: {"model reasoning effort": "xhigh", "executor model": "<actual executor model ", "require reviewer model": true} Content fidelity: the manual reviewer should see the same substantive review brief Codex would read. If the manual UI supports file upload / attachment, reuse the same brief file; otherwise paste the brief contents inline because remote web UIs cannot read your local filesystem paths. Review tracing applies equally to both backends. Context: $ARGUMENTS Prerequisites The selected MCP must be available. For the default Codex MCP Server : This gives Claude Code access to mcp codex codex and mcp codex codex reply tools Workflow Step 1: Gather Research Context Before calling the external reviewer, compile a comprehensive briefing: 1. Read project narrative documents (e.g., STORY.md, README.md, paper drafts) 2. Read any memory/notes files for key findings and experiment history 3. Identify: core claims, methodology, key results, known weaknesses Step 2: Initial Review (Round 1) Send a detailed prompt with ultra reasoning, using the selected backend. For the codex backend, keep the MCP payload short: write the full briefing to RESEARCH REVIEW REQUEST.md , then point Codex at that file. For codex backend: For Antigravity, Grok, or Claude Code, send the same prompt through its selected first call tool; do not copy Codex's config into another tool. Check successful completion and actual file coverage before interpreting the response. The review brief should contain the full research context, the specific questions, and the primary artifact / raw result paths the reviewer should inspect. For manual backend: use mcp manual review review with the same brief contents. If the manual review UI supports attachments, attach RESEARCH REVIEW REQUEST.md ; otherwise paste the brief inline. Save the returned threadId . Step 3: Iterative Dialogue (Rounds 2 N) For codex backend: use mcp codex codex reply with the returned threadId . For manual backend: use mcp manual review review reply with the same threadId . For Antigravity, Grok, or Claude Code: use the saved route's continuation protocol in reviewer backends.md ; keep its model/cwd and repeat Claude cwd/tools. Use the appropriate tool to continue the conversation. For Codex follow up rounds, write an updated brief such as RESEARCH REVIEW ROUND 2.md and send only the path: For manual follow up rounds, attach that same updated brief if possible; otherwise paste it inline. For each round: 1. Respond to criticisms with evidence/counterarguments 2. Ask targeted follow ups on the most actionable points 3. Request specific deliverables : experiment designs, paper outlines, claims matrices Key follow up patterns: "If we reframe X as Y, does that change your assessment?" "What's the minimum experiment to satisfy concern Z?" "Please design the minimal additional experiment package (highest acceptance lift per GPU week)" "Please write a mock NeurIPS/ICML review with scores" "Give me a results to claims matrix for possible experimental outcomes" Step 4: Convergence Stop iterating when: Both sides agree on the core claims and their evidence requirements A concrete experiment plan is established The narrative structure is settled Step 5: Document Everything Save the full interaction and conclusions to a review document in the project root: Round by round summary of criticisms and responses Final consensus on claims, narrative, and experiments Claims matrix (what claims are allowed under each possible outcome) Prioritized TODO list with estimated compute costs Paper outline if discussed Update project memory/notes with key review conclusions. Composed mode — if invoked with — composed: <canonical report path (an orchestrator like /idea discovery passes this), do not write a standalone review .md in the project root. The raw conversation is already persisted to .aris/traces/… (see Review Tracing below — that audit copy is kept in every mode); fold the review conclusions (consensus, claims matrix, prioritized TODOs) into the orchestrator's canonical report and cite the trace path there. Default (no — composed: directive): behave exactly as above — write the standalone review document. Never infer composed mode from a report file merely existing. Full rules: [ shared references/output composition.md ](../shared references/output composition.md). Key Rules For the default Codex route, pin model: gpt 6 astra + config: {"model reasoning effort": "ultra"} (deep audit tier; capability fallback per reviewer routing.md , never below xhigh ). Other selected routes use their resolved model/effort. For manual , use the identity bearing config above. Tool fields belong to their own provider contracts; do not copy a payload between bridges. Put comprehensive context in the review brief. Codex can read local files when you pass an absolute path; manual reviewers usually cannot, so attach or paste the same brief there. Be honest about weaknesses — hiding them leads to worse feedback Push back on criticisms you disagree with, but accept valid ones Focus on ACTIONABLE feedback — "what experiment would fix this?" Document the threadId for potential future resumption The review document should be self contained (readable without the conversation) Prompt Templates For initial review: "I'm going to present a complete ML research project for your critical review. Please act as a senior ML reviewer (NeurIPS/ICML level)..." For experiment design: "Please design the minimal additional experiment package that gives the highest acceptance lift per GPU week. Our compute: [describe]. Be very specific about configurations." For paper structure: "Please turn this into a concrete paper outline with section by section claims and figure plan." For claims matrix: "Please give me a results to claims matrix: what claim is allowed under each possible outcome of experiments X and Y?" For mock review: "Please write a mock NeurIPS review with: Summary, Strengths, Weaknesses, Questions for Authors, Score, Confidence, and What Would Move Toward Accept." Review Tracing After each reviewer call, save the trace following shared references/review tracing.md (Policy C — forensic; never silently skip). Record the selected route/session/cwd, requested and reported models, actual effort, raw response, completion and scope, verdict, independence and acceptance per reviewer backends.md . Use save trace.sh (resolved per the chain in shared references/integration contract.md §2) or write files directly to .aris/traces/<skill /<date run<NN / . Respect the trace: parameter (default: full ). A verdict bearing manual response MUST begin with Reviewer Model: <exact model id — pass the model THIS session is actually running as in executor model . Missing, unknown, or same family identity cannot acquit; emit REVIEW UNAVAILABLE rather than guessing. If the executor model cannot be named, manual review's cross family claim is unprovable — say so in the report instead of asserting it.

research-review