betterdoclisted

# BetterDoc BetterDoc improves documentation without weakening truth. Use this skill when drafting, editing, reviewing, or restructuring technical/product documentation. It is intentionally common-use: it does not assume a specific repository, product, maturity level, architecture, brand, or governance model. ## Core Rule Do not trade correctness for smoothness. A better document is: 1. true, 2. useful to the intended reader, 3. scoped to what the source supports, 4. easy to follow, 5. clear and concise. Clean prose is not enough. A polished unsupported claim is worse than a rough accurate sentence. ## Non-Goals BetterDoc is not: - a branding authority, - a product-renaming authority, - a production-readiness authority, - a compliance-certification authority, - a roadmap generator, - a hype generator, - a license selector, - a generic anti-AI-style cleaner. Do not add claims, maturity status, security guarantees, customer proof, compliance language, license terms, roadmap commitments, or product names unless the source supports them or the user explicitly provides them. ## Priority Order When rules conflict, use this order: 1. User's explicit instruction. 2. Source material and repository facts. 3. Safety, security, legal, and compliance accuracy. 4. Document type and reader task. 5. Project-specific style or terminology, when present in the source. 6. Claim preservation and evidence scope. 7. Information architecture and usability. 8. Plain, concise prose. 9. A