DeepTutor DOCX Skill
Enables an AI assistant to read, create, and edit Microsoft Word documents — from text extraction to redline tracked changes in one skill.
Purely local document operations in a sandboxed shell with preinstalled python-docx; no network calls, no credential access, defaults to writing new files rather than overwriting ("write a new output unless the user explicitly requested an authorized replacement"), and LibreOffice use is constrained to relative paths with cleanup. Least privilege and data-flow disclosure are good; deducted for: no mandatory explicit-confirmation flow for sensitive replacements/deletions, rollback relies on the user retaining originals, and no source attribution inside the skill file.
Instructions are self-consistent with two tiers (python-docx / raw OOXML), built-in post-save reopen and testzip validation, and explicit treatment of common traps (run splitting, xml:space, pPr order), with clear degradation when soffice is absent; deducted for: static review executed nothing, repository tests do not cover this skill's key paths, and snippets like tracked changes and page-number field injection have no reproduction evidence, with much error handling left to caller attention.
The description clearly scopes to .docx and excludes PDF/xlsx/pptx/Google Docs, giving precise triggers, and the body declares non-fit boundaries and degradation; deducted for: English-only documentation with no Chinese support note; the core assumption of a sandbox with python-docx (and optional LibreOffice) means unavailability in a mismatched environment, with limited environment-fit evidence; behavior on corrupted/encrypted inputs is undeclared.
Well-layered progressive disclosure (default/advanced), stable naming, ample examples and trap notes, clear Apache-2.0 license, and an actively maintained repo with release/CI pipelines; deducted for: the SKILL.md itself has no version/changelog, dependency notes assume a preinstalled environment, and there is no FAQ, known-limits list (e.g., large-document performance), or skill-level maintenance ownership.
Goals (read/create/edit/redline .docx) are clear, example code is high quality and directly adaptable, offering real marginal value over manual work; deducted for: static review cannot verify output correctness, and advanced paths (tracked changes, comments, TOC) are self-described as fiddly and needing manual verification, so direct-usability evidence is limited.
Primary evidence is auditable source and dependency declarations (pyproject confirms python-docx as a runtime dependency, consistent with the skill), plus repo CI and release workflows; deducted for: no committed test coverage of this skill or third-party execution evidence, and consistency between claims and behavior cannot be independently reproduced — a single evidence type.
- Static review only — no code was executed; key paths (tracked changes, page/TOC fields, LibreOffice conversion) were never reproduced.
- The skill assumes a sandbox with preinstalled python-docx and optional LibreOffice; if absent, it relies on runtime degradation messages rather than prior guarantees.
- Advanced raw-OOXML editing is self-described as error-prone; generated files should be opened in Word for manual verification, and overwriting originals requires explicit user authorization (default is a new output file).
- Publisher is unverified (identity unknown); the SKILL.md has no version/changelog of its own — updates track repository releases.
- Documentation is English-only with no Chinese support notes, and the skill is essentially unusable outside its assumed sandbox environment.
What does this skill do, and when should you use it?
This is the docx skill from the DeepTutor repository's built-in office skill collection, working by having the model write and execute Python scripts against Word files. A default tier uses the preinstalled python-docx library for creation, reading, and simple edits; an advanced tier manipulates raw OOXML (the XML parts inside the ZIP) for tracked changes (redlines), comments, and exact-fidelity edits that preserve untouched bytes. The skill is packed with hard-won pitfalls — real list styles instead of typed bullets, xml:space preservation, element ordering rules — and mandates verifying the deliverable reopens cleanly before returning. It handles only .docx, explicitly excluding PDF, .xlsx, .pptx, and Google Docs.
Reads and extracts paragraphs, tables, headers/footers, and styles from .docx; creates reports, letters, and memos with headings, real list styles, tables, images, page-number fields, and clickable TOCs; performs format-preserving find-and-replace; edits margins, page size, headers, and footers; parses and writes w:ins/w:del tracked changes and comments.xml annotations; optionally invokes LibreOffice for .doc-to-.docx conversion and PDF export; and validates every saved file by reopening with Document(), running zipfile.testzip(), and parsing edited XML parts with lxml in the same call.
- Knowledge workers who need recurring reports with headings, tables, and charts generated as real Word deliverables
- Editors reviewing contracts or legal text who need redlines and comments for others to accept or reject
- Operations staff filling template documents by replacing {{CLIENT}}-style placeholders without breaking formatting
- Analysts extracting tabular data and body text from batches of Word files for downstream processing
- Archivists converting legacy .doc files to .docx or exporting PDFs (requires local LibreOffice)
What are this skill's strengths and limitations?
- Pragmatic two-tier design: python-docx for almost everything, raw OOXML only where it's genuinely required
- Encodes real-world pitfalls: placeholders split across runs, w:ins/w:del rules, xml:space, unique w:id requirements, pPr element order
- Mandatory pre-delivery validation (reopen, testzip, lxml parse) reduces silent corruption
- Graceful degradation when LibreOffice is absent; never installs dependencies mid-task
- PDF export and .doc conversion depend on optional, often-absent LibreOffice
- Page-number and TOC fields require manual XML injection; the TOC shows 'Update Field' until refreshed in Word
- Cross-run placeholder replacement collapses formatting to the first run — fine only for plain placeholders
- The raw-OOXML path is fiddly and the skill itself admits output should be verified by opening in Word
- No standalone test suite or cross-platform verification evidence is shown in the source material
How do you install this skill?
The skill ships inside the DeepTutor repository at deeptutor/skills/builtin/docx/SKILL.md — no separate install. DeepTutor itself installs via PyPI (pip install -U deeptutor), from source, Docker (ghcr.io/hkuds/deeptutor:latest), or as a CLI-only package. The exec sandbox the skill requires is active by default in every deployment shape. For .doc conversion or PDF export, LibreOffice (soffice) must be present locally. The source does not document installing this skill outside a DeepTutor environment.
How do you use this skill?
Ask for Word work in a DeepTutor conversation, e.g. 'Generate an updated Q3 report as a docx with a table of metrics' or 'Change 30 days to 60 days in this contract with tracked changes'. The skill requires a shell sandbox; the model writes a complete Python script that creates, saves, reopens, and validates the deliverable in one exec call. Edits write a new output file unless the user explicitly authorizes replacement. If soffice is missing, the skill degrades with a clear note.
How does this skill compare with similar options?
Unlike prompting a model to emit document content, this skill produces real .docx files with tracked changes and comments. It is complementary to DeepTutor's built-in pdf/pptx/xlsx sibling skills, which cover the other office formats this one explicitly excludes.