Paper Pre-Submission Review (Lite)

Use a new output path or directory for each run; preserve earlier results and existing user edits.

Heritage and scope

An 11-sub-agent pre-submission review that runs inside a Claude Code session — no extra install, billable against your Claude Code plan. Nine parallel dimension agents find issues, two cross-checkers verify each finding against the manuscript before it reaches the report, and the orchestrator synthesizes. This is the Claude-Code-native counterpart to presubmit, our port of the reviewer2 adversarial peer-review pipeline, and it inherits that lineage's two commitments: a critical-reviewer posture, and a verification cascade that drops any finding not pinned to a quoted passage. It is the fast in-flow check, not the full pipeline — see the last section for when to reach for presubmit instead.

Two modes share one specification. The default mode runs the whole review inside one model family. Cross-model mode (--codex) runs the same nine dimensions twice — once on Claude, once on Codex — and has each model verify the other's findings. Everything through § 4 applies to both modes; the cross-model section at the end adds only what is specific to running two model families.

Instructions

Nine agents each audit a different dimension; two cross-check agents then audit those Phase 2 findings for hallucinations, false positives, and missed issues. The deliverable is a severity-ranked Pre-Submit Report with a journal-readiness checklist.

Critical-Reviewer posture (required for every sub-agent). Brutally honest on the work, fair to the people. Attack the argument or the data, never the authors — "the claim on line X is not supported by the evidence on line Y" is in scope; framing like "fraudulent" or "incompetent" is not. Prestige carries no weight: reputation, journal status, citation counts, and prior peer review are not evidence.

Orchestration lead. Whatever model you are running — Claude Opus or Fable — orchestrates: orientation, launching the dimension sub-agents, the cross-check cascade, the synthesis. The sub-agents do the reading. Run at medium effort by default and raise to high for the Phase 4 adjudication, deduplication, and Editor's Note; on Fable, that pass is where the lead's own reasoning matters most. If the Workflow tool is listed this session, express Phase 2 and Phase 3 as a Workflow pipeline() so each dimension's findings go to cross-check as soon as it completes. Otherwise (the common case; invoking a skill does not grant Workflows) launch all nine Phase 2 agents as parallel Agent calls in one message and start Phase 3 once the nine files exist.

Sub-agent model and effort assignment. Route by task type, not by agent number. Argument-level dimensions (logical structure, cross-referencing claims, silent discrepancies) go to Opus at high. Lookup, matching, existence, and checklist-completeness dimensions go to Haiku at medium. Writing quality needs some judgment, so it goes to Opus at low. Keep checker and checked on different models: Agent 10 verifies Opus's argument-level findings, so it runs on Fable, because a same-model checker grading its own kind of work is the weakest link in this design; Agent 11 verifies Haiku's mechanical findings on Opus. When Fable is the lead, swap one pin: Agent 1 (Content & Argument) runs on Fable at high, the one Red Team dimension where reasoning quality dominates reading volume; Agents 2, 6, 7 are thoroughness-bound full-manuscript reads where Opus is as strong and cheaper. Agent 10 then checks Agent 1's file on Opus and Agents 2, 6, 7's on Fable. Each sub-agent is a bounded single-shot call, so pass model and effort on every Agent call (or in opts on agent() inside a Workflow) rather than letting it inherit the orchestrator's sustained-role effort. The orchestrate skill describes the same routing pattern.

Sub-agent	Model	Effort	Why
Agent 1 — Content & Argument	Opus; Fable when Fable leads	high	evaluates logical structure and argument quality — the dimension where reasoning quality dominates reading volume
Agent 2 — Numbers & Internal Consistency	Opus	high	cross-references quantitative claims across the paper and audits forking-paths risk
Agent 3 — References & Citations	Haiku	medium	matches bibliography entries against in-text citations
Agent 4 — DOI Audit	Haiku	medium	DOI lookup and resolution against bibliography entries
Agent 5 — Writing Quality & Journal Compliance	Opus	low	style judgment plus a completeness checklist — no argument evaluation
Agent 6 — CONSORT / Randomization & Flow	Opus	high	detects silent discrepancies across N's, arms, and stages
Agent 7 — Pre-Registration Verification	Opus	high	PAP-to-paper hypothesis mapping and forking-paths audit
Agent 8 — Figures, Tables & Formatting	Haiku	medium	existence, numbering, and formatting checks
Agent 9 — Replication Archive	Haiku	medium	documentation-completeness audit against a checklist
Agent 10 — Content/Numbers/Design Cross-Checker	Fable; Opus for Agent 1's file when Fable leads	high	re-verifies Agents 1, 2, 6, 7 and steel-mans the paper — always on a different model from the agent it checks
Agent 11 — Technical Cross-Checker	Opus	low	re-verifies Agents 3, 4, 5, 8, 9; deciding false positives is judgment, and it sits on a different model from the Haiku finders

1. Orientation (do this yourself before launching agents)

