docx-cli
kklimuk · kklimuk/docx-cli
Cho phép các agent AI đọc, chỉnh sửa và thêm bình luận vào các tệp .docx trong khi vẫn giữ nguyên định dạng, với các thay đổi có thể được con người xem xét trong Word.
CLI dành cho AI agent (Claude, Codex) để đọc, chỉnh sửa và bình luận trên các tệp .docx với độ trung thực định dạng đầy đủ.
Xem trước
Bạn có thể làm gì với nó
- Tự động đánh dấu và bình luận trên các hợp đồng pháp lý trong Word.
- Cho phép các agent AI điền biểu mẫu trong tài liệu .docx một cách chính xác.
- Chỉnh sửa tài liệu Word bằng AI trong khi vẫn giữ nguyên tất cả định dạng tùy chỉnh.
Kiểm tra an toàn
Dùng được, nhưng nên đọc ghi chú trước.
- ●Có câu lệnh cố ghi đè chỉ dẫn của agent hoặc giấu hành động khỏi bạn.
skills/docx-cli/SKILL.md
Quét tự động các file trong repo. Luôn xem lại code trước khi chạy.
Trích từ 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