Formatting, content standards, and PR analysis patterns for release notes. Ensures consistent, user-focused documentation in docs/update-notes. vX.Y.Z.mdx v3.20.3.mdx vX.Y.mdx v3.20.mdx Summarizes a release cycle # Roo Code X.Y.Z Release Notes (YYYY-MM-DD) - Include version number - Include release date in ISO 8601 format - Date from GitHub tag OR current date if PR list provided Below title This release adds context condensing, improves performance, and fixes UI bugs. What changed? (Identify core feature) Why did it change? (Problem solved) How does this impact users? (Concrete benefits) New functionality changing user experience Own ## heading with expanded description UI/UX enhancements, workflow optimizations Under ## QOL Improvements MUST come before Bug Fixes section Resolves issues, fixes errors Under ## Bug Fixes as bullet points MUST come after QOL Improvements section API provider changes Under ## Provider Updates Completely new feature requiring new page Existing documentation needs updating New examples or use cases to add Migration guide needed for breaking changes Major features with details **📚 Documentation**: See [Feature Guide](/path/to/feature) for detailed usage. ]]> Smaller fixes and improvements (thanks username!) (thanks author, reporter!) - Omit @ from GitHub usernames - Place inside parentheses before PR link - Include both PR author and issue reporter - List PR author first - If PR author equals issue reporter, use a single username once - Do not thank these names: outlined in the special instructions section `Release Notes "thank you" exclusions` ([#PR_NUMBER](https://github.com/RooCodeInc/Roo-Code/pull/PR_NUMBER)) In intro paragraph or bullet points At end of each bullet point 1. Major feature sections (each with own heading) 2. ## QOL Improvements 3. ## Bug Fixes 4. ## Misc Improvements 5. ## Provider Updates 6. ## Documentation Updates QOL Improvements MUST always come before Bug Fixes docs/update-notes/index.md [X.Y.Z](/update-notes/vX.Y.Z) (YYYY-MM-DD) - List chronologically, newest first - Use absolute paths from site root (no /docs prefix) - Omit .md extension - Include release date in ISO 8601 format sidebars.ts 'update-notes/vX.Y.Z' - Add to "Update Notes" category - Use Docusaurus ID format - Maintain chronological order Integrate patch releases into parent minor/major file - Add changes to corresponding existing sections - Maintain consistent formatting and section order - Append new items to end of respective sections - Consolidate duplicate fixes across patches - Update summary sentence if significant features added User benefits, not implementation details Present tense ("adds" not "added") RefactoredImproved ImplementedAdded Optimized algorithmMade faster Fixed race conditionFixed timing issue [Feature Name](/path/to/feature) **📚 Documentation**: See [Feature Guide](/path) for detailed usage instructions. ]]> **🔄 Migration Guide**: If upgrading from v[OLD], see our [migration guide](/migration/vX-to-vY). ]]> - Modes: /features/modes/[mode-slug] - Tools: /advanced-usage/available-tools#[tool-name] - MCP: /features/mcp/ - Providers: /providers/ - Use absolute paths starting from root (without /docs prefix) - No .md extensions in links - All major features must have documentation links - "Summary" or "Highlights" sections in docs/update-notes (Discord announcements may use "Feature Highlights") - Version numbers in docs outside update-notes - Temporal references like "as of version X.Y.Z" - Marketing language or buzzwords - Generic headings like "## Changes" or "## Updates" Special formatting rules for Discord announcements to ensure readability and engagement in chat format. ```markdown ... ``` Entire announcement wrapped in markdown code block # 🚀 Roo Code X.Y.Z Release Notes # 🚀 Roo Code X.Y.Z-X.Y.Z Release Updates - Always include rocket emoji - Use "Release Notes" for single version - Use "Release Updates" for combined versions We've shipped [updates/an update] with [feature summary]! - Must summarize key features - No marketing language ("powerful", "revolutionary") - Be specific about what's included We've shipped an update with subtask todo lists, Vertex AI grounding, and performance improvements! We've shipped three updates with subtask todo lists, Vertex AI grounding features, Kimi K2 prompt caching, and the new Featherless provider! 1. ## ✨ Feature Highlights (not "Major Features") 2. ## 🎯 Provider Updates 3. ## 💪 QOL Improvements 4. ## 🐛 Bug Fixes 5. ## 🔧 Additional Improvements - Use emojis for section headers - "Feature Highlights" instead of "Major Features" - Keep descriptions concise for chat readability When user requests compression or content is too long User says "compress" or "condense" - Replace all sections below "Feature Highlights" with single paragraph - Count actual number of improvements (not estimate) - List specific contributor names from the releases - Use "Other Improvements and Fixes" as section title - Include all contributor acknowledgments in one place 📚 **Full Release Notes** [vX.Y.Z](https://docs.roocode.com/update-notes/vX.Y.Z) 📚 **Full Release Notes** [vX.Y.Z](link) | [vX.Y.Z](link) | [vX.Y.Z](link) - Use book emoji - Bold "Full Release Notes" - Markdown link format with version as link text - Pipe separator for multiple versions No version numbers in body text (only header/footer) Never use the word "powerful" or similar marketing terms Remove all PR numbers and links Keep contributor thanks but remove PR references No closing phrases like "Happy coding!" Use bullet points (•) instead of asterisks (*) Group minor items if over 2000 characters ([#PR](link)) (remove entirely) /path/to/feature https://docs.roocode.com/path/to/feature ## Major Features ## ✨ Feature Highlights * • Happy coding! 🦘 (remove entirely)