# DOCX

Create, edit, inspect, review, and finalize Microsoft Word .docx documents.

- Repository: https://github.com/OpenBMB/PilotDeck (4947 stars)
- Category: Documents
- License: AGPL-3.0
- Last updated: 2026-10-29
- Runs scripts: yes, review before use

## Install

Claude Code: `npx skills add OpenBMB/PilotDeck --skill docx -g -a claude-code -y`
Codex: `npx skills add OpenBMB/PilotDeck --skill docx -g -a codex -y`
Cursor: `npx skills add OpenBMB/PilotDeck --skill docx -g -a cursor -y`
Gemini CLI: `npx skills add OpenBMB/PilotDeck --skill docx -g -a gemini-cli -y`

## Description

Create, edit, inspect, review, and finalize Microsoft Word .docx documents. Use for new Word documents, source- or template-based reports, precise edits that should preserve an existing file, visual or structural review, comments and tracked changes, and final DOCX delivery. Use only for .docx files, not legacy .doc, macro-enabled .docm, or live Microsoft Word control.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# DOCX documents

Use three stages as a reasoning framework, not a fixed tool pipeline:

1. Understand the request and source materials.
2. Build or edit the document using the approach best suited to the task.
3. Review the actual result before delivery.

The user's explicit requirements are the primary acceptance criteria. Adapt the depth of inspection, implementation, and review to the task rather than following a universal checklist.

## Understand

Determine the audience, purpose, authoritative sources, required content, expected form, and what must remain unchanged. Distinguish factual sources from templates and visual references.

- Preserve source files unless replacement is explicitly requested.
- Do not invent unsupported facts, citations, dates, names, figures, or conclusions.
- When editing, preserve content, structure, and formatting the user did not ask to change.
- Inspect only the material relevant to the requested outcome. For complex sources, use direct Python, `python-docx`, ZIP/XML inspection, or the optional `inspect` command as useful.

Resolve the optional CLI once when its evidence or delivery commands help:

```bash
SKILL_ROOT={{SKILL_ROOT_SHELL}}
DOCX="$SKILL_ROOT/scripts/docx.sh"
WORKSPACE="${PILOTDECK_WORK_DIR:?PILOTDECK_WORK_DIR is required}/docx"
mkdir -p "$WORKSPACE/tmp" "$WORKSPACE/review"
```

```bash
bash "$DOCX" inspect --input "$INPUT_DOCX" --summary
bash "$DOCX" inspect --input "$INPUT_DOCX" --search "target phrase"
```

## Build

Write and run task-specific Python directly. Use the complete `python-docx` API, `lxml`, direct OOXML editing, or another suitable library according to the document and requested change. Choose the script structure and implementation route that make the current task simplest and most reliable.

Keep task scripts, candidates, extracted media, reports, renders, and debugging output under `PILOTDECK_WORK_DIR`. Put only the requested final deliverable in the project workspace.

The rest: https://github.com/OpenBMB/PilotDeck/blob/HEAD/skills/docx/SKILL.md