release

A release procedure for the Roo Code extension, a browser or editor extension project. It uses merged pull requests and linked issue details to prepare a versioned changeset, which is a file describing the next release and its version impact.

In plain words
What is it for?
Use it to find changes since the last release, summarize pull requests, choose a major, minor, or patch version, and create the required changeset with attribution.
Why use it?
It makes release notes traceable to code changes, contributors, and issue reporters. It also ensures the version change is recorded in the project’s changeset system instead of editing package metadata directly.

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/sfarpak/alifullstack/release
Clone the repo
git clone --depth 1 https://github.com/SFARPak/AliFullStack
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 864 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin 88% copy Near-identical to another mod 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.00864
Opus 5 $0.00005 $0.00432
Sonnet 5 $0.00002 $0.00173
Haiku 4.5 $0.00001 $0.00086

Measured 2d ago against content hash f28b0c16d6af, 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 2d ago.

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

This is a copy

88% identical to release — 11 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.

Roo-Code/.roo/commands/release.md · 45 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 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:
    • With issue: "- Fix: Resolve memory leak in extension (#456 by @issueReporter, PR by @prAuthor)"
    • Without issue: "- Add support for Gemini 2.5 Pro caching (thanks @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. 2d ago First seen · 45 lines · 9 tokens per session scan A f28b0c16d6af

Subscribe to this mod's changes

release is a command published in the GitHub repository SFARPak/AliFullStack (76 stars, last pushed 1mo ago), licensed Apache-2.0. It adds 9 tokens to every session and 864 once invoked, about $0.0000 per session on Opus 5. A static security scan graded it A with 0 findings. It is 88% identical to release, differing in 11 lines, and is treated as a copy.