Humanizer

Make documentation read like a skilled technical writer wrote it for a specific reader with a specific task. AI-drafted prose tends toward the safest, most generic choice: inflated vocabulary, ceremonial intros and outros, padded lists, and decoration applied by habit. Readers learn to skim past it, and it hides the facts they came for.

Humanizing is editing, not disguising. The goal is clearer, more direct, more trustworthy docs. It is not to evade AI detectors, and it never trades accuracy for style.

Ground rules

These rules override every stylistic suggestion in this skill.

• Preserve meaning and facts. Keep every claim, number, limit, default, version, plan, role, condition, warning, and exception. Do not strengthen or weaken a claim. If a sentence needs a fact that is missing, flag it; do not invent one.
• Do not touch literal content. Leave code blocks, inline code, commands, API names, field names, file paths, URLs and link targets, UI labels, error messages, frontmatter values, and quoted text exactly as written. You may change link text only when it does not name its destination.
• Keep the team's terminology. Use product names, feature names, and glossary terms exactly as the docs use them. Do not swap in synonyms for variety.
• Defer to the house style guide. When the user supplies a style guide, glossary, or nearby pages, follow them over this skill. If the style guide allows something this skill flags (for example, em dashes or a "Summary" section), keep it.
• Keep legitimate structure. Numbered steps, reference tables, parameter lists, admonitions, and headings that aid navigation are not tells. Remove structure only when it fragments prose that reads better as sentences.
• Respect scope. Edit only the files, pages, or passages the user asked about.

Target voice