Platform-agnostic document design intelligence for professional document work. Provides information architecture, typography, style-system, accessibility, and domain-compliance guidance for producing polished documents. Pair with `word-docx-production` or another execution skill for mechanical editing and file generation. Use whenever the task involves document architecture decisions, style system design, heading hierarchy, table or figure design, accessibility review, domain compliance (NIH grants, legal filings, journal manuscripts, SOPs, technical reports), anti-pattern detection, or editorial standards. Do not trigger for python-docx scripting, OOXML manipulation, pandoc conversion, document rendering, or pure prose writing with no document-formatting deliverable.
Professional Word work is not "making text look nicer." It is information architecture, typography, navigation, revision control, accessibility, and domain compliance working as one system. A good document lets a reader predict where things live, skim without getting lost, trust the numbering and references, and print or export without surprises. A bad one may contain the same words but still feel amateur because its hierarchy, spacing, tables, captions, and page logic were improvised instead of designed.
Use this skill to think like a document editor and information architect, not like a toolbar operator. Start by classifying the document's domain, audience, and constraints. Then build the structure, bind content to named styles, handle tables and figures as reading tools, and finish with accessibility and compliance checks. The goal is not decorative formatting. The goal is a document that survives revision, review, conversion to PDF, and reuse by other people.
Load only the reference files needed for the current task. Do not bulk-load the entire library. The root file gives the operating rules; the reference files provide task-specific depth.
| Task | Load |
|---|---|
| Creating any new document from scratch |
references/document-architecture.md + references/style-system-typography.md |
| Formatting or restyling an existing document | references/style-system-typography.md + references/anti-patterns.md |
| Building or formatting tables | references/tables.md + references/style-system-typography.md |
| Inserting or formatting figures/images | references/figures-visual-elements.md |
| NIH grant, manuscript, legal doc, SOP | references/domain-constraints.md + references/document-architecture.md |
| Designing lists or numbering schemes | references/lists-numbering.md |
| Headers, footers, page numbering, print layout | references/headers-footers-layout.md |
| Writing, editing, or proofreading content | references/writing-editorial.md |
| Accessibility audit or compliance check | references/accessibility-compliance.md |
| Reviewing/improving an existing document | references/anti-patterns.md + whatever domain applies |
| Publication-quality document for submission | references/domain-constraints.md + references/figures-visual-elements.md + references/accessibility-compliance.md |
| Creating or customizing a template | references/document-architecture.md (§8) + references/style-system-typography.md |
| Merging or assembling multiple documents | references/document-architecture.md + references/headers-footers-layout.md |
| Converting between formats | references/style-system-typography.md + references/anti-patterns.md |
| Compliance audit (journal, court, sponsor) | references/domain-constraints.md + references/accessibility-compliance.md |
| Repairing a corrupted or inconsistent document | references/anti-patterns.md + references/headers-footers-layout.md |
| Designing a branded template system for a team | references/style-system-typography.md + references/document-architecture.md (§8) |
| Managing tracked changes and review workflow | references/document-architecture.md (§7) + references/anti-patterns.md (§6) |
| Reflowing or repaginating after edits | references/headers-footers-layout.md + references/anti-patterns.md (§2) |
When loading 3 or more reference files, focus on the sections most relevant to the specific task. Read headings and scope statements first, then dive into only the sections that apply.
Run this checklist on every Word task:
FEEDBACK.md for lessons from prior tasks.FEEDBACK.md.This skill provides design decisions and specifications, not executable code. Adapt your output to the interface you are working through:
In all modes, state the reasoning behind your choices so the human can override intelligently when their context differs from the default.
.docx creation, editing, redlining, OOXML inspection, and rendering. Use document-design-mastery's design decisions, then execute with word-docx-production's tools.When both document-design-mastery and a toolchain skill are loaded, document-design-mastery provides the "what and why," the toolchain skill provides the "how."
When improving or reviewing an existing file, prefer the smallest change that solves the problem. Keep the original hierarchy unless it is broken. Preserve tracked-change readability. Do not replace a stable style system with ad hoc local edits. When the source document is clearly corrupted or inconsistent, stop patching symptoms and rebuild the style and section framework in a clean structure.
When a user's aesthetic or structural preference conflicts with a domain compliance rule (e.g., "make this NIH grant look modern with branded colors and decorative headers"), state the conflict explicitly rather than silently choosing one side. Explain what the compliance rule requires and why violating it matters (rejection, accessibility failure, court sanctions), then offer compliant alternatives that address the user's underlying intent. User aesthetic preferences yield to domain compliance. User structural preferences yield to sponsor, court, or journal rules when submission is involved. Everything else defaults to the user's stated intent.
When a document spans multiple domains (e.g., a grant application containing legal subcontracts, or a business report with academic citations), apply the strictest domain's constraints as the floor, then layer additional domain rules where they apply to specific sections. Load all relevant domain references from the routing table. When domain rules conflict, state the conflict explicitly and ask the user which rule set takes priority for the contested element.
Stop when the document is structurally coherent, style-driven, domain-compliant, accessible, and ready for the next human reader without manual cleanup. If anything was surprising or missing during this task, add one entry to FEEDBACK.md before finishing.