Ask a model to summarise a blog post and it does fine. Ask it to read a 40-page PDF with a two-column layout, then write a row into the right spreadsheet, and it will produce something that looks correct and is subtly wrong. The gap is not reasoning. It is file formats.
Four official skills close most of that gap: PDF Processing, DOCX Editing, XLSX Analysis, and PPTX Builder. They are unglamorous and they change what you can hand off.
Why format handling is the real bottleneck
A PDF is not a document, it is a set of instructions for placing glyphs on a page. Columns, tables, headers, and footnotes are visual relationships that the file does not label. A model reading raw bytes is guessing at structure.
The same is true of spreadsheets. A .xlsx file is a zip of XML where formulas are stored separately from their computed values. An agent that reads values will confidently quote a stale cache; an agent that reads formulas sees the actual model.
That is why these skills exist: they route the work through libraries that understand the format rather than asking the model to infer it.
What each skill actually buys you
- PDF Processing handles extraction, page splitting, merging, form filling, and table recovery. The useful part is tables: a converted PDF table that keeps its columns is data; one that does not is a paragraph.
- DOCX Editing works on the document model, so headings, styles, and numbering survive. The output opens in Word looking like a document instead of a paste.
- XLSX Analysis reads ranges and formulas and writes values back with formatting. It is the difference between quoting a number and updating a model.
- PPTX Builder builds slides inside an existing master, which keeps fonts and placeholders consistent. It produces a structured draft, not a designed deck.
What the combination enables
Individually each skill saves a step. Together they enable workflows that were previously not worth automating:
| Input | Output | Why it used to fail |
|---|---|---|
| Supplier PDFs | A reconciliation spreadsheet | Table extraction lost columns |
| A contract DOCX | A redlined DOCX | Edits flattened the styles |
| An export CSV | A formula-driven model | Formulas were overwritten as values |
| Notes and a template | A first-draft deck | Slide masters were ignored |
None of these are exotic. They are the tasks that people still do by hand because a wrong output costs more time than the manual work.
The limits worth knowing before you delegate
These skills respect structure; they do not fix ambiguity. A scanned document with handwriting is a different problem, and no amount of format handling will help. A spreadsheet with circular references will still behave badly.
There is also a review obligation. An agent that fills a form can fill it with plausible, wrong values. The output needs a human check at the same place you would check a junior colleague's work — which is to say, at the point where the data enters a system of record.
A realistic adoption order
Start with PDF extraction on documents you already read manually. Compare the agent's output against what you would have written. If the tables survive, add XLSX. Only then consider writing into files that other people depend on.
The order matters because each step increases trust in a tool you cannot fully verify. Reading is cheap to check; writing is not.
A worked example: the monthly invoice pile
A finance team receives forty supplier PDFs a month, in six different layouts. The manual process is copy the total and the invoice number into a sheet, then reconcile against the ledger.
With the PDF skill, the agent extracts text and tables from each file, normalises the layout into rows, and writes them into the workbook. The XLSX skill keeps the formulas intact while doing it, so the reconciliation column still calculates.
What used to be a two-hour job with a spreadsheet open becomes a fifteen-minute review. The review is the important part: the agent can read a total that is wrong, and only a human comparing against the supplier's own line items will catch it.
The three checks we run on document output
- Column integrity. If the extracted table has fewer columns than the source, the columns were merged or dropped. That is a failed extraction, not a formatting quirk.
- Number reconciliation. Every total should equal the sum of its parts. An agent that extracts a subtotal as a total produces a plausible, wrong number.
- Style survival. Reopen the output file. If headings became bold paragraphs, the edit flattened the structure and the next person to open it will fight the formatting.
Frequently asked questions
Do I need all four skills? No. Most teams get value from PDF and XLSX first, because those are where extraction and reconciliation happen. DOCX and PPTX matter when the deliverable is a formatted file.
Are these official Anthropic skills? Yes — they come from the public skills repository and are installed the same way as other skills. That matters for maintenance: an official skill is more likely to keep working across agent updates.
What about scanned PDFs? Text extraction will fail differently: you get OCR noise rather than columns. Treat scanned documents as a separate problem and validate the output line by line.
Last checked: 9 November 2026.
Related: Agent skills, the MCP install checklist, and what a skill is.