release

A research agent for creating a UI design contract for a frontend development phase. UI means the screens and controls people interact with.

In plain words
What is it for?
Use it to inspect requirements, existing design systems, reusable components, and project context before frontend implementation.
Why use it?
It gathers existing design decisions and asks only questions that the project documents have not answered.

Command

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add commands/roocodeinc/roo-code/release
Clone the repo
git clone --depth 1 https://github.com/RooCodeInc/Roo-Code
Per session 9 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 892 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00009 $0.00892
Opus 5 $0.00005 $0.00446
Sonnet 5 $0.00002 $0.00178
Haiku 4.5 $0.00001 $0.00089

Measured yesterday against content hash 9f8168004925, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

release scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

Origin

Copies of this mod

2 near-identical copies found in the catalogue:

  • release — 97% identical, 4 lines differ
  • release — 88% identical, 11 lines differ
.roo/commands/release.md · 46 lines

What it actually says

  1. Identify the SHA corresponding to the most recent release using GitHub CLI: gh release view --json tagName,targetCommitish,publishedAt
  2. Analyze changes since the last release using: gh pr list --state merged --base main --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)'
  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}'
  4. Summarize the changes. If the user did not specify, ask them whether this should be a major, minor, or patch release.
  5. Create a changeset in .changeset/v[version].md instead of directly modifying package.json. The format is:
---
"roo-cline": patch|minor|major
---
[list of changes]
  • Always include contributor attribution and the PR number: use "(PR # by @username)".
  • For PRs that close issues, include both the issue number and the PR number and authors: "- Fix: Description (#123 by @reporter, PR #456 by @contributor)"
  • For PRs without linked issues, include the PR number and author: "- Add support for feature (PR #456 by @contributor)"
  • Provide brief descriptions of each item to explain the change
  • Order the list from most important to least important
  • Example formats:
    • With issue: "- Fix: Resolve memory leak in extension (#456 by @issueReporter, PR #789 by @prAuthor)"
    • Without issue: "- Add support for Gemini 2.5 Pro caching (PR #789 by @contributor)"
  • 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.
  1. If the generate_image tool is available, create a release image at releases/[version]-release.png
    • The image should feature a realistic-looking kangaroo doing something human-like that relates to the main highlight of the release
    • Pass releases/template.png as the reference image for aspect ratio and kangaroo style
    • Add the generated image to .changeset/v[version].md before the list of changes with format: ![X.Y.Z Release - Description](/releases/X.Y.Z-release.png)
  2. If a major or minor release:
    • Ask the user what the three most important areas to highlight are in the 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)
    • Ask the user to confirm that the English version looks good to them before proceeding
    • 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 (The READMEs as well as the translation strings)
  3. Create a new branch for the release preparation: git checkout -b release/v[version]
  4. 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]
  5. 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]
  6. The GitHub Actions workflow will automatically:
    • Create a version bump PR when changesets are merged to main
    • Update the CHANGELOG.md with proper formatting
    • Publish the release when the version bump PR is merged
Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. yesterday First seen · 46 lines · 9 tokens per session scan A 9f8168004925

Subscribe to this mod's changes

release is a command published in the GitHub repository RooCodeInc/Roo-Code (24,320 stars, last pushed 3mo ago), licensed Apache-2.0. It adds 9 tokens to every session and 892 once invoked, about $0.0000 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.