Apply professional documentation standards. Use when writing README files, commit messages, code comments, technical docs, or any user-facing text. Enforces evidence-based claims, no marketing language.
Technical documentation must be factually accurate, conservative in claims, and free of marketing language.
No emojis. No checkmarks, party poppers, or unicode decorations. Use plain text: "Compliant", "Implemented", "Supported", "Pending".
No excessive formatting. Use bold sparingly for genuine emphasis only.
| Bad | Good |
|---|---|
| "Highly accurate" | "Median error: 1.4 arcseconds across 7 bodies" |
| "Fast performance" | "Typical response time: 25-75ms" |
| "Well-tested" | "33 unit tests, 6 test suites, 100% pass rate" |
| "Production-ready" | "Deployed in [context]; further testing recommended for [other contexts]" |
| Bad | Good |
|---|---|
| "Low latency" | "< 100ms typical, < 500ms worst case" |
| "High precision" | "1.4 arcsec median, 8.6 arcsec maximum" |
| "Comprehensive coverage" | "87% line coverage, 92% branch coverage" |
Always include a limitations section stating what the software does NOT do.
When describing validation: state comparison target, methodology, dataset, and link to reproducible tests.
No emojis. Use conventional commits format: