Office Deliverable Skills: Ten You Can Actually Install

The list first: ten entries, install commands below

How to install (commands copied from each official page)

# 1-4 in Claude Code: one command for all four (marketplace is anthropic-agent-skills)
/plugin marketplace add anthropics/skills
/plugin install document-skills@anthropic-agent-skills

# 6-9 ship in the other plugin, together (plus skill-creator, mcp-builder and more)
/plugin install example-skills@anthropic-agent-skills

# 5 on the Claude API: not "installed" but named in the container, with code execution on
container: { skills: [ { type: "anthropic", skill_id: "pptx" } ] }
# Only four skill_ids exist: pptx / xlsx / docx / pdf

# 10 markitdown: the reading half, installed with pip
pip install 'markitdown[all]'
# Only need three formats? Do not pull the lot:
pip install 'markitdown[pdf, docx, pptx]'
# There is an MCP build too, exposing exactly one tool: convert_to_markdown(uri)
pip install markitdown-mcp

# Two things to do right after installing
/skills          # see the list, switch off what today does not need
/skill-doctor    # per-skill token cost and invocation frequency (v2.1.252+)

One by one, in plain words

• 1 docx: not "call a library and get a Word file". The top layer of SKILL.md is a decision tree — create means a Node script using the docx package, edit means unzip, change word/document.xml, rezip, read means one line of pandoc -t markdown. The real value is scripts/merge_runs.py: Word shreds a sentence into a chain of runs, and without merging them first, nine find-and-replace attempts out of ten silently miss. It also ships accept_changes.py for tracked changes and comment.py for comments, which touch six cross-linked files at once.
• 2 pptx: create via pptxgenjs, edit by unzipping XML, read via markitdown or a thumbnail grid from scripts/thumbnail.py. Its gotcha list is unusually honest: set the layout before adding slides (the default is 10 x 5.625 inches, not 13.3), hex colors carry no #, and shadow option objects must never be reused across calls. Always finish with scripts/office/validate.py, which checks schema, relationships and charts.
• 3 xlsx: openpyxl writes formulas, pandas loads bulk data, markitdown gives a quick look — and the step that matters is running scripts/recalc.py afterwards, because openpyxl writes formulas but never computes them. Skip it and you ship a sheet full of = signs and no numbers. Its stated limits are worth copying down: no spilling array functions (XLOOKUP, FILTER, UNIQUE, SEQUENCE; use INDEX+MATCH), post-2007 functions need the _xlfn. prefix to survive recalculation, data_only=True loads cached values and destroys formulas on save, and external links are stripped on re-save.
• 4 pdf: the broadest of the four — pypdf or qpdf for merge, split and rotate, pdfplumber for text and tables, reportlab for new files, pytesseract plus pdf2image for OCR on scans, and a separate FORMS.md for filling forms. It is the only one of the four that never unzips OOXML, which also makes it the only one that does not depend on LibreOffice.
• 5 the pre-built four: Anthropic-hosted, ready on claude.ai, named on the API by skill_id. Two hard constraints: the code execution tool is required (skills run inside its container) and that container has no network access and no runtime package installation. The docs state plainly that Claude Code does not offer the pre-built document skills. So the answer to "it works in the browser, why not in my terminal" is right here: what you want is entries 1-4.
• 6 doc-coauthoring: the only entry on this list that bundles no scripts at all. What it gives you is a process — transfer your domain knowledge first, draft section by section, then test the result against a fresh reader who lacks your background. Its relationship to entry 1 is content versus container: think it through with this one, then pour it into Word with docx.
• 7 internal-comms: four house-style files — 3p-updates.md (progress, plans, problems), company-newsletter.md, faq-answers.md, general-comms.md — and you load the one that matches. Its description is strikingly personal: help me write internal communications in the formats my company likes to use. That phrasing is a signal: the right move with this class is to fork it and drop in your own house style, not to install it as is.
• 8 theme-factory: ten preset themes (Ocean Depths, Modern Minimalist, Midnight Galaxy and others), with a theme-showcase.pdf so you can look before choosing, plus on-the-fly generation of new ones. It is a clean specimen of separating style from content: a theme is just hex values paired with fonts, applicable to slides, docs or landing pages alike.
• 9 brand-guidelines: note that it ships Anthropic's own brand — primary #141413, Poppins for headings, Lora for body, with background-aware color choice and fallbacks to Arial and Georgia. Installing it unchanged hangs someone else's sign over your shop; the right use is as a template with your palette swapped in. Skill 15 of this series digs into that class on its own.
• 10 markitdown: officially "a Python tool for converting files and office documents to Markdown", eating PDF, Word, Excel, PowerPoint, images (EXIF and OCR), audio (transcription), HTML, CSV, JSON, XML, ZIP and EPub. It is not a skill; it is the lower-level tool the four keep calling — the "read" step in entries 2 and 3 is literally this. It stands alone perfectly well, and it is the only entry here that works in every environment.

