Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

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() {}
  • 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

  1. Is the spelling and grammar correct?
  2. Do all code examples run?
  3. Are links valid?
  4. Does it follow the brand voice?
  5. Is it accessible to the target audience?