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:

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 "$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.