Claude Scientific Writer is a Python and Claude Code tool that researches sources before drafting papers, posters, grant proposals, and literature reviews. Version v2.22.0, published 29 September 2026, is mostly a refresh of its bundled skills. It fits teams already standardized on Claude tooling. This is a source and documentation review with no runtime evidence, so treat any rollout as a deployment project with real prerequisites rather than a finished installation.

key facts and review scope

Capability and behaviour claims below come from the repository and its maintainers. Star counts and download badges are popularity signals; they say nothing about whether the tool fits your documents or your data policy.

what changed in v2.22.0

The release notes describe v2.22.0 as a refresh of the vendored skill set rather than a rewrite. The catalog stays at 26 skills, and the maintainers report regenerating skills.lock.json and all three snapshot copies with scripts/sync_skills.py, confirming the pin with --check. Of those 26 skills, the notes say 24 gained new content, while docx and pptx are identical between the two upstream pins.

The bundled skills moved to Scientific Agent Skills v2.69.0 at commit 45af7aefb40e, replacing the pin at ab2f84ab1059 (upstream 2.61.0), which had held since v2.19.0.

citation handling is the change that reaches your output

According to the release notes, the older BibTeX field parser stopped at the first closing brace, so titles with protected terms such as {AlphaFold} were truncated and written back with unbalanced braces. The same notes record page ranges like 583--589 being corrupted into 583----589. Version 2.1 of the skill also adds an OpenAlex search script, corrects twelve documented flags the scripts had rejected, and changes format_bibtex.py to write to standard output unless --output or --in-place is given.

That matters if you already run this tool over reference-heavy documents. Mangled titles and page ranges can survive automated review and land in a submitted manuscript. If your citations have been clean, this is routine upkeep rather than a reason to change anything.

the rest is model swaps and link repairs

Five skills, including scientific-schematics, scientific-slides, latex-posters, literature-review, and infographics, moved their AI review model from google/gemini-3.6-flash to google/gemini-3.7-flash. The generate-image skill advanced from 2.0 to 3.1 with substantial changes to its model reference and script. The release also fixed broken internal script and reference links in research-grants, scientific-critical-thinking, and scientific-slides, and installation instructions now use uv pip install.

None of that changes the shape of the product. It changes which model handles some review and figure steps, which can shift output style or cost without any change to your prompts.

the buyer problem and the reader’s stage

The tool targets a specific problem: a small research group, lab, consultancy, or technical founder needs a repeatable path from internal data plus published literature to formatted documents, and does not want to staff a research-engineering team to build one. The decision-maker is the technical lead or operations manager who owns tooling, API spend, and data policy. The reader here is evaluating the project and deciding whether to move into implementation.

The repository’s own framing lists papers with IMRaD structure, clinical reports, posters, grant proposals, literature reviews, and schematics, and describes research lookup through Parallel Search and Extract before writing. Those are maintainer claims. This review did not run the tool, so it cannot confirm output quality, citation accuracy in practice, or the reliability of any individual skill. The v2.18.0 changelog adds a useful scope note: the clinical and treatment-plan skills were tightened to cover research, formatting, and validation of clinician-supplied decisions rather than clinical decision-making itself.

who should look closer

• Teams already working inside Claude Code, or willing to standardize on the Anthropic API, who want a structured document pipeline rather than ad-hoc prompting.
• Groups that produce the same class of document repeatedly, where templates, citation handling, and figure generation are recurring work.
• Organizations that already run LaTeX and, optionally, LibreOffice, and have someone who can own Python dependencies and credentials.
• Operations leads who can define a human review step, because the tool drafts and formats while subject-matter verification still belongs to your experts.

who should pass

• Anyone whose research data cannot leave the environment. Research lookup, image generation, and the model calls route through remote services, and no evidence in this review shows a supported local-only path.
• Teams without an engineer or technical operator to maintain prerequisites, versions, and API keys.
• Buyers looking for unattended publication of unreviewed claims, which is a misuse of any drafting tool.
• Anyone who needs contractual support, service levels, or a security attestation. The project is MIT licensed open source with an organization behind it, but this review found no support commitment.

what has to be true before production

prerequisites are a real gate

The README requires Python 3.10 or newer, an ANTHROPIC_API_KEY, and either Parallel CLI authentication or a PARALLEL_API_KEY for research lookup. Image generation needs an optional OPENROUTER_API_KEY. PDF output expects a LaTeX distribution with pdflatex, bibtex, and preferably latexmk, with LibreOffice for Office rendering and recalculation and FFmpeg for media conversion. Check each of these in the environment where documents will actually be produced, because a pipeline that only works on one developer’s laptop is not a pipeline.

data egress and third-party services

Three external dependencies sit in the default path: the model provider, the research lookup service, and the optional image provider. Before you point this at real research, clinical, or client material, decide what leaves your network, under which contract, and with what retention. That is a policy decision your team owns; the repository does not make it for you.

