Preview
What it is.
The reason to care is handoff. A brief, a one-pager or a report that opens correctly in Word and in Google Docs is the difference between a deliverable and a support conversation, and this skill lists the exact settings that break each one.
Tables are the usual failure. It requires column widths on the table and a width on every cell, both in the same unit, because percentage widths break in Google Docs. Table shading has to be set as clear and not solid, or it renders black.
The last step is the one people skip: convert the document to PDF, render the pages as images, and look at them. A document nobody opened is a document nobody checked.
What you get.
- Word documents created from a script, or edits to a file you already have
- Tables that hold their layout in Word and in Google Docs
- A working table of contents, which needs built-in heading levels
- Dot leaders and right-aligned text on the same line, done properly
- A render-to-image verification pass before you send anything
How to set it up.
Install the document-skills plugin from the anthropics/skills marketplace.
Set US Letter explicitly if you need it. The page size defaults to A4, and Letter is 12240 by 15840 in the unit the library uses, where 1440 equals one inch.
Give tables both sets of widths: column widths on the table and a width on every cell, in the same unit, with the columns summing to the table width.
Set table shading to clear. Solid renders black, which is the most visible way to ruin a deliverable.
Use a numbering configuration for bullets in place of the bullet character itself, and separate paragraphs in place of newline characters.
Use built-in heading levels if you want a table of contents, because custom heading styles need an outline level set or they never appear.
Pricing Plans
Free to use. Source-available license, not open source.
Included in Anthropic's document-skills plugin. Checked against the repo in July 2026.
Use cases
Brief bound for Google Docs
The client opens everything in Google Docs. Build the brief with column widths on the table and a width on every cell, in the same unit, and the layout survives the trip.
Long report with contents page
A report needs a table of contents that works. Use built-in heading levels while drafting, since custom heading styles never appear in the contents without an outline level set.
Editing a client's own file
You were sent a document to revise and its formatting must stay. Edits run through the XML, leaving the creation library out of it, so the file keeps its existing styles.
Looking before sending
The document is finished and nobody has opened it. Convert it to PDF and render the pages as images, then read them, because that pass catches the black table shading a script never sees.
Best for
Client-facing briefs and one-pagers
The Google Docs table rule alone saves the round trip where a client opens your brief and the layout has collapsed.
Long reports with a table of contents
Built-in heading levels are a requirement here, which is what makes the contents page work.
Editing a document you were sent
Editing goes through the XML and not the creation library, so an existing file keeps its formatting.