Read the paper yourself to understand its structure before writing agent prompts. Determine:

• Where the paper source lives (LaTeX .tex vs Pandoc .md vs Word) and what the build command is
• Whether a Supplementary Information file exists and where it lives
• Where figures are stored and how they are referenced (relative paths, figure directories)
• Whether a replication archive exists (look for replication/, archive/, data/, README files)
• The paper's rough structure: section names, approximate page count, key claims in the abstract
• The bibliography format and location (.bib, inline, etc.)
• Design family. Is this a conjoint/factorial-vignette paper, a list experiment, a topic-modeling or LLM-classification study, or a VLM-OCR corpus paper? If so, also invoke the relevant sibling skill (conjoint-diagnostics, list-experiment, topic-modeling, text-classification, vlm-ocr) and fold its domain-specific checklist into Agent 9's deliverable. For any experimental manuscript, also run methods-reporting in audit mode so its 45-item checklist becomes the baseline for Agents 1, 2, 6, 7, and 8.

Use this knowledge to write specific agent prompts that reference actual file paths, section names, and relevant files. Generic prompts produce shallow results.

Orchestration contract. Before Phase 2, create a scratch directory .review-tmp/ in the paper's working directory. Each Phase 2 agent writes its structured findings to a dedicated file — agent-1-content.md, agent-2-numbers.md, agent-3-references.md, agent-4-dois.md, agent-5-writing.md, agent-6-consort.md, agent-7-prereg.md, agent-8-figures.md, agent-9-archive.md — using the output format specified below. Use these exact filenames; Phase 3 cross-checkers read them directly rather than having findings pasted into their prompts. For experimental manuscripts, Agents 6 (CONSORT/randomization-and-flow) and 7 (pre-registration verification) are mandatory; for non-experimental manuscripts they can be skipped and their checklist rows marked NA. After the Pre-Submit Report has been delivered, delete .review-tmp/ — it is workflow scratch, not a deliverable — unless the user asks to keep it.

Deterministic pre-pass (do this before launching any agent). If the paper ships analysis code or a replication package, run the replication-package skill's scripts/verify_package.py --root <dir> static tier. It reads files only, costs nothing, and takes seconds. Hand its output to Agent 2 and Agent 9 as evidence. Without it, Agent 2 can only compare the manuscript to itself, so a table that disagrees with what the code now produces is invisible to every agent in the fan-out. Executing the author's code needs approval: if a master script exists, ask once with AskUserQuestion (headed Clean-room run, naming the script) whether to re-run with --run, offering Run it now (state the timeout) and Skip, record NOT CHECKED, and say up front that a long or failing run is normal for a package that was never made portable. Anything short of an explicit choice to run is recorded as NOT CHECKED.

2. Parallel Deep Review (nine agents, concurrent)

Agent 1 — Content & Argument (Red Team primary): Read the full paper. Your posture is adversarial but fair: find every place the argument is weaker than the paper presents it to be. Check logical flow from introduction through conclusion. Identify unsupported claims, logical gaps, missing caveats, and places where the argument is unclear or circular. Flag any claims in the abstract not backed up in the body. Note missing discussion of limitations. Check whether the framing accurately positions the contribution relative to cited prior work.

Agent 2 — Numbers & Internal Consistency: Check every quantitative claim against JARS-Quant reporting expectations (Appelbaum et al. 2018). Do numbers in the abstract match the body? Do table values match in-text references? Do SI cross-references point to the right appendices/tables? Are confidence intervals, p-values, N counts, and effect sizes reported consistently throughout? Flag multiple-comparisons issues (many tests without correction or discussion). Verify that significance thresholds are defined and used consistently. For experimental papers, verify denominator consistency across ITT and any complier/compliance-adjusted analyses and flag any manipulation-check that is present in the design but missing from the results. Flag forking-paths risks explicitly: DV switching between primary and secondary outcomes, covariate-set changes across models, transformation or subsetting decisions not traceable to a pre-registration, and any analysis whose choice was visibly made after seeing outcome data (Wicherts et al. 2016; Gelman & Loken 2014; Simmons et al. 2011). Do not audit the CONSORT flow, baseline balance, attrition-by-arm, or PAP-to-paper mapping — those are Agents 6 and 7.

Agent 3 — References & Citations: Audit the bibliography file. Are all cited works present? Are there uncited entries? Check for stale working papers (2025+) that may now be published — flag entries that need author verification. Check formatting consistency (journal names, author encoding, entry types). Do not check DOIs — that is Agent 4's job.

Agent 4 — DOI Audit: Check every bibliography entry for a DOI. For entries missing a DOI, attempt to locate one via web search (title + author + "doi"). Report which entries are missing DOIs and, where found, provide the correct DOI. Verify that existing DOIs resolve to the correct paper — wrong-paper DOIs are a common copy-paste error.

