# Scientific Review Writer > 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 public… - **Type:** Skill - **Install:** `agentstack add skill-k-telux-scireviewwriter-scientific-review-writer` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [k-telux](https://agentstack.voostack.com/s/k-telux) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [k-telux](https://github.com/k-telux) - **Source:** https://github.com/k-telux/SciReviewWriter/tree/main/skills/scientific-review-writer ## Install ```sh agentstack add skill-k-telux-scireviewwriter-scientific-review-writer ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # 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](references/writing-architecture.md) before outlining or restructuring. - Read [evidence-contract.md](references/evidence-contract.md) before drafting, claim checking, source acquisition, or citation repair. - Read [committee-gates.md](references/committee-gates.md) before multi-reviewer supervision, revision cycles, or final acceptance. - Read [latex-visual-qa.md](references/latex-visual-qa.md) before compiling, visually auditing, or packaging LaTeX/PDF deliverables. - Read [history-derived-rules.md](references/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. ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [k-telux](https://github.com/k-telux) - **Source:** [k-telux/SciReviewWriter](https://github.com/k-telux/SciReviewWriter) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-k-telux-scireviewwriter-scientific-review-writer - Seller: https://agentstack.voostack.com/s/k-telux - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.