You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
description: "Create a new release of the Roo Code extension"
3
+
argument-hint: patch | minor | major
4
+
---
5
+
6
+
1. Identify the SHA corresponding to the most recent release using GitHub CLI: `gh release view --json tagName,targetCommitish,publishedAt`
7
+
2. Analyze changes since the last release using: `gh pr list --state merged --json number,title,author,url,mergedAt,closingIssuesReferences --limit 1000 -q '[.[] | select(.mergedAt > "TIMESTAMP") | {number, title, author: .author.login, url, mergedAt, issues: .closingIssuesReferences}] | sort_by(.number)'`
8
+
3. For each PR with linked issues, fetch the issue details to get the issue reporter: `gh issue view ISSUE_NUMBER --json number,author -q '{number, reporter: .author.login}'`
9
+
4. Summarize the changes. If the user did not specify, ask them whether this should be a major, minor, or patch release.
10
+
5. Create a changeset in .changeset/v[version].md instead of directly modifying package.json. The format is:
11
+
12
+
```
13
+
---
14
+
"roo-cline": patch|minor|major
15
+
---
16
+
[list of changes]
17
+
```
18
+
19
+
- Always include contributor attribution using format: (thanks @username!)
20
+
- For PRs that close issues, also include the issue number and reporter: "- Fix: Description (#123 by @reporter, PR by @contributor)"
21
+
- For PRs without linked issues, use the standard format: "- Add support for feature (thanks @contributor!)"
22
+
- Provide brief descriptions of each item to explain the change
23
+
- Order the list from most important to least important
24
+
- Example formats:
25
+
- With issue: "- Fix: Resolve memory leak in extension (#456 by @issueReporter, PR by @prAuthor)"
26
+
- Without issue: "- Add support for Gemini 2.5 Pro caching (thanks @contributor!)"
27
+
- CRITICAL: Include EVERY SINGLE PR in the changeset - don't assume you know which ones are important. Count the total PRs to verify completeness and cross-reference the list to ensure nothing is missed.
28
+
29
+
6. If a major or minor release, update the English version relevant announcement files and documentation (webview-ui/src/components/chat/Announcement.tsx, README.md, and the `latestAnnouncementId` in src/core/webview/ClineProvider.ts)
30
+
7. Ask the user to confirm the English version
31
+
8. Use the new_task tool to create a subtask in `translate` mode with detailed instructions of which content needs to be translated into all supported languages
32
+
9. Create a new branch for the release preparation: `git checkout -b release/v[version]`
33
+
10. Commit and push the changeset file and any documentation updates to the repository: `git add . && git commit -m "chore: add changeset for v[version]" && git push origin release/v[version]`
34
+
11. Create a pull request for the release: `gh pr create --title "Release v[version]" --body "Release preparation for v[version]. This PR includes the changeset and any necessary documentation updates." --base main --head release/v[version]`
35
+
12. The GitHub Actions workflow will automatically:
36
+
- Create a version bump PR when changesets are merged to main
37
+
- Update the CHANGELOG.md with proper formatting
38
+
- Publish the release when the version bump PR is merged
Copy file name to clipboardExpand all lines: .roomodes
-36Lines changed: 0 additions & 36 deletions
Original file line number
Diff line number
Diff line change
@@ -41,42 +41,6 @@ customModes:
41
41
- mcp
42
42
customInstructions: Focus on UI refinement, component creation, and adherence to design best-practices. When the user requests a new component, start off by asking them questions one-by-one to ensure the requirements are understood. Always use Tailwind utility classes (instead of direct variable references) for styling components when possible. If editing an existing file, transition explicit style definitions to Tailwind CSS classes when possible. Refer to the Tailwind CSS definitions for utility classes at webview-ui/src/index.css. Always use the latest version of Tailwind CSS (V4), and never create a tailwind.config.js file. Prefer Shadcn components for UI elements instead of VSCode's built-in ones. This project uses i18n for localization, so make sure to use the i18n functions and components for any text that needs to be translated. Do not leave placeholder strings in the markup, as they will be replaced by i18n. Prefer the @roo (/src) and @src (/webview-ui/src) aliases for imports in typescript files. Suggest the user refactor large files (over 1000 lines) if they are encountered, and provide guidance. Suggest the user switch into Translate mode to complete translations when your task is finished.
43
43
source: project
44
-
- slug: release-engineer
45
-
name: 🚀 Release Engineer
46
-
roleDefinition: You are Roo, a release engineer specialized in automating the release process for software projects. You have expertise in version control, changelogs, release notes, creating changesets, and coordinating with translation teams to ensure a smooth release process.
47
-
whenToUse: Automate the release process for software projects.
48
-
description: Automate the release process.
49
-
customInstructions: |-
50
-
When preparing a release:
51
-
1. Identify the SHA corresponding to the most recent release using GitHub CLI: `gh release view --json tagName,targetCommitish,publishedAt`
52
-
2. Analyze changes since the last release using: `gh pr list --state merged --json number,title,author,url,mergedAt,closingIssuesReferences --limit 1000 -q '[.[] | select(.mergedAt > "TIMESTAMP") | {number, title, author: .author.login, url, mergedAt, issues: .closingIssuesReferences}] | sort_by(.number)'`
53
-
3. For each PR with linked issues, fetch the issue details to get the issue reporter: `gh issue view ISSUE_NUMBER --json number,author -q '{number, reporter: .author.login}'`
54
-
4. Summarize the changes and ask the user whether this should be a major, minor, or patch release
55
-
5. Create a changeset in .changeset/v[version].md instead of directly modifying package.json. The format is:
56
-
```
57
-
---
58
-
"roo-cline": patch|minor|major
59
-
---
60
-
[list of changes]
61
-
```
62
-
- Always include contributor attribution using format: (thanks @username!) - For PRs that close issues, also include the issue number and reporter: "- Fix: Description (#123 by @reporter, PR by @contributor)" - For PRs without linked issues, use the standard format: "- Add support for feature (thanks @contributor!)" - Provide brief descriptions of each item to explain the change - Order the list from most important to least important - Example formats:
63
-
- With issue: "- Fix: Resolve memory leak in extension (#456 by @issueReporter, PR by @prAuthor)"
64
-
- Without issue: "- Add support for Gemini 2.5 Pro caching (thanks @contributor!)"
65
-
- CRITICAL: Include EVERY SINGLE PR in the changeset - don't assume you know which ones are important. Count the total PRs to verify completeness and cross-reference the list to ensure nothing is missed.
66
-
6. If a major or minor release, update the English version relevant announcement files and documentation (webview-ui/src/components/chat/Announcement.tsx, README.md, and the `latestAnnouncementId` in src/core/webview/ClineProvider.ts)
67
-
7. Ask the user to confirm the English version
68
-
8. Use the new_task tool to create a subtask in `translate` mode with detailed instructions of which content needs to be translated into all supported languages
69
-
9. Create a new branch for the release preparation: `git checkout -b release/v[version]`
70
-
10. Commit and push the changeset file and any documentation updates to the repository: `git add . && git commit -m "chore: add changeset for v[version]" && git push origin release/v[version]` 11. Create a pull request for the release: `gh pr create --title "Release v[version]" --body "Release preparation for v[version]. This PR includes the changeset and any necessary documentation updates." --base main --head release/v[version]` 12. The GitHub Actions workflow will automatically:
71
-
- Create a version bump PR when changesets are merged to main
72
-
- Update the CHANGELOG.md with proper formatting
73
-
- Publish the release when the version bump PR is merged
74
-
groups:
75
-
- read
76
-
- edit
77
-
- command
78
-
- browser
79
-
source: project
80
44
- slug: translate
81
45
name: 🌐 Translate
82
46
roleDefinition: You are Roo, a linguistic specialist focused on translating and managing localization files. Your responsibility is to help maintain and update translation files for the application, ensuring consistency and accuracy across all language resources.
0 commit comments