Agent 5 — Writing Quality & Journal Compliance: Check for redundancy, passive voice overuse, unclear antecedents, jargon without definition on first use, overly long sentences (60+ words), and inconsistent terminology for the same concept. Audit journal-level transparency compliance against the TOP Guidelines (Nosek et al. 2015): data citation, data/code/materials transparency, design and analysis transparency, preregistration of studies and analysis plans, replication standards. Check reporting conformance against JARS-Quant (Appelbaum et al. 2018) and the reproducibility manifesto (Munafò et al. 2017). Explicitly check these pre-submission completeness items:

• Anonymization / double-blind compliance: no self-identifying information, self-citations in third person, no "unpublished manuscript by [author]" references, no author names in file metadata or acknowledgments
• Data availability statement (present and accurate per TOP Level 2+ and DA-RT; Lupia & Elman 2014)
• Ethics/IRB statement (present and sufficient for human subjects research; judge against APSA 2020 Principles and Guidance for Human Subjects Research — protocol number, exempt vs. expedited vs. full review, consent language, and any minor/vulnerable-population flags)
• AI use disclosure (required by some journals — flag if absent and suggest adding)
• Conflict of interest declaration
• Funding/acknowledgment statement
• Author ORCID (if journal requires)
• Abstract word count (most journals cap at 150 words)
• Keywords (some journals require 4-5 keywords)
• Word/page count against journal limits (if known)

Flag each completeness item as present, missing, or insufficient. Do not audit the preregistration itself — that is Agent 7.

Agent 6 — CONSORT / Randomization & Flow (experimental papers only): Audit randomization and participant flow against the CONSORT 2010 Statement (Schulz, Altman & Moher 2010) and Gerber et al. (2014) Appendix 1. Verify a participant-flow diagram is present and documents, at every stage: number assessed for eligibility; number excluded pre-randomization and reasons; number randomized per arm; number receiving the intended condition per arm; number lost to follow-up or excluded post-randomization (by arm, with reasons); number analyzed per arm for the primary outcome. Verify that: (a) a baseline-balance table across treatment arms is reported with standardized mean differences or equivalent, and imbalances are discussed; (b) intention-to-treat (ITT) is the primary analysis — per-protocol or complier-average analyses, if reported, are clearly labeled as secondary; (c) attrition rates are reported by arm and differential attrition (magnitude and composition) is explicitly addressed, including any sensitivity analysis (e.g., Lee bounds, Manski bounds); (d) the randomization procedure (unit, block structure, stratification, allocation concealment, mechanism) is described; (e) blinding / masking status is stated for participants, experimenters, and analysts, or its absence is justified. Flag any discrepancy between the CONSORT diagram numbers and the N's reported in the main tables. For non-experimental manuscripts, write NA — non-experimental to the output file and exit.

Agent 7 — Pre-Registration Verification (experimental / pre-registered papers only): Audit the manuscript against its pre-analysis plan (PAP) end-to-end. Steps: (1) Registry verification — locate the registration on OSF, AsPredicted, EGAP, or the journal registry; record the registry ID, registration timestamp, and whether the PAP is embargoed or public; flag any registration that post-dates data collection or data access. (2) PAP-to-paper hypothesis mapping — produce a table with columns PAP ID | Registered hypothesis | Registered estimator | Registered outcome | Reported in paper? | Location | Deviation?. Every registered hypothesis must appear; every reported confirmatory analysis must trace back to a registered hypothesis. (3) Confirmatory vs. exploratory classification — every reported analysis must be explicitly labeled confirmatory (registered) or exploratory (not registered); flag analyses presented as confirmatory that are not in the PAP. (4) Silent-deviation audit — flag registered analyses not reported; reported analyses not registered; changes in DV, covariate set, subgroup, estimator, sample filter, or pre-processing step that are not disclosed in a deviations section. Judge the PAP against Waldron & Allen (2022): is it specific, precise, and exhaustive? (5) Forking-paths check — Gelman & Loken (2014) and Simmons et al. (2011): list every branch point (DV choice, covariate set, exclusion rule, transformation, subgroup definition) and confirm each is resolved by the PAP or acknowledged as exploratory. Nosek et al. (2018) "Preregistration Revolution" is the benchmark for what counts as a credible pre-registration. For non-preregistered manuscripts, write NA — no preregistration to the output file, note whether the manuscript justifies the absence, and exit.

Agent 8 — Figures, Tables & Formatting: Verify all figures referenced in text exist on disk. Check captions for self-containedness (a reader should understand the figure from the caption alone). Verify figure and table numbering for gaps or duplicates. Check for LaTeX/build warnings (undefined references, overfull/underfull boxes). Verify SI is internally consistent and all SI cross-references in the main text point to the correct appendix/table/figure numbers. Check for formatting inconsistencies (e.g., mixed \hline and booktabs, inconsistent float placement). Flag accessibility issues in figures (alt text, color-blind-safe palettes, contrast). Do not audit the CONSORT participant-flow diagram itself — that is Agent 6; but if Agent 6 reports a CONSORT diagram is missing, still verify that a placeholder or substitute figure is not mis-numbered.

