Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Acknowledgement: Shared by Peter Bamuhigire, techguypeter.com, +256 784 464178.
Required Inputs
Input
Required
Use
Decision, audience, and deliverable
yes
Bound the business outcome
Source evidence, constraints, and owner
yes
Ground recommendations and accountability
Approved budget, customer data, or production artefacts
conditional
Support high-impact execution
Capability and permission contract
Default to read-only analysis and drafting. Do not publish, send, price, promise, alter customer records, commit budget, or modify production artefacts without explicit authority and a named approver. Minimise confidential data, preserve provenance, and keep reversible copies.
Degraded mode
If evidence, stakeholder decisions, specialist tooling, or authoritative commercial data are unavailable, deliver a labelled draft, checklist, or decision memo. State what was not verified and do not claim approval, publication, financial accuracy, or customer acceptance.
Decision rules
Condition
Action
Stop condition
Output creates a commercial, customer, or delivery commitment
Obtain named approval before release
Authority or terms are unclear
Evidence supports a reversible draft
Produce it with assumptions and owner
Required evidence conflicts
Tooling or data is incomplete
Specify validation
A final executable artefact is expected
Domain Anti-Patterns
Inventing customer evidence, prices, benchmarks, or approvals. Fix: cite the source or mark the gap.
Publishing or sending a draft without authority. Fix: retain draft status and name the approver.
Hiding assumptions inside polished prose. Fix: expose them beside each affected decision.
Polishing presentation while the decision remains unclear. Fix: resolve audience, owner, and acceptance criteria.
Treating unavailable tooling as passed validation. Fix: record the unassessed check.
Use When
Generate world-class, professionally designed Microsoft Word (.docx) documents that look like a designer and communications specialist worked on them together — not AI output. Use when producing any .docx file: reports, proposals, manuals...
Evidence Produced
Category
Artifact
Format
Example
Release evidence
Generated Word document
Branded .docx artefact compliant with the professional-word-output design standard
docs/output/report-2026-04-16.docx
References
English output standard for human-facing prose, collocation, register, terminology, and proof.
Use the references/ directory for deep detail after reading the core workflow below.
Two things kill document quality equally: bad design and bad writing. A document must pass both tests. This skill addresses both.
references/quality-checklist.md — pre-delivery checklist (run before every delivery)
The Standard
Every document produced must pass this bar: a professional communications specialist and a document designer would both be satisfied. This means:
Every typographic decision is intentional and consistent
The writing is clear, structured, and free of AI-slop vocabulary
Navigation elements (TOC, headers/footers, page numbers) are complete and correct
Visual hierarchy guides the reader without effort
The document looks the same on any machine (styles, not direct formatting)
Production Pipeline
Documents are produced via Pandoc + python-docx + reference.docx template:
Markdown source (structured content)
↓ pandoc --reference-doc=templates/reference.docx
.docx (styles applied from reference.docx)
↓ manual python-docx post-processing (cover page, TOC, header/footer)
Final .docx → PDF export
Before using LibreOffice for a background PDF export or render, load document-spreadsheet-tooling-readiness and follow its isolated-profile, cross-platform conversion contract. Do not construct a raw soffice command or reuse the interactive user's LibreOffice profile.
Project export contract
Every project that generates .docx deliverables must include these project-root paths:
projects/<ProjectName>/export/
projects/<ProjectName>/export-docs.ps1
projects/<ProjectName>/export-docs.sh
Build .docx files in their canonical phase folders first. Then run the project export script so export/ contains a flat copy of every generated Word deliverable, excluding files already inside export/.
Build commands
# Single document
pandoc source.md -o output.docx --reference-doc=templates/reference.docx
# With table of contents
pandoc source.md -o output.docx --reference-doc=templates/reference.docx --toc --toc-depth=3
# Rebuild reference.docx from scratch
python scripts/create-reference-docx.py
Style System
Pandoc maps Markdown elements to named Word styles in reference.docx. Never bypass this with direct formatting.
Markdown element
Word style
# Heading
Heading 1
## Heading
Heading 2
### Heading
Heading 3
#### Heading
Heading 4
Body paragraph
Normal
```code block```
Source Code / Verbatim
`inline code`
Verbatim Char
> blockquote
Block Text
Table
Table Grid
YAML title:
Title
YAML subtitle:
Subtitle
*Caption* below figure/table
Caption
If a style needs to change, change it in reference.docx — never in the document directly.
Heading Flow & Page Break Rules
These rules are mandatory. They determine how the document breathes across pages and whether the reader can follow the structure without effort.
Rule 1 — Heading 1 always starts a new page
Every # Heading 1 forces a page break before it. Major sections never share a page with the section that precedes them. This makes the document scannable: readers flipping through pages immediately see where each chapter/section begins.
Word setting: Paragraph → Line and Page Breaks → Page break before = ON
python-docx:
from docx.oxml.ns import qn
from docx.oxml import OxmlElement
h1 = doc.styles['Heading 1']
h1.paragraph_format.page_break_before = True
h1.paragraph_format.keep_with_next = True# heading never orphaned alone
Rule 2 — Heading 2 and Heading 3 stay with their first paragraph
If the heading plus its first following paragraph do not entirely fit on the current page, the whole unit moves to the next page. A heading that appears at the bottom of a page with its content on the next page is a design failure.
Word settings on Heading 2 and Heading 3:
Paragraph → Line and Page Breaks → Keep with next = ON
Paragraph → Line and Page Breaks → Keep lines together = ON
Word setting on Normal / body paragraphs:
Paragraph → Line and Page Breaks → Keep lines together = ON
This combination means: the heading is glued to the paragraph that follows it, and that paragraph will not be split across pages. If the pair doesn't fit, both move to the next page.
python-docx:
for style_name in ['Heading 2', 'Heading 3']:
style = doc.styles[style_name]
style.paragraph_format.keep_with_next = True
style.paragraph_format.keep_together = True# Body paragraphs: never split mid-paragraph
doc.styles['Normal'].paragraph_format.keep_together = True
Rule 3 — Widow and orphan control is always on
No paragraph's first line appears alone at the bottom of a page (orphan), and no paragraph's last line appears alone at the top of a page (widow).
Word setting: Paragraph → Line and Page Breaks → Widow/Orphan control = ON (this is the Word default but must be confirmed in reference.docx).
File → Print → verify print preview (no widows, no blank pages)
Export PDF with accessibility tags enabled
Name file: ProjectName_DocumentType_v1.0_YYYY-MM-DD.docx
When the PDF was produced by LibreOffice, retain the readiness result and conversion diagnostics with the delivery evidence, then inspect the rendered output rather than assuming the DOCX layout survived export.
Customisation Reference
To change global document styling, edit scripts/create-reference-docx.py:
Release only after semantic structure, fields, tables, headers, pagination, accessibility, and final rendered pages have been inspected in the target format.
Outputs
Artefact
Consumer
Acceptance condition
Render-verified DOCX and validation note
Named document recipient
Styles are semantic, pagination and tables survive rendering, accessibility properties are present, and no placeholder or hidden revision ships
