Anthropic's official skill pack: PDF, XLSX, DOCX, PPTX and where they shine

Published 2026-05-11 by Owner

Most Claude Code sessions stay in the text-and-code lane: read a file, edit a file, run a command. That works until a user hands you a PDF expense report, asks for an Excel summary, or wants a slide deck drafted. Without the right tooling, Claude reaches for generic Python and produces brittle one-off scripts.

The anthropic-skills pack is Anthropic’s answer. It installs eight skills for Claude Code — four document-handling skills and four meta/utility skills — each with clear triggering conditions and well-scoped responsibilities. The document skills call Python libraries (openpyxl, python-docx, pptx, etc.) under the hood, so they handle the file format details that would otherwise eat the first half of every script you ask Claude to write.

The four document skills and what triggers them

Each document skill fires on specific signals in the user’s message. If the signal is absent, Claude won’t invoke the skill and will handle the request another way.

pdf triggers on:

• A .pdf file path or attachment in the conversation
• Explicit phrases like “extract from PDF”, “split this PDF”, “fill out the form”
• Requests for OCR (the skill wraps OCR tooling when extracting from scanned pages)

xlsx triggers on:

• A .xlsx, .xls, or .csv filename
• Phrases like “spreadsheet”, “tabular data”, or “create a workbook”
• Requests that involve Excel formulas or charts

docx triggers on:

• A .docx or .doc filename
• Requests mentioning “Word document”, “table of contents”, “track changes”, or “find and replace in a document”

pptx triggers on:

• A .pptx filename
• Requests for “slides”, “presentation”, “speaker notes”, or “deck”

The triggering logic matters because it tells you what to say when you want a specific skill. If you type “summarize this data” without mentioning a spreadsheet file, Claude may write a script that prints to stdout rather than produce an .xlsx file. Mention the format explicitly: “summarize this data into an Excel workbook” routes to xlsx; “summarize this data” does not.

The docx and pptx skills follow the same pattern. “Write a report” without a .docx mention may produce a markdown file. “Write a report as a Word document” invokes docx, which uses python-docx to produce a properly formatted .docx file with styles, page numbering, and a table of contents if requested. The same specificity applies to pptx: “make some slides about Q1 results” is ambiguous; “create a .pptx presentation with speaker notes” triggers the PowerPoint skill.

This is one of the few places where being explicit with Claude Code produces a qualitatively different output, not just a stylistically different one. The file format is the deliverable.

When the PDF skill earns its keep — and when it doesn’t

PDF extraction is the clearest case where the skill saves real work. A scanned PDF of a vendor invoice is not text: it’s an image of text. Without the skill, Claude would have to ask you to copy-paste the content. With pdf, the OCR pipeline runs, text gets extracted, and you get structured output.

Cases where pdf adds real value:

• Splitting a PDF into individual pages or page ranges (useful for distributing sections of a contract)
• Merging multiple PDFs into one (the skill handles page ordering and metadata)
• OCR on scanned documents — bank statements, physical forms, older documents that were never digital
• Form field extraction from PDF forms (the skill can read form field names and values, not just visual text)
• Table extraction from PDFs where the visual layout is a grid but the underlying text is a flat string

Cases where pdf is overhead:

• A modern, text-based PDF that Claude’s Read tool already handles. If you’ve pasted or attached a PDF and Claude can read the text in it, the pdf skill adds a Python subprocess and latency for no gain.
• Quick Q&A about PDF content when you just want an answer, not a file output.
• Single-page documents where copy-pasting the relevant section is faster than setting up an extraction pipeline.

The practical rule: reach for the pdf skill when you need a file transformation or a structured data extraction. For “what does this PDF say on page 4?”, Read is faster.

The XLSX skill’s spreadsheet-first contract

The xlsx skill is opinionated: its output is an Excel file. That’s the right tool when:

• A stakeholder needs the result in .xlsx (finance team, operations, anyone who lives in Excel)
• You want formulas, conditional formatting, or named ranges preserved or created
• You’re building a chart that needs to stay editable in Excel rather than be exported as an image
• You’re cleaning data and need to hand the cleaned file back to the user

Where the skill is the wrong choice:

• Data going into a database: write Python or SQL directly. The round-trip through Excel adds format conversion with no benefit.
• HTML tables or reports: a Jinja template or plain Python dictionary is less brittle and easier to version-control than an Excel file.
• Quick tabular output in chat: if you just want a readable table in the conversation, a markdown table doesn’t need xlsx at all.