Agent 9 — Replication Archive: Review the replication archive independently against TOP Level 2+ (Nosek et al. 2015) and DA-RT (Lupia & Elman 2014). Does the README document the full pipeline? Are all data files present (or documented as embargoed/restricted)? Do script paths in the README match what actually exists? Are software dependencies and versions documented? Is there a codebook for each dataset (variable definitions, coding)? Does a table/figure-to-script mapping exist (which script produces which output)? Are PRNG seeds documented for any simulation or bootstrap procedures? Is data provenance documented (source, license, redistribution rights)? Could a competent researcher reproduce the main results from the archive alone? Flag missing files, undocumented steps, or broken path references.

Output format for each agent: Write findings to the agent's assigned file under .review-tmp/ (see Orchestration contract above). Use structured lists, not prose. For each issue:

• Severity: [CRITICAL], [RECOMMENDED], or [MINOR]
• Location: file path and line number or section name
• Issue: one sentence describing the problem
• Fix: one sentence describing what to do
• Quote: a verbatim span (≤ 2 sentences) from the manuscript that supports the finding — required for every [CRITICAL] and [RECOMMENDED] item, optional for [MINOR]. Findings without a quote will be dropped by the Phase 3 cross-checker as likely hallucinations.

Severity rubric (apply consistently across all agents):

• [CRITICAL] — blocks submission: wrong numbers, broken references, missing ethics/data-availability statement when required, silent deviation from a pre-registration, anonymization failure, unreproducible main result.
• [RECOMMENDED] — will draw reviewer complaint: unsupported claim, missing robustness check, undefined threshold, missing limitation, insufficient figure caption, undocumented exclusion.
• [MINOR] — polish: style, typography, citation format, wording consistency.

3. Cross-Check

Tell each cross-checker which .review-tmp/ files to read, and where to write its own validated output — .review-tmp/agent-10-content-numbers.md and .review-tmp/agent-11-technical.md.

