docx-cli
kklimuk · kklimuk/docx-cli
Enables AI agents to read, edit, and add comments to .docx files while preserving formatting, with changes human-reviewable in Word.
CLI for AI agents (Claude, Codex) to read, edit, and comment on .docx files with full format fidelity.
Preview
What you can do with it
- Automate redlining and commenting on legal contracts in Word.
- Have AI agents fill out forms in .docx documents accurately.
- Edit Word documents with AI while preserving all custom formatting.
Safety check
Usable, but read the notes first.
- ●Contains instructions that try to override the agent or hide actions from you.
skills/docx-cli/SKILL.md
Automated scan of the repo files. Always review code you run.
From the README
docx-cli
A .docx CLI built for AI agents. Leave comments, suggest redlines, and edit Word documents without breaking the formatting or losing content — a human accepts or rejects in Word afterward.
- Hand a
.docxto Claude or Codex and get back a redlined copy with comments — open it in Word, accept or reject as usual. - Agents address text by stable locators with character offsets (
p3:5-20); humans see normal Word formatting on disk. - Custom styles, theme colors, embedded objects — all of it survives. The CLI mutates XML in place rather than re-emitting from a lossy model.
Why docx-cli?
The default way agents edit Word docs is to unzip the .docx and hand-write the OOXML inside. That takes a strong model to get right, burns tokens, and routinely produces a file Word won't open. docx-cli hands the agent plain commands plus an annotated-Markdown read view, so it never has to reason about the XML.
We measured it — a controlled A/B bake-off: six real document tasks (fill an NDA, fill an invoice, restyle a résumé, redline a contract, finalize a contract, author a journal), the same starting files, and one independent judge grading every result from the Word-rendered pages. Three runs per arm at each of two model tiers. Haiku columns: July 2026 rerun on v0.20.4; Sonnet columns: June 2026 bake-off (not Sonnet 5):
| Haiku (weak, cheap) | Sonnet (strong, June run — not Sonnet 5) | |||
|---|---|---|---|---|
| docx-cli | default skill | docx-cli | default skill | |
| Tasks solved (of 6) | 5.0 (5–5) | 0.7 (0–2) | 6.0 (6–6) | 4.0 (4–4) |
| Rendered correctly (of 6) | 6.0 | 4.3 | 6.0 | 4.7 |
| Outright-broken documents | 0 | ~1.3/run (up to 2) | 0 | 0 |
| Effective input tokens | 3.2M | 7.9M (2.5×) | 1.6M | 3.6M (2.2×) |
| Output tokens | 78k | 155k (2.0×) | — | — |
| Wall-clock | 1,186 s | 2,438 s (2.1× slower) | 1,175 s | 2,029 s (1.7× slower) |
- The correctness gap is widest on the cheap Haiku tier (~7×), and a frontier model never closes it — the default skill caps at 4/6, losing the contract redline and the résumé every Sonnet run.
- The cost and speed penalties are model-independent — ~2.2–2.5× more input tokens and ~1.7–2.1× slower at both tiers, with token/time ranges that never overlap. (Output tokens, measured in the July rerun: 2× more for the default skill. The June Sonnet run measured input only.)
- Word couldn't reliably open the default skill's work — in the July Haiku runs it failed to open 4 of the skill's 18 outputs (both legal-redline deliverables in 2 of 3 runs); all 18 of docx-cli's opened on the first try.
Full methodology, per-task rubrics, and the harness that produced these numbers: .claude/skills/weak-agent-test.
Install
npm — the simplest path (requires Bun >= 1.3):
bun add -g bun-docx
# or run without installing:
bunx bun-docx read doc.docx
Standalone binary (no Bun required). Every release publishes prebuilt binaries, the installer, and a SHA256SUMS manifest covering all of them; the installer verifies the binary's SHA-256 before installing:
curl -fsSLO https://github.com/kklimuk/docx-cli/releases/latest/download/install.sh
sh install.sh
install.sh is a release asset, not a file served from a moving branch — so it is immutable per release and listed in that release's SHA256SUMS. (Published from v0.23.0 onward; on earlier releases use the npm path above.) To verify it before running it:
curl -fsSLO https://github.com/kklimuk/docx-cli/releases/latest/download/SHA256SUMS
shasum -a 256 -c SHA256SUMS --ignore-missing # or: sha256sum -c …
sh install.sh
macOS artifacts built by the current release workflow are ad-hoc signed and signature-verified before checksumming; they are not Developer ID-signed or notarized.
Honors PREFIX (default $HOME/.local/bin) and VERSION (default latest). Pre-built for linux/x64, linux/arm64, darwin/x64, darwin/arm64, windows/x64.
Once installed, docx upgrade updates a standalone binary — it replaces the binary wherever it already lives (PREFIX does not apply), running the same installer embedded in the binary at build time rather than fetched, so the download stays pinned to a release tag and SHA-256-verified. --to v0.23.0 pins a version, --dry-run reports what would change. On an npm/bun install it tells you to use the package manager instead.
Prefer to skip the script entirely? Download docx- + SHA256SUMS from the latest release, verify, chmod +x, and put it on PATH.
Quick example: filling out an NDA
The repo includes a Common Paper Mutual NDA template at tests/fixtures/mnda.docx. Below are the primitives an agent would compose to fill in the cover page and leave redline edits — the same flow shown in the video above. Every command was verified end-to-end against the fixture:
# Make a copy first — there's no undo (git is the history; the CLI overwrites in place)
cp tests/fixtures/mnda.docx mnda-filled.docx
# Read the cover-page table so the agent knows what placeholders exist
docx read mnda-filled.docx --from t1 --to t1
# Fill the yellow-highlighted br