/doc-voiceDocs that read like marketing copy or dry internal prose get rewritten — problem-first, proof-led, no fluff. Governs how the prose reads; structure is /documentation-standard's job.
The reader is a developer deciding whether to install, try, or trust a tool. They are skeptical, fast-scanning, and one tab-close away from leaving. Use /doc-voice when writing or revising any user-facing prose meant to convince that reader.
Trigger phrases (from SKILL.md):
"improve this README""rewrite the docs""make this clearer""remove the marketing fluff""landing copy""user manual""write a handout"Not for: code comments, commit messages, ADRs, or internal specs — those have different voice constraints.
Invoke directly, then paste the copy to rewrite or describe what to write:
/doc-voice [paste existing copy or describe what to write]The skill rewrites or drafts in one pass. For a deeper adversarial check of the result, follow up with /da-review.
Input:
/doc-voice
Supercharge your workflow with our powerful AI-driven code review tool!
Seamlessly integrates into your development process and effortlessly
catches bugs before they reach production.Output / Result:
Code review that finds real bugs — not style preferences.
One command, seven check groups, 132 named checks, more than half automated.
Runs on local changes, a git range, or specific files.Input:
Write a feature bullet for /plan-maker that doesn't sound like marketing.Output / Result:
- **/plan-maker** — Stop staring at a ticket wondering where to start.
Breaks a feature brief into the smallest tasks with tests and
dependencies — ready for /implement to chew through./doc-voice to fix how it reads./doc-voice to catch claims that don't hold up.