PaperSpine5: a local-first paper pipeline for Codex, Claude and OpenClaw hosts

The gap PaperSpine5 targets: paper work spread across disconnected tools

Most writing stacks split a paper into separate chores. A reference manager holds PDFs, a chat model drafts prose, a plotting library makes figures, and a checklist catches citation errors, usually after the draft is done. PaperSpine5 is built for the person who wants those steps in one task. The README frames it as an AI Skill covering the whole paper lifecycle: you supply a research direction, existing material or experimental data, and it searches literature, organizes arguments, builds an outline, writes the full text, generates research figures, and finishes with citation verification, review, revision and typesetting. The stated deliverable is editable Word or LaTeX sources plus PDF. The audience is narrower than "anyone writing a paper". It assumes a host runtime, since the skill is projected into Codex, Claude and OpenClaw directories under dist/. If you do not already run one of those hosts, the standalone paper-spine Skill at roughly 0.72 MB is useless on its own. The self-contained bundles, about 26.4 MB for Windows x64, 56.2 MB for Linux glibc x86_64, and 40.5 MB for each macOS architecture, exist for people who want the host and skill installed together.

How the pipeline is organized: projections, method tools and guards

The repository layout is unusually explicit about where code lives versus where it is published. src/ holds the Skill source, while dist/ holds per-host projections: dist/codex/skills/paper-spine, dist/claude/skills/paper-spine and dist/openclaw/skills/paper-spine. Claude users get an additional command entry at dist/claude/commands/paperspine.md, which matches the README instruction to launch through paper-spine. The method layer is named rather than hidden: writing_rationale_matrix, citation_support_bank and translation_package are listed as key methods and tools. The guard layer is a set of Python checkers, artifact_check.py, reference_inventory.py, citation_bank_check.py, latex_guard.py and word_guard.py, which suggests validation runs over artifacts, references, citations, LaTeX output and Word output respectively. The README states that arguments, citations and figures are bound to real material and evidence, and that research material is kept locally by preference. That is the design claim worth testing: the guards are the mechanism that makes evidence binding checkable rather than aspirational. The public repository keeps source and tests but not local tasks, clinical data, caches or development run logs, so anyone expecting to inspect a live task directory in the repo will not find one. The examples directory contains examples/v4_acceptance.py, an acceptance script tied to the previous major version.

Installing PaperSpine5 and running the first task

Download the bundle for your platform from the public release manifest at https://wubing2023.github.io/PaperSpine/v5/ and verify its SHA-256 before running anything. On Windows x64 the README gives this installer invocation, which targets the Codex host and archives known V3/V4 skill discovery directories:

powershell -ExecutionPolicy Bypass -File .\install.ps1 -Target codex -CleanLegacy

The README is explicit that -CleanLegacy only archives known V3/V4 Skill discovery directories. It does not delete paper task data, host settings or unknown files. On macOS and Linux the equivalent is:

sh ./install.sh --target codex --clean-legacy

Both installers verify byte counts, SHA-256, internal bundle integrity and a first-start self-check, according to the README. After installation, the README says you start the workflow through paper-spine, then work in the web interface: choose a plan, preview text and figures, leave revision comments, and download the result. The README does not document the exact prompt or flag sequence for that first task beyond the paper-spine entry point, so treat the web interface as the place where the run is configured. If you only want to check whether you are current, the check-only mode exists on both platforms:

sh ./install.sh --check-only

On Windows the same check is `powershell -ExecutionPolicy Bypass -File .\install.ps1 -CheckOnly`. Automatic updates are off by default, so nothing changes under you until you run the update command yourself.

Updating and rolling back without losing task data

The README describes a two-step update: run the check-only mode first, then re-run the installer against your target host. On Windows that second command is `powershell -ExecutionPolicy Bypass -File .\install.ps1 -Target codex`; on macOS and Linux it is `sh ./install.sh --target codex`. The README states that when a previous installation exists, this second command performs a rollback-capable update that preserves task data and runs a startup self-check. The repository also ships UPDATE.md, ROLLBACK.md and UNINSTALL.md as separate documents, which is a better signal than a single paragraph in a README because the rollback procedure has its own file. What the README does not describe is the exact rollback command or how far back a rollback can reach; that detail lives in ROLLBACK.md, which is the file to read before you update, not after. The practical constraint is that updates are manual by design. If you want a host agent that silently tracks upstream, this is the wrong posture, and the project has deliberately chosen the opposite one.

