This guide defines the writing style for Roo Code documentation. The style is direct, concise, and technical. It avoids marketing language and prioritizes clarity for a developer audience. All output must be in markdown. Before writing or editing documentation, always explore existing documentation to understand established patterns, style, and structure. Use list_files to explore the documentation structure Read similar existing documents to understand the style Follow established patterns rather than imposing new ones MANDATORY: Before making ANY changes to existing documentation files, you MUST complete the redundancy validation workflow. This is NOT optional. You CANNOT proceed with edits until validation is complete You MUST document validation results before making changes Skipping validation steps will result in task rejection Use codebase_search to find ALL mentions of the topic across documentation Search for multiple variations of key terms (e.g., if editing "authentication", also search "auth", "login", "security", "credentials") Read and analyze EVERY discovered location thoroughly Create a validation report listing: - All locations where similar content exists - The current state of each location - Potential conflicts or duplications - Recommendation for how to proceed If similar content exists, you MUST determine: - Is this an update to existing content? (proceed to that location) - Is this a consolidation opportunity? (merge content) - Is this truly new, non-redundant content? (proceed with caution) Check for contradictions with existing documentation Verify that new content aligns with established terminology and concepts Ensure cross-references are accurate and bidirectional where appropriate Validate that the change enhances rather than fragments the documentation flow Document how the change improves overall documentation cohesion You MUST use ask_followup_question to confirm validation results with the user BEFORE proceeding with any edits Start with the most important information. No filler introductions. In this guide, we will explore how to configure the tool. To configure the tool, open... Use short sentences. Cut unnecessary words. If it doesn't add value, remove it. Focus on what the user can do and why it matters. Provide actionable steps. Keep only what changes decisions, prevents mistakes, or unlocks outcomes. Cut narration of obvious UI. Why it matters (value/outcome; 1–3 sentences at the top) Decision points and trade-offs (e.g., Pro vs free, security implications) Non-obvious behavior, caveats, limits, prerequisites Short, actionable steps; error handling and recovery Listing every visible control or tab on a page Describing screenshots (“This page shows…”, “It includes…”) without decisions or implications Explaining basic concepts common to developers Redundant restatement of labels already visible in screenshots When editing a document, use its existing style, structure, and format as a guideline for any updates. Do not make major changes unless explicitly asked. Read the entire document first to understand its current style Identify patterns in headings, formatting, and tone Match the existing style in your edits Bold, honest, human. No fluff, no fake hype. Short, punchy sentences. Speak like a helpful colleague. Expose real value. If it matters, state it clearly; if not, leave it out. Be excited when the feature earns it. Be candid about limits. Don’t use buzzwords, clickbait, or corporate tone. Don’t exaggerate beyond the truth—real impact sells itself. Don’t narrate the screen. Focus on decisions and outcomes. Avoid marketing jargon, buzzwords, and clichés. These words are ambiguous and reduce signal. When editing existing documentation, check if any of these words are already used and maintain consistency with the existing approach. seamlessly comprehensive enhanced streamlined powerful improved intuitive state-of-the-art revolutionary robust easily simply Use structured headings, lists, and short paragraphs for scannability. Provide clear, copy-pasteable code snippets. Assume user familiarity with basic concepts. Do not over-explain.

Explain the outcome and value in 1–3 sentences.

Concrete capabilities and decision points; link to authoritative references instead of duplication.

Minimal steps to success (include only non-obvious choices).

Important limits, access requirements, pricing—only what affects decisions.

Common failure modes and fixes.

Only include screenshots when they clarify a decision, show non-obvious state, or demonstrate outcome. 1 3 No narration of on-screen labels or obvious layout. No screenshot that repeats text already stated without adding decision context. Alt text describes action/outcome, not the UI chrome. Prefer width="800" unless smaller improves readability. Use captions or surrounding text to explain the decision/implication. Follow Docusaurus image rules; see rules in 2_docusaurus_conventions.xml. Before formatting new content, examine existing documentation for: - Heading hierarchy patterns (H1, H2, H3 usage) - List formatting preferences (bullets vs numbers) - Code block styling and language tags - Paragraph length and structure Match the discovered patterns to maintain consistency Have I explored the existing documentation structure? Have I read similar documents to understand the established style? Have I identified the patterns for paths, links, and references? Am I following discovered patterns rather than making assumptions? Have I searched for existing content that might overlap with my changes? Have I verified that my changes don't contradict existing documentation? Have I checked that cross-references will remain valid? This workflow is MANDATORY for ALL documentation changes. Each phase MUST be completed in order. Skipping any phase or step will invalidate the entire change request. Analyze the requested change and its impact You CANNOT proceed to the next phase until ALL steps are complete Identify the scope and purpose of the requested change List ALL key concepts, terms, and their variations (e.g., "config" → "configuration", "setup", "settings") Determine which documents might be affected (use list_files to verify) Document your analysis results before proceeding Search for ALL existing related content - this phase is NOT optional You MUST find and analyze ALL related content before proceeding Use codebase_search with the primary term from the request Use codebase_search with EACH variation of key terms identified in analysis Read ALL potentially related documentation sections in full Create a comprehensive map documenting: - Every location where related information exists - The specific content at each location - How each location relates to the requested change Identify any gaps, overlaps, or contradictions If you find existing content, you MUST read it completely before proceeding Validate the change against existing content - MUST be completed before ANY edits You MUST answer ALL questions and get user confirmation before implementation Does this exact information already exist elsewhere? (If yes, STOP and redirect to existing location) Does similar but incomplete information exist? (If yes, enhance existing rather than duplicate) Will this change create any contradictions with existing docs? Have you verified ALL cross-references will remain valid? Does this enhance the documentation flow or fragment it? Have you identified ALL files that need updates to maintain consistency? You MUST use ask_followup_question to present validation findings and get approval Include specific file paths and line numbers in your validation report Provide clear recommendations based on your findings Apply changes ONLY after validation is approved by user You can ONLY enter this phase after user approves validation results If updating existing content, preserve ALL valuable context If adding new content, ensure it links appropriately to ALL related topics discovered in phase 2 Update ALL affected cross-references in other documents Maintain consistent terminology throughout ALL affected files Verify no information is lost or contradicted by your changes Verify the changes maintain documentation integrity Re-run codebase_search to ensure no duplicates were created Verify all cross-references still work Confirm terminology remains consistent Document what was changed and why for future reference