DOCX Document Processing

Problem

Many .docx tasks go beyond plain text: creating formatted Word files, editing someone else’s document, preserving tracked changes, extracting comments/media/metadata, and visually checking pages all require separate XML, Pandoc, PDF, and OOXML handling. A common difficulty is that .docx files are ZIP archives of XML, so naive text replacement can corrupt runs, paragraphs, comments, revisions, and styles.

How it works

The skill routes each job and emphasizes reading the full reference docs before choosing a toolchain:

• Read and analyze: convert with pandoc to Markdown; for comments, media, and metadata, unpack and inspect word/document.xml, word/comments.xml, and word/media/.
• Create documents: use docx-js components such as Document, Paragraph, and TextRun, then export via Packer.toBuffer().
• Edit documents: unpack OOXML, modify the DOM with the Python Document library, then repack into .docx.
• Redlining review: convert to Markdown with tracked changes, group 3-10 edits, locate XML nodes precisely, mark only changed text, preserve unchanged run RSID, pack, and verify.
• Visual checks: convert DOCX to PDF with LibreOffice, then render pages to page-*.jpg with pdftoppm.

Boundaries

Best for engineers who need precise Word XML control, not just simple text replacement. Markdown is enough for plain-text extraction, but legal documents with comments, revisions, and styles must be checked at the OOXML level. For third-party, legal, academic, business, or government documents, the material mandates a redlining workflow; generated code should stay concise, avoiding redundant variables and prints.