Create complete, source-grounded professional documents from existing materials, outlines, or templates, then generate, edit, review, or redline the final .d...
Use this skill in two layers:
.docx deliverable.Keep Markdown or plain text as the working source of truth until the wording and structure are stable. Move into DOCX creation, formatting, tracked changes, or comments only after the content is sufficiently mature.
This skill vendors the DOCX capability locally. Do not assume a separate $docx skill is installed.
Some upload targets reject bundled OOXML schema files such as .xsd. When preparing a publishable package, use the packaged upload-safe variant from this skill. That variant keeps document generation and editing workflows, but omits the strict schema-validation bundle.
When the final deliverable is a Word document, always determine the format authority before finalization:
Use the source-grounded text workflow:
Use the DOCX workflows in this skill:
.docx content with pandoc when text extraction is enough..docx from scratch only after fully reading docx-js.md..docx files only after fully reading ooxml.md.Split the work into phases:
.docx generation or .docx editing.Do not mix heavy content generation and low-level OOXML editing in the same pass unless the task is trivial.
Confirm these four inputs before drafting:
If any input is missing, infer the minimum safe default and state the assumption in the working notes, not in the final deliverable.
If the output contract includes .docx, also determine the format authority early. Read references/word-format-profile.md and use scripts/init_format_profile.py when a format profile needs to be captured or confirmed.
If the task is to produce a formal, complete Word deliverable, capture a delivery brief before drafting. Read references/word-delivery-brief.md and use scripts/init_delivery_brief.py to record what the user must specify and what still needs confirmation.
Before writing, create a manifest of the available materials. Read references/source-manifest.md when the corpus has more than a few files.
Use scripts/build_manifest.py to generate a first-pass inventory. Then enrich or trim it manually as needed.
The manifest should separate:
Do not draft directly from a large corpus into the final chapters. First create a section brief for each target section.
Read references/section-briefs.md when building the planning layer. Use scripts/plan_sections.py to bootstrap the outline into brief stubs.
Each section brief should contain at least:
For large projects, section briefs are the shared contract between multiple agents.
Read references/drafting-rules.md before drafting.
Draft against the section brief, not against the whole corpus. This keeps the writing grounded and reduces repetition.
Rules:
Read references/consistency-review.md before merging the full document.
Run a full-pass review for:
Use scripts/assemble_markdown.py to merge ordered chapter files into a single Markdown draft when needed.
Keep a clear distinction between:
Default to a single agent when:
Use multiple agents only when:
In multi-agent mode, create these shared artifacts before splitting work:
Do not let agents improvise different naming systems, evidence rules, or section boundaries.
.docxIf only the text is needed, convert the file with:
pandoc --track-changes=all path-to-file.docx -o output.md
If structure, comments, media, or tracked changes matter, unpack the OOXML package and inspect the XML.
.docxBefore writing any code, fully read docx-js.md without truncation.
Use the bundled docx JavaScript workflow when:
Before final DOCX generation, lock the format profile. If no authoritative template exists, use the default profile in references/word-format-profile.md.
Before final DOCX generation, also resolve the delivery brief items that affect document completeness, review mode, and output packaging.
Before final DOCX generation, run scripts/resolve_word_job.py or follow references/word-assembly-plan.md to determine whether the Word job is actually ready for delivery, which package components will be generated, and which blockers remain.
When the job is ready, generate the file with scripts/generate_docx_from_markdown.cjs. Feed it the merged Markdown body, the delivery brief JSON, and the format profile JSON.
.docxBefore editing, fully read ooxml.md without truncation.
Use the bundled OOXML workflow when:
Default to tracked changes or comments when editing:
Use the bundled local resources in this skill:
If the upload-safe package excluded the OOXML .xsd schema set, treat strict schema validation as unavailable and continue with unpack, edit, and repack workflows only.
Do not ask the user to confirm formatting too early if the task is still in the text-drafting phase. Draft the content first unless formatting decisions would change the structure materially.
Ask the user to confirm the format before final Word delivery when any of these are true:
Do not ask for confirmation when:
.docx to match.When confirmation is needed, present the resolved format profile, not an open-ended question. Default to the profile in references/word-format-profile.md if the user does not override it.
For a complete Word deliverable, separate user inputs into two buckets.
The user must specify these before drafting:
.docxThe user must confirm these before final Word delivery:
If these items are unclear, proceed with text drafting only when safe defaults will not invalidate the content. Do not finalize the Word deliverable until the unresolved delivery-brief items are closed.
Treat final Word generation as a gated assembly step, not just a file export.
Before assembly, resolve:
If the job is not ready, stop at Markdown or internal DOCX draft output and surface the blockers explicitly.
.docx from Markdown, the delivery brief, and the format profile..docx files.ZIP package — ready to use