|
| 1 | +--- |
| 2 | +name: docs-polish |
| 3 | +description: Proofreads a single documentation page and improves clarity, readability, and word choice without changing meaning or reorganizing structure. Simplifies complex sentences, applies style guide standards, and converts passive voice to active voice. Use when the user wants to polish, improve language and clarity, make more readable, check style guide compliance, or clean up documentation while preserving its structure. |
| 4 | +user-invocable: true |
| 5 | +disable-model-invocation: false |
| 6 | +--- |
| 7 | + |
| 8 | +> **Skill progression:** This does everything `/docs-proofread` does plus clarity improvements and style guide enforcement. If only grammar and spelling fixes are needed, use `/docs-proofread`. For deeper reorganization, suggest `/docs-enhance`. |
| 9 | +
|
| 10 | +Improve clarity and readability without changing meaning, structure, or paragraph order: |
| 11 | + |
| 12 | +**docs-polish should**: |
| 13 | +* Read Mendix style guides first (in parallel): `grammar-formatting.md`, `terminology.md`, and `product-naming-guide.md` from `/content/en/docs/community-tools/contribute-to-mendix-docs/style-guide/` |
| 14 | +* Fix all spelling, grammar, and punctuation errors |
| 15 | +* Add missing alt text to images (use simple, factual descriptions) |
| 16 | +* Ensure required front matter fields are present (title, url, description) and make descriptions concise and action-oriented |
| 17 | +* Fix broken Markdown syntax |
| 18 | +* Fix capitalization and terminology inconsistencies |
| 19 | +* Break up long, complex sentences for better readability |
| 20 | +* Simplify wordy or awkward phrasing |
| 21 | +* Improve word choice (more precise or accessible terms) |
| 22 | +* Change passive voice to active voice where appropriate |
| 23 | +* Remove bold and italics used for emphasis (reword or use alerts if needed) |
| 24 | +* Apply Mendix style guide standards (overrides the Microsoft Writing Style Guide) |
| 25 | +* Apply Microsoft Writing Style Guide standards, unless they conflict with the Mendix style guide standards |
| 26 | + |
| 27 | +**docs-polish should NOT**: |
| 28 | +* Move paragraphs or restructure sections (that's `/docs-enhance`) |
| 29 | +* Change technical meaning or accuracy |
| 30 | +* Significantly increase document length |
| 31 | +* Change command syntax, code identifiers, variable names, placeholders, or any other text that appears in code formatting (inline backticks or code blocks). Code-formatted text represents literal technical content that must remain unchanged. If you notice an issue with code-formatted text, flag it in the chat but don't edit it directly. |
| 32 | + |
| 33 | +Every edit should serve a clear purpose in making the text easier to read, scan, and understand. |
| 34 | + |
| 35 | +Priority order for determining scope: |
| 36 | +1. If the user has selected text in a file (check for `ide_selection` tags), only polish the selected text in that file. Don't polish the entire document. |
| 37 | +2. If there's one open file (check for `ide_opened_file` tags) and no selection, work on the entire file. |
| 38 | +3. If there are multiple open files, list them and ask which to process. |
| 39 | +4. If no files are open, ask for a file path. |
0 commit comments