Documentation Style Guide
Version: 0.1.0
To maintain high quality and consistency across ReasonKit documentation, please adhere to these guidelines.
Voice and Tone
- Authoritative but Accessible: Write with confidence, but avoid jargon where simple words suffice.
- Concise: Get to the point. Avoid fluff.
- Active Voice: “The engine processes data” (Good) vs “Data is processed by the engine” (Bad).
- Objective: Avoid marketing hype (“blazing fast”, “best in class”) unless backed by benchmarks.
Formatting
Headers
Use sentence case for headers.
# Getting started (Bad)
# Getting Started (Good)
Code Blocks
Always specify the language for syntax highlighting.
// Good
fn main() {}
Links
- Use relative links for internal documentation (
[Link](./setup.md)). - Use absolute links for external resources.
Terminology
- ReasonKit (Capitalized, CamelCase).
- ThinkTool (One word, CamelCase).
- LLM (Acronym, uppercase).
- MCP (Acronym, uppercase).
Directory Structure
guide/: Practical, step-by-step instructions.concepts/: Explanations of how things work.api/: Technical references.advanced/: Deep dives and edge cases.
Checklist for Reviewers
- Is the spelling and grammar correct?
- Do all code examples run?
- Are links valid?
- Does it follow the brand voice?
- Is it accessible to the target audience?