Why these ten cannot share one ranking: three kinds of thing, one table

Three shapes

1. Deterministic, script-bearing (1, 2, 3, 4) — the shared structure is: a decision tree in SKILL.md, deterministic operations in scripts/, and a validation script closing the feedback loop. The criterion here is "which specific trap do its scripts catch for me", not "how well is it written". The price is environment dependencies: entry 2's validation chain needs LibreOffice, entry 4's OCR needs tesseract.
2. Pure process (6, 7, 8, 9) — not a line of code, only prose and examples. The criterion is whether its examples are the kind you actually want. Entries 7 and 9 are conspicuously templates rather than products: one ships another company's status-report conventions, the other another company's palette.
3. Lower-level tool (10) — it takes no part in skill triggering; skills call it. It sits in this table only because in real work it always shows up alongside entries 1 through 4.

And one thing that fits no shape

"Template skill" sounds like a category of tool. It is really a structure: one decision tree, a set of reference files read on demand, and a checking step that can tell right from wrong. Entries 1-4 are that structure applied to file formats; entries 7 and 9 are the same structure applied to prose. Once you see it, your own contract templates and quote sheets are built exactly the same way.

Three-minute inspection: six criteria, with these ten as the yardstick

1. Is there a step that can tell right from wrong? Entry 2's validate.py, entry 3's recalc.py and entry 1's soffice conversion check are the positive samples. A document skill with no validation step is asking a model to write a binary format blind — and the most expensive bug in this class is "the file was produced, but it will not open".
2. Are deterministic operations scripts, or improvised? Merging runs, recalculating formulas, accepting tracked changes: single correct answers, no judgement required. As scripts they cost fewer tokens and cannot drift (the code never enters context; only its output does). A SKILL.md that is all "you could write code like this" with no scripts/ has handed the model work it should never have been given.
3. Does it admit its limits? Entry 3 puts "no spilling array functions" and "data_only=True destroys formulas" in the body, and that half page buys more trust than anything else on this list. A skill that lists only what it can do leaves you to discover the rest by stepping on it.
4. Is it shipping a process, or someone's preferences? Entry 6 gives a process you use as is; entries 7 and 9 give Anthropic's own conventions and palette, and those you fork rather than install. The tell is easy: read the description, and treat anything containing "my company" or "Anthropic's official" as a template.
5. Are environment dependencies stated up front? Entries 2 and 3 need LibreOffice to convert and recalculate; entry 4 needs tesseract for OCR. Check the machine your agent runs on before installing — this failure never announces itself as "the skill is bad", it announces itself as a command-not-found you cannot parse.
6. Does it even exist in your environment? This one is specific to the office class: the same capability reaches claude.ai, the API and Claude Code by three different roads (pre-built, skill_id, plugin install), and they do not interoperate — the docs devote a section to custom skills not syncing across surfaces. Ask "where will I use this" before you install anything.

The honest cost: what the bill for this class looks like

The light part first

The docs are specific: only name and description stay resident, roughly 100 tokens per skill; the body is read when triggered, usually under 5k tokens; bundled files cost nothing until read (per the platform.claude.com Agent Skills documentation, 2026-09). Claude Code adds a sharper number: the combined skill descriptions are truncated at 1,536 characters — which means that once you install enough of them, descriptions past the cut are simply gone and those skills stop triggering at all. That is far worse than a few hundred tokens. Use /skill-doctor for real per-skill token cost and invocation frequency, and switch off via /plugin anything whose purpose you cannot recall.

Now the heavy part

• Environment dependencies are a real gate. The full chain for entries 1, 2 and 3 wants LibreOffice (soffice); seeing entry 2's output also wants pdftoppm; entry 4's OCR wants tesseract. On a clean CI box, half of this suite is mute.
• The API container has no network and no package installs. Entry 5 runs inside the code execution sandbox: no external calls, no runtime installation, pre-installed packages only. An office skill of your own that targets the API must keep its dependencies inside that list.
• The license is not MIT. Entries 1-4 carry license: Proprietary in frontmatter, and the repo README adds "for demonstration and educational purposes only". Read LICENSE.txt before adapting any of it into a commercial product — this series will meet that question again.
• Installed is not the same as understood. Entry 3's limit list is the best example: not knowing it rejects XLOOKUP leaves you puzzling over a sheet full of #NAME?. The learning cost in this class is not in installation; it is in the half page of limits the author was honest enough to write down.
• Trigger conflicts, as ever. Entries 1 and 10 can both "read a docx"; entries 6 and 7 can both "write a document". Two descriptions for one capability means the model chooses every time — which is the concrete reason not to re-upload the open-source copy on claude.ai.