scientific-review-writer

name

scientific-review-writer

description

Evidence-gated workflow for planning, drafting, revising, auditing, and packaging scientific literature reviews, thesis reviews, and paper-style manuscripts from source notes, PDFs, BibTeX, LaTeX, DOCX, figures, or reviewer feedback. Use when the work must be mechanism-first, citation-traceable, visually verified, privacy-safe, and explicit about uncertainty, competing interpretations, and publication readiness.

Scientific Review Writer

Overview

Turn heterogeneous scientific sources into a review whose claims, figures, citations, rendered pages, and release files can be audited. Treat writing quality as a logic-and-evidence problem before sentence polish.

This skill may target a concise journal-like style, including “Nature-style,” but must never imply endorsement, acceptance, or review by Nature or any publisher.

Choose the route

• For a new review, follow the complete workflow below.
• For a plan-only request, complete scope, source-ledger boundaries, and argument architecture, then stop before drafting while listing every unverified input and the next gate.
• For a revision, freeze the current source, PDF, logs, renders, audits, and package as one baseline; then run the same gates on the delta and globally.
• For an audit, do not rewrite unless asked. Report evidence, failures, and the smallest repair set.
• For a source-recovery task, inventory local sources and generated artifacts before proposing a new outline or replacing existing work.

Read the references only when their gate becomes active:

• Read writing-architecture.md before outlining or restructuring.
• Read evidence-contract.md before drafting, claim checking, source acquisition, or citation repair.
• Read committee-gates.md before multi-reviewer supervision, revision cycles, or final acceptance.
• Read latex-visual-qa.md before compiling, visually auditing, or packaging LaTeX/PDF deliverables.
• Read history-derived-rules.md when a failure resembles a known review-writing failure mode or the user asks how the rules were derived.

Core contract

Always:

1. Separate source fact, direct observation, model-dependent inference, synthesis, and open question.
2. Put a traceable source near every nontrivial historical, theoretical, experimental, and review-level claim.
3. Define abbreviations at first use in body text and respect figure/caption reading order.
4. Explain the mechanism, why it matters, what it explains, and where it fails.
5. Follow every figure or table with same-section interpretive prose before the next heading, page break, bibliography, appendix, or document end.
6. Keep source, compiled PDF, build log, rendered pages, audit, and package on one version lineage.
7. Use PASS, FAIL, BLOCKED, and UNVERIFIED literally. Never inherit a stale PASS after a relevant source or validator change.

Never:

• fabricate a citation, quotation, page number, experiment, or acceptance;
• equate an abstract, search snippet, or community post with a checked paper;
• copy hidden chain-of-thought, private dialogue, personal data, credentials, or unlicensed third-party assets into a public deliverable;
• bypass a paywall or claim legal access when only metadata is available;
• treat successful compilation, text extraction, or one reviewer as final QA;
• let stylistic fluency hide a missing evidence boundary.

Complete workflow

1. Lock scope and acceptance

Record the audience, review question, date horizon, required formats, length, language, venue style, source-access limits, and exact acceptance gates. Translate vague targets such as “PhD level” into checkable requirements: mechanism depth, claim traceability, disagreement synthesis, figure interpretation, and rendered-page quality.

Ask only when a missing field would materially change the work. Otherwise use the narrowest reasonable default, label the field UNVERIFIED, and expose the assumption in the handoff.

2. Inventory and classify inputs

Create a source ledger containing identifier, source type, access state, redistribution state, intended claim, checked location, and confidence. Mark personal or licensed material before any public packaging.

Do not infer current document state from filenames. Inspect source, PDF, log, renders, hashes, and modification times.

3. Build the argument architecture

Form one central question and a section-level claim map. Organize the review by mechanism, diagnostic, limitation, or disagreement rather than paper-by-paper chronology. Each section should answer:

• What physical or scientific problem is being solved?
• Which mechanism or model is introduced?
• What evidence discriminates it from alternatives?
• Which assumptions and confounders remain?
• What conclusion is justified at the stated evidence level?

4. Draft from claim-evidence units

For each paragraph, write a claim, mechanism, evidence, limitation, and transition. Use calibrated verbs: “supports,” “is consistent with,” or “constrains” unless the evidence truly establishes the stronger statement.

Keep terminology canonical. Distinguish observables from derived quantities and state conventions that can change signs, normalizations, or labels.

5. Integrate figures and tables

Use only owned, licensed, public-domain, or permission-cleared visuals. For each panel, record provenance, transformation, claim supported, and limitation.

Body text must identify the relevant panel, describe the evidence it contains, connect that evidence to the paragraph’s claim, and state what remains model-dependent. Interpret at least half of the panels in a multi-panel figure.

6. Run independent review gates

Use complementary read-only reviewers for physics/domain correctness, claim-citation alignment, figure/provenance, writing architecture, and rendered layout. Each reviewer returns:

• PASS, FAIL, BLOCKED, or UNVERIFIED for the inspected gate;
• exact evidence inspected;
• minimal blockers;
• severity and affected artifact;
• what the evidence does not prove.

Use FAIL when inspected evidence contradicts the gate, BLOCKED when required evidence cannot be obtained, and UNVERIFIED when the gate was not inspected. Any substantive FAIL triggers the smallest correction, a fresh compile, full regression QA, and focused re-review. Keep one writer for the canonical source.

7. Compile, render, and inspect

Run the venue-appropriate build, inspect warnings, extract text, render every page to images, scan whitespace and clipping, and manually inspect a contact sheet plus high-risk pages. Separate source-level, text-extraction, and rendered-visual verdicts.

8. Package and freeze

Build from a clean directory. Include only current canonical source, bibliography, licensed figures, build instructions, generated PDF, evidence ledger, and machine-readable acceptance record. Recompile the clean package and record hashes.

Report simulated-reviewer consensus as simulated. It is not professor, committee, journal, or publisher acceptance.

Stop conditions

Stop and report BLOCKED or UNVERIFIED when:

• a required source cannot be legally accessed;
• a citation does not support the adjacent claim;
• source, PDF, logs, renders, or package are not from one version;
• a figure’s provenance or redistribution rights are unclear;
• the rendered document cannot be inspected;
• a domain ambiguity changes the conclusion;
• an external acceptance claim lacks external evidence.

Required handoff

Return:

1. artifact links and version/hash lineage;
2. scope and audience;
3. source coverage and legal-access gaps;
4. PASS, FAIL, BLOCKED, and UNVERIFIED gates;
5. unresolved scientific and editorial limitations;
6. exact commands or steps needed to reproduce the result;
7. a statement separating publication-quality targeting from actual acceptance.