Where PaperSpine5 stops: platform limits, unsigned builds and alpha status

The boundary section is the most useful part of the README because it lists what the project will not promise. The self-contained bundles are verified on Windows x64, Linux glibc x86_64, macOS arm64 and macOS x86_64. Linux arm64 and musl/Alpine are not declared as supported, so container images based on Alpine are outside the stated scope. The macOS bundles are not signed or notarized, which means the first launch may require the user to explicitly allow it; that is a real friction point on managed machines where users cannot grant that permission. The current line is an alpha pre-release, v0.4.0-alpha.1-dev, and the README states there is no independent cryptographic signature on the product. The bundle checksums cover download integrity, not publisher identity. Two further limits are policy rather than technical: the product release does not authorize submission, uploading private material, payment or external contact, and the support entry point is voluntarily maintained, does not unlock features and does not read payment status. If your workflow requires the tool to submit a manuscript or contact a journal, PaperSpine5 is the wrong tool by its own documentation.

PaperSpine5 against a general-purpose writing assistant

The obvious alternative is a general chat assistant with a document plugin, and the difference is not writing quality. A general assistant has no fixed notion of a paper artifact. It will draft prose and stop. PaperSpine5 ships named checkers for artifacts, references, citations, LaTeX and Word output, and it produces editable Word or LaTeX sources plus PDF as the stated deliverable. That means the review step can be mechanical: reference_inventory.py and citation_bank_check.py imply an inventory of references and a bank of citation support that can be compared against the draft, while latex_guard.py and word_guard.py imply format-level checks on the exported files. A chat assistant leaves that comparison to you. The trade-off runs the other way too. A general assistant works anywhere with a browser. PaperSpine5 requires a supported host runtime, a platform-specific bundle, and an installer that touches skill discovery directories. It is also alpha software with unsigned macOS builds. If your paper is a short commentary with a dozen references, the installation and update ceremony probably costs more than it saves. If it is a full manuscript with figures, a citation bank and a LaTeX submission, the guard layer is the reason to accept that ceremony.

Licence and the cost of staying current

PaperSpine5 is MIT licensed, which permits commercial and private use, modification and redistribution provided the licence and copyright notice are retained. The README does not add field-of-use restrictions on top of MIT, and the stated policy limits (no submission, no upload of private material, no payment, no external contact) describe what the product release authorizes rather than what the licence grants. Those are different things, and treating the README boundary as a licence term would be a misreading. For a lab, the practical implication is that the source in src/ can be forked and the projections in dist/ rebuilt for a host the project does not ship. The upgrade cost is the part to budget for. This is an alpha line with a release cadence visible in the repository: v0.3.0-rc.1 on 2026-08-22 and v0.4.0-alpha.1-dev on 2026-09-15, with the last push on 2026-09-17. Frequent pre-release movement plus manual updates plus an archive step for legacy skill directories means every upgrade is a small operation, not a background one. The installers mitigate this by verifying bundle integrity and running a self-check, and the documented update preserves task data, but someone on the team still has to run the check and the update.

Editorial conclusion

Adopt PaperSpine5 if you already run a Codex, Claude or OpenClaw host, want the paper workflow kept on your own machine, and can accept an alpha pre-release whose macOS bundle is unsigned. Do not adopt it if you need Linux arm64 or musl/Alpine support, or if you expect the installer to submit, pay or contact anyone on your behalf, because the documented product release does not do those things. Before installing, read INSTALL.md, ROLLBACK.md and UPDATE.md, confirm the SHA-256 in the public manifest against the bundle you downloaded, and decide whether -CleanLegacy fits your existing V3/V4 skill directories, since it archives known discovery directories rather than deleting them.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. WUBING2023/PaperSpine on GitHub