The skill uses openpyxl for .xlsx and can read existing files to update them in place, which is often more useful than generating a fresh workbook. If you have a report template that finance uses every quarter, the xlsx skill can populate its named ranges from new data without touching its formatting.

The same “file-in, file-out” contract applies to docx and pptx. The docx skill targets documents that will be edited further by a human — legal contracts with tracked changes, specs with a table of contents, onboarding guides where someone will adjust the formatting. The pptx skill targets presentations where the slides need to be handed off in a format that allows editing: updating speaker notes, reordering slides, adjusting layouts before a meeting. Neither skill is a substitute for a design tool, but both produce structurally sound files that don’t need to be rebuilt from scratch by the recipient.

skill-creator and consolidate-memory — the two meta-skills

These two are unrelated to document handling. They operate on the skills and memory layers themselves.

skill-creator is for authoring new skills — not using them. It provides scaffolding for writing the YAML descriptor, the eval harness, and the optimization loop that makes a skill more reliable over iterations. If you find yourself repeating a complex multi-step workflow (a deploy checklist, a data pipeline, a PR review template), skill-creator is the path to codifying it into a first-class skill with a name and triggering conditions.

consolidate-memory does a reflective pass over your Claude Code memory files — the CLAUDE.md files and any accumulated notes from past sessions. It identifies contradictions, stale facts, and redundant entries, then proposes pruning. A memory file that started at 30 lines and grew to 200 over six months often has a lot of “note to self” entries from early sessions that no longer apply. This skill runs a structured review rather than a manual grep through markdown.

Neither of these is a document tool. Don’t expect them to produce a PDF or a spreadsheet.

A good time to run consolidate-memory is after an intensive project wraps up — the session will have added notes, constraints, and reminders to your CLAUDE.md that were accurate in context but won’t hold next month. Running the skill then rather than later keeps the memory file lean and prevents the model from anchoring on stale context. A 200-line CLAUDE.md is not a virtue; it’s a tax on every future session.

A concrete pipeline: PDF invoice → XLSX summary

Here’s how the skills interlock on a real task: “extract line items from these three vendor invoices and produce an Excel summary with totals.”

Step 1 — PDF extraction (the pdf skill)

The skill runs OCR on each invoice, identifies the line-item table, and returns structured data — item name, quantity, unit price, total — for each page. If the invoices are scanned images, OCR handles the text layer. If they’re text-based PDFs, extraction is direct.

Step 2 — XLSX construction (the xlsx skill)

The structured line-item data from step 1 feeds into the xlsx skill, which builds a workbook:

Sheet: "Invoices"
Columns: vendor | invoice_date | item | qty | unit_price | line_total
Row 1..N: one row per line item across all three invoices

Sheet: "Summary"
=SUMIF(Invoices!A:A, A2, Invoices!G:G) — total by vendor

The formulas are native Excel formulas, not computed values pasted as static numbers. The finance team can open the file and trust that the totals will update if they correct a cell.

This two-skill pipeline is cleaner than a single Python script because the concerns are separated. The pdf skill owns “get structured data out of this document format.” The xlsx skill owns “write it into a spreadsheet that Excel users can work with.” Each is testable independently.

The pipeline also composes with the other document skills. If the final deliverable is a Word document rather than an Excel file, swap step 2: feed the extracted invoice data into docx and get a formatted report with a table and a header per vendor. The prompt is straightforward — “take the line items you extracted and write a Word document with one section per vendor” — and the skill handles the formatting details that would otherwise require wrestling with python-docx directly.

What the skills don’t replace

The anthropic-skills document pack is a document-handling layer, not a general data-processing engine. For transformations that stay entirely in code — parsing a CSV, joining two datasets, writing to a database — plain Python or SQL is the right tool. Adding an Excel file as a waypoint for data that will never be touched by a human adds unnecessary file I/O and format coupling.

The skills earn their keep at the interface between automated pipelines and human workflows. When the output lands in a human’s hands in a format they expect to open in Office, the skills close that gap cleanly.

The schedule and setup-cowork skills round out the pack (cron-style scheduled tasks and guided collaboration setup, respectively), but those are worth a separate look once the document layer is working well for your setup.

The document skills are stable enough to rely on for production pipelines. The install is a single command, the triggering is predictable once you’ve internalized what each skill listens for, and the file-in/file-out contract makes each skill easy to test in isolation. Start with the skill that matches the document format you encounter most often, and the others will slot in naturally once the pattern is familiar.