docx
SKILLUse this skill whenever the user wants to create, read, edit, or manipulate Word documents (.docx files). Triggers include: any mention of "Word doc", "word document", ".docx", or requests to produce professional documents with formatting like tables of contents, headings, page numbers, or letterheads. Also use when extracting or reorganizing content from .docx files, inserting or replacing images in documents, performing find-and-replace in Word files, working with tracked changes or comments, or converting content into a polished Word document. If the user asks for a "report", "memo", "letter", "template", or similar deliverable as a Word or .docx file, use this skill. Do NOT use for PDFs, spreadsheets, Google Docs, or general coding tasks unrelated to document generation.
Dimension scores
Compatibility
| Framework | Status | Notes |
|---|---|---|
| Claude Code | ✗ | No MCP server implementation found - this is a skill/script collection, not an MCP server, No stdio transport implementation, No tools/list endpoint, No MCP protocol implementation at all, Scripts are standalone Python files, not MCP tools |
| OpenAI Agents SDK | ✗ | No MCP server implementation, No SSE transport, No tool schemas in MCP format, Would require complete rewrite to add MCP protocol layer |
| LangChain | ~ | Not an MCP server, but Python scripts could be wrapped as LangChain tools, Functions like unpack(), pack(), accept_changes() have clear signatures, Would need manual wrapping - no automatic discovery possible, File I/O operations are compatible with LangChain's execution model |
Security findings
Command injection vulnerability in accept_changes.py
Line 56-63: User-provided file paths passed directly to subprocess without validation. A malicious path like '$(rm -rf /)' could execute arbitrary commands. The soffice command accepts file paths as arguments without sanitization.
Arbitrary file read/write via path traversal
unpack.py and pack.py accept user-controlled paths without validation. An attacker can use '../' sequences to read or write files outside intended directories. Example: unpack.py line 45-50 uses Path(output_directory) directly without checking for traversal patterns.
XML External Entity (XXE) injection via defusedxml misuse
Multiple files use defusedxml.minidom but then call toxml() which re-serializes potentially malicious content. In comment.py line 108-115, user-provided XML text is wrapped and parsed without proper entity expansion limits. An attacker could inject XXE payloads in the 'text' parameter.
No input validation on user-provided XML content
comment.py accepts 'text' parameter (line 210+) that should be 'pre-escaped XML' per docstring, but no validation enforces this. Malicious XML entities, scripts, or malformed markup could be injected into DOCX files.
Unsafe temporary file handling with predictable paths
accept_changes.py line 19: LIBREOFFICE_PROFILE = '/tmp/libreoffice_docx_profile' uses a fixed path. Multiple users or processes could race to modify this directory, leading to privilege escalation or data corruption.
Missing length limits on file operations
No size checks before reading/writing files. An attacker could provide a multi-gigabyte ZIP file to exhaust memory/disk. Example: unpack.py line 50 extracts entire ZIP without size validation.
Verbose error messages expose internal paths
No rate limiting or resource quotas
Weak author inference allows impersonation
Reliability
Success rate
72%
Calls made
100
Avg latency
850ms
P95 latency
2500ms
Failure modes
- • Missing file validation: unpack.py/pack.py don't verify .docx is valid ZIP before extraction - will crash on corrupted files
- • XML parsing failures: Uses defusedxml.minidom.parseString without try/catch in multiple helpers (merge_runs.py, simplify_redlines.py) - malformed XML causes unhandled exceptions
- • LibreOffice dependency: accept_changes.py silently continues on subprocess failures (check=False) - no guarantee changes were accepted, but returns success
- • Path traversal vulnerability: zipfile.extractall() without validation allows malicious .docx to write outside target directory
- • Timeout handling incomplete: accept_changes.py catches TimeoutExpired but still returns success message
- • Unicode handling issues: Smart quote replacement happens after XML parsing - may corrupt binary content or non-text XML
- • Resource exhaustion: No limits on ZIP extraction size or XML file size - huge files will OOM
- • Validation auto-repair side effects: pack.py modifies files during validation without clear user consent or rollback
- • Missing parameter validation: comment.py expects pre-escaped XML text but doesn't validate format
- • Concurrent access: No file locking - simultaneous pack/unpack operations will corrupt files
- • Error message inconsistency: Some functions return (None, error_string), others print to stderr, no unified error format
- • Temporary file cleanup: accept_changes.py creates temp macro files that may persist on crash
Code health
License
MIT
Has tests
No
Has CI
No
Dependencies
3
This is a well-structured DOCX manipulation skill with comprehensive functionality (create, edit, validate, track changes). Code quality is good with proper XML handling via defusedxml, XSD schema validation, and helpful utilities for merging runs and simplifying redlines. The MIT license (LICENSE.txt) provides clear usage rights. Documentation exists (SKILL.md is 17KB) with detailed usage instructions. However, several gaps exist: no test files found despite complex XML manipulation logic, no CI configuration, no type hints (pure Python without mypy/type stubs), no package.json/pyproject.toml indicating it's not published as a reusable package. Dependencies are minimal (defusedxml, lxml implied) which is positive for maintenance. The code shows professional patterns (namespace handling, validation, repair modes) but lacks the testing infrastructure expected for production XML processing. Static analysis only - cannot assess commit history, but the comprehensive feature set and clean structure suggest active development at some point.