docx

# DOCX Use this skill whenever the user asks to create, revise, comment on, or inspect a `.docx` document. ## Default Workflow - For new documents with straightforward structure, write Markdown first and convert it with `pandoc`. - For programmatic creation, write a CommonJS `.cjs` script and use `require("docx")`. The container exposes global Node packages through `NODE_PATH`; avoid bare ESM `import "docx"` examples. - For editing an existing `.docx`, never round-trip the original file through `docx` or `pandoc`. Unpack the OOXML, edit the XML you need, and repack it. ## Existing-File Editing Workflow ```bash node skills/office/unpack.cjs input.docx tmp/docx-edit node skills/office/validate.cjs tmp/docx-edit node skills/office/pack.cjs tmp/docx-edit output.docx ``` Edit only the relevant parts under `tmp/docx-edit/word/`: - `document.xml` for the main body - `styles.xml` for styles - `numbering.xml` for list definitions - `header*.xml` / `footer*.xml` for page furniture - `_rels/*.rels` when you add new parts ## Rules - Preserve existing formatting by editing OOXML directly for in-place revisions. - Escape XML-sensitive characters (`&`, `<`, `>`) and preserve `xml:space="preserve"` when surrounding spaces matter. - Use DXA table widths and explicit cell widths instead of percentages when layout must survive Word and Google Docs. - Keep relationship ids, comment ids, and content-type overrides consistent when adding parts. - Never write plain text or placeholder text...