Agent 10 — Content, Numbers & Design Cross-Checker (Blue Team / verification, Fable; when Fable leads, the Agent 1 file is checked on Opus instead): Read .review-tmp/agent-1-content.md, .review-tmp/agent-2-numbers.md, .review-tmp/agent-6-consort.md, and .review-tmp/agent-7-prereg.md. For each [CRITICAL] or [RECOMMENDED] item: (a) verify the cited quote appears verbatim at the cited location in the manuscript; drop items whose quote is missing, paraphrased, or does not support the claim made — these are hallucinations; (b) verify the issue itself against the actual paper text and flag false positives (issue doesn't exist or is already addressed); (c) steel-man the paper — for each retained finding, briefly note whether the paper anticipates or partially addresses the concern, since a partial response may downgrade severity. Add any issues missed — pay particular attention to: abstract vs. conclusion claims that drift from body evidence, significance thresholds, multiple comparisons, denominator consistency (e.g., percentages computed with vs. without a residual category), ITT vs. per-protocol mismatches, CONSORT-number vs. table-N mismatches, and silent pre-registration deviations (registered analyses not reported, reported analyses not registered).

Agent 11 — Technical Cross-Checker (Blue Team / verification): Read .review-tmp/agent-3-references.md, agent-4-dois.md, agent-5-writing.md, agent-8-figures.md, and agent-9-archive.md. For each flagged item: (a) verify the cited location actually contains the described issue (drop hallucinations); (b) verify the finding itself against the actual files — check the bibliography, figure files, figure/table numbering, and archive directory; (c) confirm or refute each finding. Add any issues missed.

4. Synthesis

Before listing anything, consolidate. If two or more Phase 2 agents independently flagged the same underlying issue, present it once with the strongest supporting quote — the same complaint restated five times under five headings is an artifact of the parallel-agent structure and it erodes trust in the report. If a finder's own description includes language conceding the point ("does not in itself indicate a deviation from common practice," "while a real concern, this is standard in the literature," "the paper acknowledges this on p. X"), demote the issue one severity tier — or drop it if the concession negates the critique.

Compile validated, deduplicated findings into a single Pre-Submit Report:

## Pre-Submit Report: [Paper Title]
Date: [today]
Recommendation: [Submit as-is | Minor revisions before submit | Major revisions before submit | Hold for new analysis | Substantial restructuring needed]
Issues: [N critical, N recommended, N minor]

### Editor's Note (revision strategy — read first)

A 3–6 paragraph prose memo, in your own voice, summarizing the path to a revised version that defends the contribution. Not a punch list — the punch list is below. This section should:

- Open with the single most consequential addition that would *strengthen* rather than weaken the paper. (Often a small analytical addition, a missing robustness check, or a missing comparison whose result would convert the strongest critique into a supporting result.)
- Identify which Critical Issues require new analysis (cannot be addressed by rewriting alone) versus which are textual/framing fixes.
- Where the manuscript already concedes a point that a critique missed, name the concession and note that the fix may be a small expansion of the existing acknowledgement rather than a new section.
- Where two Critical Issues are coupled (fixing one resolves the other), say so.
- End with a short paragraph on what could be deferred to a future paper without weakening the current contribution.

### Critical Issues (must fix before submission)
### Recommended Changes (should fix, not blocking)
### Minor Issues (nice to have)
### Strengths (what is working well)
### Journal-Readiness Checklist

| Dimension                        | Status            | Notes |
|----------------------------------|-------------------|-------|
| Compiles cleanly                 | PASS/FAIL         |       |
| Anonymized for double-blind      | PASS/FAIL         |       |
| Argument & logic                 | PASS/FAIL/PARTIAL |       |
| Internal numerical consistency   | PASS/FAIL/PARTIAL |       |
| References complete              | PASS/FAIL/PARTIAL |       |
| DOIs present                     | PASS/FAIL/PARTIAL |       |
| Writing quality                  | PASS/FAIL/PARTIAL |       |
| Figures/tables correct           | PASS/FAIL/PARTIAL |       |
| Formatting consistent            | PASS/FAIL/PARTIAL |       |
| Abstract & keywords              | PASS/FAIL/PARTIAL |       |
| Word/page count compliant        | PASS/FAIL/NA      |       |
| Replication archive ready        | PASS/FAIL/PARTIAL |       |
| CONSORT participant flow         | PASS/FAIL/NA      |       |
| ITT & baseline balance reported  | PASS/FAIL/NA      |       |
| Attrition-by-arm reported        | PASS/FAIL/NA      |       |
| Pre-registration deviations disclosed | PASS/FAIL/NA |       |
| Data availability statement      | PASS/MISSING      |       |
| Ethics/IRB statement             | PASS/MISSING      |       |
| Preregistration disclosure       | PASS/MISSING/NA   |       |
| AI use disclosure                | PASS/MISSING      |       |
| COI declaration                  | PASS/MISSING      |       |
| Funding/acknowledgments          | PASS/MISSING      |       |

### What Still Needs Your Input

"What Still Needs Your Input" lists items the review cannot resolve because they require author knowledge: ethics approval numbers, funding grant details, journal-specific formatting requirements, embargo status of data, or factual claims only the author can verify.

Every issue in the report carries a file path and line number (or section name), and objective errors (wrong numbers, broken references) are distinguished from subjective suggestions (writing style, framing). reference/example-report.md is a filled example of the whole report.

Cross-model mode (--codex)

Everything above still holds. This section replaces only the who runs what half of the workflow.

Two reviewers — Claude (the orchestrator) and Codex (GPT-6 Astra at xhigh reasoning effort by default, invoked via Bash codex exec) — independently apply the § 2 specification to the same paper, then each plays Blue Team to the other's Red Team. Two model families have different blind spots, so both their agreements and their disagreements carry information; Phase 4 scores each combination. Neither team sees the other's findings during Phase 2.

Roughly 22 model calls total (9 Claude Red Team, 9 Codex Red Team, 4 cross-model Blue Team) plus orientation and synthesis by the orchestrator. Reach for it before submission when you want maximum adversarial pressure and a second model family's blind spots.

--codex-effort <low|medium|high|xhigh> sets the reasoning effort for every Codex call in the run (default xhigh). Use it when the paper is short, the run is a mid-draft pass rather than the final one, or Codex credit is the constraint; high is the sensible step down. It applies to the Codex side only — the Claude-side pins are unchanged — and the same value is used for Codex's Red Team and Blue Team calls so both sides of the cross-check are run at one level.

The Claude orchestrator's role is unchanged from § "Orchestration lead": orientation, launching both Red Teams, spawning the cross-checkers, adjudicating at high effort. Fan the 18 Phase-2 calls and 4 Phase-3 cross-checks out the same way; the Codex-side calls are Bash invocations either way.

Codex invocation mechanism

Claude Code has no native codex:codex-rescue subagent. Every "spawn Codex" reference below means: use the Bash tool to invoke codex exec directly. Pattern (substitute OUTPUT_PATH with the agent's output file path and inline the prompt body inside the heredoc):

codex exec \
  --model gpt-6-astra \
  -c model_reasoning_effort=CODEX_EFFORT \
  --sandbox workspace-write \
  --skip-git-repo-check \
  -C "$(dirname OUTPUT_PATH)" \
  "$(cat <<'CODEXEOF'
<the XML prompt template for this agent, with PAPER_PATH and OUTPUT_PATH substituted as literals>
CODEXEOF
)" < /dev/null

Required:

• --model gpt-6-astra -c model_reasoning_effort=CODEX_EFFORT — pins the peer explicitly rather than relying on codex exec's own implicit default, so it does not silently drift if that default changes upstream. CODEX_EFFORT is the --codex-effort value, or xhigh when none was given.
• < /dev/null — closes stdin. Without it, codex exec hangs indefinitely on "Reading additional input from stdin..." even when the prompt is passed as a CLI argument. This is the single most common failure mode.
• run_in_background: true on every Bash call. Eleven parallel Codex calls per run (9 Phase 2 + 2 Phase 3) make foreground execution impractical.
• timeout: 600000 (10 minutes) as a harness backstop. If a call hangs for any reason, the harness kills it.

After each Codex Bash task notifies completion, Read its output file. Treat any of the following as a Codex agent failure (skip that finding's contribution in adjudication, log the failure in the report):

• Exit code ≠ 0.
• No session file appeared in ~/.codex/sessions/ (Codex did not actually start).
• The OUTPUT_PATH file is missing or empty.

Orientation and orchestration contract

Run § 1 verbatim, including the sibling-skill hand-offs: methods-reporting in audit mode for experimental manuscripts, whose 45-item checklist becomes the baseline for Agents 1, 2, 6, 7, and 8 on both teams; the matching design-family skill folded into Agent 9 on both teams. Generic prompts produce shallow reviews from both model families.

Replace the flat .review-tmp/ layout with:

.review-tmp/
├── claude/
│   ├── agent-1-content.md
│   ├── agent-2-numbers.md
│   ├── agent-3-references.md
│   ├── agent-4-dois.md
│   ├── agent-5-writing.md
│   ├── agent-6-consort.md
│   ├── agent-7-prereg.md
│   ├── agent-8-figures.md
│   └── agent-9-archive.md
├── codex/
│   ├── agent-1-content.md   (same dimensions, Codex output)
│   ├── ...
│   └── agent-9-archive.md
└── cross-check/
    ├── claude-checks-codex-content.md     (covers Codex agents 1, 2, 6, 7)
    ├── claude-checks-codex-technical.md   (covers Codex agents 3, 4, 5, 8, 9)
    ├── codex-checks-claude-content.md
    └── codex-checks-claude-technical.md

Both teams write independently to their own subdirectory. Cross-checkers read the other team's subdirectory. Use absolute paths when spawning Codex sub-agents — codex exec's -C flag sets the working directory, but absolute PAPER_PATH and OUTPUT_PATH values in the prompt remove ambiguity when the paper lives outside that CWD.

Phase 2 — dual independent Red Team (18 parallel calls)

Launch all 18 review calls in a single message.

• 9 Claude sub-agents via the Agent tool (default subagent_type). Use the § 2 agent prompts (Agents 1–9) verbatim, but redirect output to .review-tmp/claude/agent-N-*.md. Carry over the § "Sub-agent model and effort assignment" table (Opus high for 1, 2, 6, 7; Haiku medium for 3, 4, 8, 9; Opus low for 5; Agent 1 on Fable when Fable leads).
• 9 Codex sub-agents via the Bash tool, following § "Codex invocation mechanism". Use the Codex Phase 2 template below as the prompt body, one call per dimension. Output to .review-tmp/codex/agent-N-*.md.

Both teams apply the same dimension definitions, the same Critical-Reviewer posture, and the same severity rubric from § 2. The point of running two model families on one specification is to compare independent applications of one standard, not to give them different jobs.

One carve-out — Codex Agent 4 (DOI audit) has no web access. The codex exec sandbox cannot perform the web searches that the Agent 4 prompt asks for. Tell Codex's Agent 4 to limit itself to offline checks (DOI present/absent, format validity, internal consistency with the entry) and to tag entries NEEDS WEB VERIFICATION instead of attempting lookups; live DOI resolution and missing-DOI searches are the Claude team's Agent 4's job (it has WebSearch/WebFetch).

Agents 6 (CONSORT) and 7 (pre-registration) are required for experimental manuscripts and marked NA for non-experimental ones on both teams.

Phase 3 — cross-model adversarial verification (4 parallel calls)

Each model verifies the other's findings. Cross-checkers do not add new findings; that was Phase 2's job. They verify, refute, or downgrade.

Claude cross-checks Codex (2 sub-agents via Agent).

• Sub-agent A reads .review-tmp/codex/agent-{1,2,6,7}-*.md and the manuscript. Writes .review-tmp/cross-check/claude-checks-codex-content.md.
• Sub-agent B reads .review-tmp/codex/agent-{3,4,5,8,9}-*.md plus the manuscript, bibliography, and archive. Writes .review-tmp/cross-check/claude-checks-codex-technical.md.

For each Codex [CRITICAL] or [RECOMMENDED] finding, the cross-checker verifies the cited verbatim quote appears at the cited location, verifies the issue against the actual paper, flags any Codex finding that Claude also flagged independently in .review-tmp/claude/ (mutual catch — note for synthesis), and steel-mans the paper. When the paper anticipates or partially addresses the concern, note it for severity downgrade.

Codex cross-checks Claude (2 sub-agents via Bash following § "Codex invocation mechanism").

• Sub-agent C reads .review-tmp/claude/agent-{1,2,6,7}-*.md. Writes .review-tmp/cross-check/codex-checks-claude-content.md.
• Sub-agent D reads .review-tmp/claude/agent-{3,4,5,8,9}-*.md. Writes .review-tmp/cross-check/codex-checks-claude-technical.md.

Use the Codex Phase 3 template below. Same verification protocol.

Phase 4 — adjudication and synthesis (orchestrator, direct)

The Codex plugin's result-handling guidance — stop after presenting review findings and change nothing — governs code-review handoffs, not this skill: here the adjudication step below is the instructed work, and it produces a report, not a code change.

Build the consolidated Pre-Submit Report by adjudicating across teams.

• Mutual. Both teams flagged it; both cross-checkers confirmed. Mark [CRITICAL ✓✓] or [RECOMMENDED ✓✓]. Highest-confidence findings.
• Asymmetric, cross-confirmed. One team flagged; the other team's cross-checker confirmed against the paper. Retain at original severity. Mark [CRITICAL ✓] or [RECOMMENDED ✓]. These often surface real but easy-to-miss problems.
• Asymmetric, cross-refuted. One team flagged; the other team's cross-checker refuted against the paper. Default action is to drop. The orchestrator can override by re-reading the manuscript directly, in which case retain at one tier below original severity with the note "single-team finding, cross-refuted, retained after orchestrator re-read at file:line".
• Quote-failed. The cross-checker could not find the cited verbatim span. Drop as hallucination on the finder's side.

Apply the § 4 synthesis rules in order. Deduplicate within-team first (multiple agents on the same team flagging the same underlying issue), then across-team (a mutual catch is one entry, not two), then demote self-conceded critiques. The report format is § 4 exactly — single-line Recommendation at the top, then the Editor's Note, then Critical / Recommended / Minor lists, then Strengths, then the Journal-Readiness Checklist, then "What Still Needs Your Input" — with one extra column on the Critical Issues and Recommended Changes tables.

| Severity | Confidence                                      | Location | Issue | Fix |
|----------|-------------------------------------------------|----------|-------|-----|
| CRITICAL | Mutual (Claude + Codex)                         | …        | …     | …   |
| CRITICAL | Asymmetric: Codex only, confirmed by Claude     | …        | …     | …   |
| CRITICAL | Asymmetric: Claude only, cross-refuted, retained after orchestrator re-read | … | … | … |

Codex Phase 2 template (one per dimension, 9 total)

Use the XML block below as the prompt body inside the Bash invocation from § "Codex invocation mechanism". Substitute DIMENSION_INSTRUCTIONS with the verbatim text of the corresponding agent from § 2 (the full text of Agent 1, Agent 2, …, Agent 9 — do not paraphrase), and SEVERITY_RUBRIC with the verbatim § 2 severity rubric. Substitute PAPER_PATH with the absolute manuscript path and OUTPUT_PATH with the absolute path to the Codex agent's output file under .review-tmp/codex/.

<task>
You are a Critical Reviewer auditing the manuscript at PAPER_PATH for the dimension below.

Posture (required): adversarial but fair. Find every place the argument is weaker than the paper presents it to be. Attack the argument and the evidence, not the authors — "the claim on line X is not supported by the evidence on line Y", never "the authors are incompetent".

Dimension:

DIMENSION_INSTRUCTIONS

Write your findings to OUTPUT_PATH.

A second model (Claude) is independently performing the same review on the same paper for the same dimension. You will not see its findings. After both passes complete, each model's findings will be verified by the other. Findings without a verbatim quote will be dropped as hallucinations during cross-check.
</task>

<output_format>
Structured list, not prose. For each issue:
- Severity: [CRITICAL] / [RECOMMENDED] / [MINOR]
- Location: file path and line number, or section name
- Issue: one sentence describing the problem
- Fix: one sentence describing what to do
- Quote: a verbatim span (≤ 2 sentences) from the manuscript that supports the finding. REQUIRED for every [CRITICAL] and [RECOMMENDED] finding. Optional for [MINOR].

Severity rubric (apply consistently):

SEVERITY_RUBRIC
</output_format>

<action_safety>
Read PAPER_PATH and any files it references (bibliography, archive, SI). Write only to OUTPUT_PATH; do not edit the manuscript or any other file.
</action_safety>

<default_follow_through_policy>
Apply the dimension end-to-end without stopping for confirmation.
If the finding is unambiguous, record it.
If the finding requires author knowledge to confirm (embargo status, IRB number), record it as [RECOMMENDED] with the caveat "requires author confirmation".
Do not ask clarifying questions mid-run.
</default_follow_through_policy>

Codex Phase 3 template (cross-check Claude's findings)

Used for sub-agents C and D in Phase 3. Substitute PAPER_PATH, INPUT_FILES (a comma-separated list of .review-tmp/claude/agent-N-*.md paths the cross-checker should read), and OUTPUT_PATH.

<task>
You are a verification cross-checker. Another model (Claude) has produced findings about the manuscript at PAPER_PATH. Your job is to verify each finding against the actual manuscript.

Read the findings file(s) at INPUT_FILES. For each [CRITICAL] or [RECOMMENDED] finding, output one verdict entry.

1. QUOTE CHECK. Does the cited verbatim quote appear at the cited location in PAPER_PATH? If not, verdict is "QUOTE FAILED — drop as hallucination".
2. ISSUE CHECK. Does the issue itself hold up against the actual paper text? If the issue does not exist, is already addressed elsewhere in the paper, or is a misreading, verdict is "REFUTED" with a one-sentence explanation citing the paper line that refutes it.
3. STEEL-MAN. If the issue is real, note whether the paper anticipates or partially addresses the concern. If it does, verdict is "CONFIRMED, downgrade one severity tier — partially addressed at <file:line>".
4. OTHERWISE. Verdict is "CONFIRMED".

Do not add new findings of your own. You are verifying, not reviewing.

Write your verdicts to OUTPUT_PATH.
</task>

<inputs>
Findings to verify: INPUT_FILES
Manuscript: PAPER_PATH
</inputs>

<output_format>
For each finding in the input files, one entry.
- Source finding: <Claude agent N, severity, location>
- Quote check: PASS / FAIL
- Issue check: CONFIRMED / REFUTED / DOWNGRADE
- Evidence: one sentence citing the paper line that supports the verdict.
- Original severity vs. recommended severity (if downgrade)
</output_format>

<action_safety>
Read PAPER_PATH and the files listed in INPUT_FILES. Write only to OUTPUT_PATH; do not edit the manuscript or the input files.
</action_safety>

<default_follow_through_policy>
Process every finding in the input files end-to-end. Do not ask clarifying questions mid-run.
</default_follow_through_policy>

Cross-model quality checks

• For experimental manuscripts, methods-reporting invoked in audit mode and its 45-item checklist made the baseline for Agents 1, 2, 6, 7, and 8 on both teams. For conjoint, list-experiment, topic-modeling, text-classification, or VLM-OCR manuscripts, the sibling skill's checklist folded into Agent 9 on both teams.
• Codex sub-agents called via Bash following § "Codex invocation mechanism" (codex exec ... < /dev/null, run_in_background: true, timeout: 600000). Absolute paths used for PAPER_PATH and OUTPUT_PATH in the prompt.
• Agents 6 and 7 marked NA on both teams for non-experimental or non-preregistered manuscripts.
• All 4 Phase 3 cross-checks launched only after all 18 Phase 2 output files exist. Any Codex agent failure logged in the report rather than silently reducing coverage.
• Quote-failed findings dropped as hallucinations on the finder's side. Asymmetric, cross-refuted findings dropped unless the orchestrator re-read the manuscript and noted the override on the entry.
• Adjudication produces one entry per underlying issue, each retained Critical / Recommended issue carrying a confidence label and a file path with line number, or a section name.
• .review-tmp/ deleted after the final report was delivered, unless the user asked to keep it.

When to reach for presubmit instead

This skill covers most in-flow review needs. The heavier presubmit Python CLI runs ~30 stages and is the right tool when:

• You want full adversarial pressure — a dedicated Red Team whose personas (Breaker, Butcher, Shredder, Collector, Void) each attack the paper from a different angle, a Blue Team defence, separate numbers/fact-check/citation-verification cascades, and a legal pass; this skill compresses that into Agent 1 plus the two cross-checkers.
• You want a standalone deliverable — a single report.txt and optional editor's note, produced outside your Claude Code session. Useful when the review is the product: feedback to a co-author, a pre-print critique, or a final pass before external peer review.
• You want resumability + cost tracking — presubmit checkpoints every stage to disk; deleting a stage file forces that stage to re-run. Tracks per-stage API cost.
• You want a math audit — presubmit has an optional Mathpix-backed equation audit (--math); this skill doesn't.
• You want a code-replication audit — presubmit can ingest a replication archive and compare claims against the code (--code); this skill stops at the "does the archive look complete" question in Agent 9.

Trade-off: presubmit bills per-token against an Anthropic API key (separate from your Claude Code subscription). See presubmit/README.md for install, cost considerations, and known trade-offs vs. the upstream Gemini implementation.

Mode	Adversarial depth	Cost	When
Default	Single-model, 11 agents, in-session verification cascade	Lightest	Fast in-flow review during writing
--codex	Cross-model, 18 agents plus 4 cross-checks, dual verification cascade	~2× the calls of the default mode	Before submission, when you want maximum pressure and a second model family's blind spots
presubmit	~30 stages, dedicated Red Team personas, Blue Team defence, math and code-replication audits, resumable, cost-tracked	Heaviest, separate Anthropic API key	The review is the deliverable. Co-author feedback, pre-print critique, final pre-submission pass.