Vision

docex exists because editing Word documents should not require Word. Academics, researchers, and developers who live in the terminal should be able to produce the same .docx files that journals, publishers, and collaborators expect, without ever opening a GUI.

Workflow 1: Solo editing

You write a paper. You get peer review feedback. You need to make tracked changes and respond to each comment. Instead of clicking through Word menus, you work in the terminal.

1

Decompile the manuscript

docex decompile paper.docx -o paper.dex

Your .docx becomes a plain text file you can read and edit in any editor.

2

Make your edits

# Fix the number reviewers flagged
docex replace paper.docx "12,847" "300,000" --author "Alex"

# Reply to Reviewer 2's comment
docex reply paper.docx 5 "Added citation." --by "Alex Chen"

# Insert a new paragraph after Methods
docex insert paper.docx "after:Methods" "We used a mixed-methods approach."

Every edit is tracked. The reviewer will see strikethrough and insertions in Word.

3

Format for the journal

# Apply Political Communication formatting
docex style paper.docx --preset polcomm

# Verify it meets submission requirements
docex verify paper.docx --preset polcomm

4

Submit

Upload the .docx. The editor sees a professionally formatted manuscript with tracked changes and comment replies. They never need to know you used the terminal.

paper.docx from journal

→

docex CLI replace, comment, style

→

revised.docx tracked changes

Workflow 2: With collaborators

Your co-author uses Word. You use vim. Neither of you needs to change. The .dex format is the bridge.

1

Co-author sends you a .docx

They made edits in Word. The document has tracked changes and comments.

2

You decompile and work in plain text

# See what they changed
docex list paper.docx revisions
docex list paper.docx comments

# Decompile to .dex for a full view
docex decompile paper.docx -o paper.dex

# Edit the .dex in your editor, then compile back
docex compile paper.dex -o paper-updated.docx

3

Version control with git

# The .dex file is plain text, so git diffs are meaningful
git diff paper.dex

# Commit your changes
git add paper.dex
git commit -m "respond to reviewer 2 comments"

Unlike binary .docx files, .dex diffs show exactly what changed. Line-by-line.

4

Send back the .docx

Your co-author opens it in Word and sees clean tracked changes. They accept or reject as usual.

Co-author edits in Word

→

.docx email / cloud

→

You .dex + git

→

.docx back to co-author

Workflow 3: With AI agents

An AI agent reads your manuscript, understands the reviewer comments, and drafts a response. It makes tracked changes attributed to you, adds reply comments, and saves. You review the result in Word.

1

Connect the AI agent via MCP

{
  "mcpServers": {
    "docex": {
      "command": "node",
      "args": ["src/mcp-server.js"]
    }
  }
}

The MCP server exposes docex operations as tools. The AI agent can open, edit, and save .docx files.

2

AI reads the document

The agent decompiles the manuscript to .dex, reads the reviewer comments, and understands the full context. It sees:

{comment id:5 by:"Reviewer 2" date:"2026-03-15T10:00:00Z"}
The authors need to justify their classification methodology.
How was inter-coder reliability measured?
{/comment}

3

AI makes edits

The agent calls docex tools to make tracked changes and reply to comments, all attributed to you:

# AI calls these operations via MCP:
doc.author("Alex Chen");
doc.after("Classification Pipeline").insert(
  "Inter-coder reliability was measured using Krippendorff's alpha..."
);
doc.at("classification methodology").reply(
  "Added inter-coder reliability section. Alpha = 0.87.",
  { by: "Alex Chen" }
);

4

You review in Word

Open the .docx in Word. Every change shows as a tracked change attributed to you. Accept what you like, reject what you do not. The editor sees your name, not an AI's.

Reviewer comments in .docx

→

AI Agent reads .dex, calls docex

→

revised.docx tracked changes by you

→

You review in Word

The bigger picture

Plain text is a superpower

When your document is plain text, you can use every tool that works on text: grep, sed, diff, git, scripts, AI. Binary .docx files lock you out of this ecosystem. The .dex format unlocks it.

Zero data loss is non-negotiable

Other converters lose formatting, comments, tracked changes, or metadata. docex preserves everything. The round trip from .docx to .dex and back produces a byte-level equivalent document.

No dependencies, no lock-in

docex is zero-dependency Node.js. No npm install. No Python. No Java. No LibreOffice. No cloud API. Just clone the repo and run. It will work in 10 years.

Who is this for

You are...	docex lets you...
An academic who hates Word	Respond to peer review from the terminal. Format for any journal with one command.
A developer building document tools	Edit .docx files with a clean API. No XML. No OLE. No COM objects.
An AI agent operator	Give your agent the ability to read and edit Word documents. Full tracked changes, comments, and formatting.
A researcher managing many documents	Batch-process hundreds of .docx files. Apply formatting, extract data, validate against journal specs.
Someone who wants git for documents	Convert to .dex, commit to git, see meaningful diffs, collaborate without merge conflicts.

Get started

git clone https://github.com/favstats/docex.git
cd docex
docex decompile your-document.docx

Try the playground View on GitHub