Synthesise Reviews

Synthesise Reviews

Combine multiple review reports into a single prioritised revision plan with cross-reviewer consensus ranking.

Output Path

Per rules/review-artefact-routing.md (auto-loads in research projects (path-scoped to paper-*/ and paper/)):

• Source slug: synthesise-reviews
• Write reports to: reviews/<scope>/synthesise-reviews/YYYY-MM-DD-HHMM.md inside the project, where <scope> is the paper slug (e.g. paper-jtp) or _project for project-level synthesis. Path is relative to the research project root, not the Task-Management repo.
• Never at project root (./CRITIC-REPORT.md-style filenames are forbidden — pre-rule layout).
• Idempotency: if today's file exists, append a same-day descriptor ({date}-revision.md, {date}-r2.md, {date}-pre-submission.md) — never overwrite.
• Index update: if reviews/INDEX.md exists, write a one-line entry under "Latest per source" pointing at the new file. Otherwise review-recap will rebuild the index next time it runs.
• Infrastructure repos (Task-Management, atlas-workspace, etc.): this section does not apply — the path-scoped rule won't load there.

Purpose

After running parallel review agents (paper-critic, domain-reviewer, referee2-reviewer), this skill reads their internal reports, cross-references issues, and produces a unified synthesis grouped into workstreams by priority and theme. It decides the consolidated issue set; strategic-revision --internal is the separate step that turns a complex issue set into an executable DAG.

Inspired by APE Papers' reviewer_response_plan_1.md pattern — workstreams grouped by priority, each concern traced to its reviewer.

When to Use

• After running 2+ review agents on a paper
• After a council review round
• When preparing a revision plan from multiple feedback sources
• Before an optional strategic-revision --internal handoff when the consolidated issues are interdependent

When NOT to Use

• Before reviews exist — run the review agents first
• To run reviews — use the individual agents (paper-critic, domain-reviewer, referee2-reviewer)
• For a single review — just read the report directly
• For genuine venue referee reports or an R&R response — use strategic-revision --external

Workflow

Step 1: Discover Reports

Glob for review files in the project root. Scan the new canonical structure first, then fall back to legacy:

reviews/<scope>/<check>/YYYY-MM-DD*.md (canonical: e.g. reviews/paper-jtp/paper-critic/2026-06-28-1437.md)
reviews/<check>/YYYY-MM-DD*.md (legacy: e.g. reviews/paper-critic/2026-06-28-1437.md)

Where <scope> is a paper slug (e.g. paper-jtp) or _project.

If no reports found, ask the user where the reports are.

Present the discovered reports and their dates. If reports are from different dates, ask whether to synthesise all or just the most recent round.

Step 2: Parse Issues

For each report, extract the issue list:

From paper-critic CRITIC-REPORT.md:

• Parse the Deductions table (columns: #, Issue, Tier, Deduction, Category, Location)
• Extract Critical (C*), Major (M*), Minor (m*) issue details from the detailed sections

From domain-reviewer DOMAIN-REVIEW.md:

• Parse each Lens section's issue table (columns: #, Issue, Severity, Location)
• Map: CRITICAL → Critical, MAJOR → Major, MINOR → Minor

From referee2-reviewer REFEREE2-REPORT.md:

• Parse the structured findings from each audit dimension
• Extract severity-tagged issues

Step 2.5: Spot-verify findings against their cited location (integrity gate)

Per _shared/audit-integrity.md Rule 2, a review sub-agent's finding is not trusted until its evidence is confirmed — reviewers can emit plausible findings with a fabricated path:line. Before synthesising, spot-verify a random sample of the parsed issues (≥3, or 20% — whichever is larger, weighted toward Critical/Major):

1. For each sampled issue, open its cited Location (path:line) and confirm the quoted text/code is actually there and the issue follows from it.
2. Any sample miss (cited line doesn't exist, quote isn't there, or the claim doesn't follow) ⇒ that report is suspect: widen the check to all of that reviewer's findings and drop every one that can't be grounded.
3. Findings with no Location/quotable anchor at all are dropped, not synthesised — a finding you cannot point at is inadmissible.

Record a one-line Integrity: N sampled, M dropped note in the synthesis output. If reports lack locations entirely and nothing can be verified, say so rather than silently trusting them.