- "customInstructions": "**Release Notes (`docs/update-notes`) Standards:**\n\nWhen creating or updating release notes (`.md` files within the `docs/update-notes` directory), adhere to the following standards:\n\n1. **File Naming:**\n * **Patch Releases:** Use the full version number (e.g., `v3.3.1.md`). These files should detail specific bug fixes or minor changes since the last patch or minor release.\n * **Minor/Major Releases:** Use the major.minor version number (e.g., `v3.11.md`). These files should summarize all changes included in that version cycle, including features, improvements, and bug fixes from all associated patch releases (e.g., `v3.11.0`, `v3.11.1`, `v3.11.2`, etc.).\n2. **File Structure (`vX.Y.Z.md` or `vX.Y.md`):**\n * **Title:** The H1 title must follow the format: `# Roo Code X.Y.Z Release Notes (YYYY-MM-DD)` or `# Roo Code X.Y Release Notes (YYYY-MM-DD)`. Ensure the date reflects the release date and is always included.\n * **Summary Sentence:** Include a brief sentence below the title summarizing the key changes in the release. For minor/major releases, this should cover the scope of the entire version cycle.\n * **Section Headings:** Use consistent `##` headings. Recommended headings include:\n * `## Highlights` (for major features or changes, especially in minor/major releases)\n * `## Bug Fixes`\n * `## Improvements` (can include performance, UX, or other enhancements)\n * `## Provider Updates` (for changes related to specific integrations like Cloud providers)\n * `## Documentation Updates`\n * *(Avoid overly generic terms like \"Changes\" or \"Updates\" as section headers)*\n3. **`index.md` File (Main Index):**\n * The main `index.md` file in the `docs/update-notes` directory should list all release versions chronologically (newest first).\n * Each entry should link to the corresponding release note file (e.g., `v3.11.md` for the summary page, `v3.3.1.md` for a specific patch). Use absolute paths from `/docs/` and omit the `.md` extension (e.g., `[3.11.8](/update-notes/v3.11.8)`).\n * Ensure the date `(YYYY-MM-DD)` is included next to each version link.\n4. **Contributor Acknowledgments:** If acknowledging contributors for specific changes (e.g., bug fixes), do so consistently. Add `(thanks username!)` at the end of the relevant bullet point, omitting the `@` symbol.\n5. **Content Style:** Maintain a clear, concise, and informative writing style. Use Markdown formatting correctly (e.g., use backticks `` for code or version numbers). Ensure consistent terminology (e.g., \"release notes\" vs. \"changelog\").\n6. **Sidebar Update (`sidebars.ts`):**\n * When a new **minor release summary page** (e.g., `vX.Y.md`) is created, you **must** update the `sidebars.ts` file.\n * Add the Docusaurus ID for the new page (e.g., `'update-notes/vX.Y'`) to the `items` array within the 'Update Notes' category.",
0 commit comments