skill supply chain

The skills are vendored from a separate upstream repository, pinned in skills.lock.json, and mirrored into three plugin roots. The maintainers’ own published guidance on skill security warns about prompt injection and poisoned SKILL.md files and recommends auditing and version pinning before installing skills in a lab environment. The same risk applies here: every skill refresh changes instructions the agent will follow, so diff the change and pin the commit instead of tracking the default branch.

input handling and destructive flags

The README states that input files are preserved by default and that --consume-inputs explicitly removes them after a successful copy. Confirm that behaviour against a disposable dataset before running the tool over a shared or irreplaceable folder.

cost and usage controls

The README points to scientific-writer --help for permission, budget, and token-usage controls, and the API example shows an optional track_token_usage flag. No cost-per-document figure exists in this evidence, so budget for the pilot by measuring your own token consumption rather than extrapolating from anyone else’s numbers.

hosted-model dependency

The tool inherits the availability of its model and search providers. Public attention to Claude availability on 29 September 2026, captured in the Google Trends entries attached to this review, is a reminder that an agent wrapped around a hosted API inherits that API’s outages. It is not a statement about this project’s quality. If document production is time critical, plan a fallback path.

maintenance signals

• Release cadence has been active: v2.18.0 and v2.19.0 in late July 2026, v2.20.0 and v2.21.0 in mid-August 2026, and v2.22.0 on 29 September 2026.
• The project now requires a changelog entry to release, and release entries are generated from it, which reduces the drift visible at v2.19.0.
• Release notes are not infallible. The v2.20.0 notes attributed the document-skill discovery bug to upstream, and v2.21.0 explicitly corrected that claim and fixed it inside this repository.
• Version 2.21.0 fixed a genuine defect: the docx, pdf, pptx, and xlsx skills were nested one level deeper than clients scan, so they were invisible. After upgrading, verify that every skill you rely on is actually discovered by your client.
• The open issue count was three at review time. A low count is a snapshot, not proof of stability.
• Continuous maintenance here is largely upstream synchronization. Installed behaviour can shift through vendored skills even when the package version changes little.

limitations and unknowns

The largest unknown is whether the output meets your standard. This review covers sources, not results: it generated no document, spot-checked no citations, measured no cost, and performed no security review. The maintainers’ stated intent is publication-ready output, but a drafting tool still needs expert verification of claims, and that cost belongs in your plan.

There is also a live third-party proposal in issue 21 to integrate a local, open-weight paper-generation backend. It is open, unlabelled, and has no maintainer comment at review time, so read it as an unaccepted suggestion rather than a supported route to offline operation.

evaluation questions to settle first

1. Which single document type will the pilot produce, and who signs off on its accuracy?
2. Are you allowed to send that document’s inputs to the model, search, and image providers?
3. Does your environment already have Python 3.10+, LaTeX, and the optional Office and media tooling?
4. Who owns API keys, spend limits, and the decision to upgrade skills?
5. How will you pin skills.lock.json and diff outward-facing instruction changes between versions?
6. What is your fallback when a provider is unavailable?

If the honest answer to the second question is no, the evaluation ends there regardless of how capable the tool is.

alternatives worth pricing alongside it

The maintainers position a hosted sibling product for end-to-end research and writing, and they publish the skills separately as a standalone repository, which means you can adopt the instruction layer without the CLI. General-purpose assistants remain a cheaper option for occasional drafts but lack the structured output and citation handling described here. The maintainers describe each of these trade-offs in their own materials; none was evaluated in this review.

verdict

Claude Scientific Writer is worth a controlled pilot for teams already committed to Claude tooling that produce research-heavy documents at volume, and especially for anyone who has hit the BibTeX defects that v2.22.0 addresses. It is not a drop-in production system. The prerequisites are real, the data-egress decisions are yours, and skill updates arrive from upstream continuously. Run the first month against non-sensitive material, pin the version, measure token cost, and compare output against your existing review standard before widening access. Teams that need offline operation, contractual support, or unattended accuracy should wait or look elsewhere.

if you want help putting this into a real environment

I take on AI agent development, deployment, and integration work, including the unglamorous parts: wiring a Python package or agent plugin into an existing workflow, pinning versions and vendored skill snapshots, defining credential and data-egress boundaries, and building a review step that keeps an expert accountable for every claim. To scope it honestly I would need your current stack, one sample document type, the environment where output is produced, and a non-sensitive dataset to run against. From there I can map the prerequisites, the integration points, and the ongoing maintenance work. That is the same ground covered by my software development services, and you can describe your setup through the contact form.

sources

• K-Dense-AI/claude-scientific-writer repository
• Release v2.22.0 notes
• Issue 21: CAJAL local backend proposal
• K-Dense: Security in the Science Agent Era