Word skill (skill_id: docx)

Why you'd careThe problem it solves

Legal sends you a contract as .docx and wants three clauses redlined. Or you have a letter template and 200 recipients. Or the compliance report has to arrive in the format the regulator's portal accepts, which is Word and only Word. In every case the deliverable is not text that describes a document — it is the document, with styles intact, tracked structure preserved, and the recipient's ability to keep editing it unbroken. Pasting markdown into Word destroys all three. The docx skill is the packaged path from an uploaded Word file to a modified Word file. The thing that trips teams up is not the mechanism, which is straightforward, but the boundaries between surfaces: what you set up in one place does not follow you to another, and people lose an afternoon to that.

ConceptWhat it is

The Word skill is an Anthropic-authored skill directory for producing and editing .docx documents with real formatting — headings, styles, tables, lists — and, distinctively among the document skills, for reading and modifying an existing file you upload rather than only generating from scratch. It is a filesystem-based skill living on the code-execution container, declared as {"type": "anthropic", "skill_id": "docx"} in container.skills alongside the code-execution tool.

Its nearest neighbour is the PDF skill, and the difference is round-tripping. A PDF is a terminal format: you generate it and someone reads it. A .docx is a working format: someone opens yours, edits it, and sends it back. That makes the edit path — parse, modify, rewrite, preserve everything you did not touch — the interesting part of this skill rather than an afterthought.

The moving parts are the same four as its siblings: the skill directory, the progressive-disclosure ladder, the container filesystem where the input file is mounted and the output written, and the Files API for both directions. There is a fifth that is easy to miss, and it is the one that causes support tickets: the scope the skill was registered in. Hosted skills like docx are global, so this bites you on custom skills rather than this one — but the boundary it draws applies to every surface question on this page.

How it worksThe mechanics

The flow for an edit, rather than a generation, is: upload the source file through the Files API, reference it as a container input on the request, declare the skill and the code-execution tool, and describe the change in the prompt. Claude reads SKILL.md once the request matches its description, then writes Python against the bundled scripts and the document library, runs it in the sandbox, and writes a new file. Word documents are not edited in place; you get a new file ID. No beta header is involved: code execution, Skills and the Files API are all out of beta.

anthropic-version: 2023-06-01

"container": {
  "skills": [{"type": "anthropic", "skill_id": "docx", "version": "latest"}]
},
"tools": [{"type": "code_execution_20260521", "name": "code_execution"}]

Now the part the source row flags as a common mistake, and it deserves the space. Custom skills do not sync between claude.ai and the API. There are at least three separate stores, and only one narrow bridge between them:

• A custom skill uploaded through claude.ai belongs to that account's consumer surface. Your API key cannot name it.
• A custom skill registered through the Skills API (POST /v1/skills, no beta header since it left beta) is a workspace resource with a skill_... ID. It is what API requests and Managed Agents can reference. It does not appear in claude.ai.
• A skill in Claude Code is a folder on your disk. It is discovered by the filesystem, versioned by your repo, and has no ID in any registry. The one bridge is a download: Claude Code copies the custom skills enabled on your claude.ai account into ~/.claude/skills/synced/ — automatically in Cowork and cloud sessions, or on your machine in a non-interactive run with CLAUDE_CODE_SYNC_SKILLS=1. The docs describe no path back to claude.ai, and none to the API.

The hosted docx skill is the exception that proves the rule: it is available on every surface that runs Anthropic's container, precisely because Anthropic publishes it rather than you. The moment you customise it — fork it, add your house style guide — you own a custom skill and inherit all three boundaries.

At a glanceSee it

A Word file round-tripping through the container, with the cross-surface boundary marked.

Where it runsSurfaces and availability

Read this table twice: once for where the hosted skill runs, and once for where a custom version of it would run. Those are different answers, and the docs say so outright — "Custom Skills do not sync across surfaces", with Skills uploaded to claude.ai unavailable to the API and vice versa, and Claude Code Skills separate from both. That last clause is now stale: Claude Code's own docs describe it downloading the skills enabled on your claude.ai account, one way. The hosted one is broadly available; a fork of it is scoped to whichever store you registered it in. Teams that plan a single "our document skill" and then discover it needs registering three times — browser, API, repo — have almost always missed this distinction at design time. Checked against primary sources 2026-07-25.

ExampleIn the real world

A contracts team runs a first-pass redline. The workflow uploads msa-vendor-draft.docx through the Files API, then sends a request naming skill_id: "docx", the code-execution tool, and a prompt: apply the company's standard positions on limitation of liability, governing law and payment terms; leave everything else untouched; add a comment at each change explaining the position.

Claude loads the skill, then writes a script that opens the document, walks its paragraphs to locate the three clauses by heading and text, rewrites those runs while preserving their character styles, and inserts comments. It deliberately does not reflow the rest of the document — the skill's instructions push toward surgical edits, because a regenerated document loses the counterparty's numbering and formatting and lands badly in review.

Stdout reports which clauses were found and which were not: governing law was under a heading the script did not expect, so Claude adjusts its locator and re-runs.

The output is msa-vendor-draft-redlined.docx under a new file ID. A lawyer opens it in Word, sees the three changes and the comments, accepts two, rejects one, and sends it back. Nothing in that loop required anyone to retype a clause — which is the only version of this feature that survives contact with a legal team.

Not thisWhat it is often confused with

• Not a shared skill librarya custom skill uploaded on claude.ai, one registered via the Skills API, and one sitting in a Claude Code folder are three separate artefacts. Editing one changes nothing about the others — with one exception: change a skill on claude.ai and the copy synced into Claude Code follows on the next sync.
• Not tracked changesunless you ask for it and verify the output, "redline" means edited text plus comments, not Word's revision-tracking feature. Check what actually lands before promising a reviewer they can accept and reject.
• Not a document parser for retrievalif your goal is to answer questions across a thousand Word files, that is an indexing problem. This skill opens one file, changes it, and closes it.
• Not a system promptthe skill's instructions load only when a request matches its description, and the bundled scripts never enter context at all. A system prompt is paid for on every request, whether or not the task is about documents.
• Not a subagentno separate context window is spawned. The main model reads the skill and drives the container itself.

LimitsWhen not to reach for it

• The recipient wanted a PDF.Generate the PDF directly rather than producing a .docx and converting; the conversion step is where formatting goes wrong.
• You are mail-merging a fixed template.That is a deterministic loop over a data source. Write it once in python-docx and run it in your own infrastructure; a model in the loop adds variance you do not want in 200 letters.
• Users need to work in the document together.A file-in, file-out skill has no concept of concurrent editing. Reach for the collaboration platform's own API.
• You only need to read the document.Extracting facts from a Word file may not need a skill or a container at all — check whether plain document input on your surface already covers it.
• You are on Bedrock or Vertex.Nothing degrades gracefully here; the feature is simply absent. Plan the alternative before the sprint, not during it.

RelatedGo deeper