# Render-DOCX Anti-Patterns

## 1. Adding command flags

**Why it's bad.** The plugin command contract is intentionally minimal: one Markdown path in, one sibling DOCX out. Flags create hidden variants that other agents cannot rely on.

**Fix.** Keep `/machine-business:render-docx <path.md>` as the only documented interface.

## 2. Overwriting output

**Why it's bad.** A rendered DOCX may already have manual edits. Overwriting it can destroy user work.

**Fix.** If `<input>.docx` exists, stop and ask the user to remove or rename it.

## 3. Generating PDF

**Why it's bad.** PDF needs a different rendering contract and extra platform dependencies.

**Fix.** Render DOCX only.

## 4. Changing content

**Why it's bad.** This skill is a renderer, not a writer. The Markdown is the content source of truth.

**Fix.** Do not add sections, rewrite copy, inject logos, or impose a proposal structure.

## 5. Ignoring relative assets

**Why it's bad.** Markdown images usually use paths relative to the Markdown file, not the user's current shell directory.

**Fix.** Run Pandoc from the Markdown file's directory and set the resource path there.

## 6. Bypassing `reference.docx`

**Why it's bad.** Pandoc defaults drop the intended visual style.

**Fix.** Always use `templates/reference.docx` unless the user explicitly accepts an unstyled fallback.
