tomevault-io Documentation Style Guide
This guide defines standards for all documentation generated in the project.
Formatting
- Ensure there are no spelling errors. Avoid emojis and decorative Unicode characters (such as →, •, ★, ✓, 🎯, ✅).
- Avoid hyphens or dashes as separators between concepts. Instead of "concept A - concept B", rewrite the sentence.
- Prefer lists and tables over long paragraphs.
- Keep documents concise: specs and ADRs should be 1-2 pages, not novels.
- Never use
#<number>in free text (e.g., "#1 priority", "#3 option"). Azure DevOps automatically converts#<number>into a work item link. Use "first", "third option", or rephrase the sentence.
Language
- Avoid promotional or exaggerated language.
- Do not use contrastive constructions:
- "it's not just X, it's Y"
- "it's not just about..."
- "more than just..."
- "goes beyond..."
- Describe directly what something is, without negating or minimizing alternatives.
- Use active voice and direct sentences.
- Avoid generic framing: if the sentence works in any project without modification, it is not saying anything useful.
- Avoid: rhetorical questions followed by an obvious answer ("The solution? Test everything that matters.")
- Prefer: go straight to the statement with project-specific context.
Diagrams
For diagram design, review, tool selection (Mermaid vs Draw.io), and platform rendering rules, use the diagram-design skill.
Document Structure
- Start with the most important content (conclusion, decision, summary).
- Use consistent hierarchical headings (H1 for title, H2 for main sections).
- Include metadata when relevant (Status, Date, Version).
Source: microsoft/devsquad-copilot — distributed by TomeVault.