release

A command workflow for preparing a new release of the Zoo Code extension. A release is a published version of software containing selected changes since the previous stable version.

In plain words
What is it for?
Use it to inspect the latest stable release, review merged work, choose a major, minor, or patch release when needed, and update release information.
Why use it?
It gathers merged pull requests and linked issue reporters, summarizes the changes, and applies the project's separate numbering rules for stable and nightly versions.

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/zoo-code-org/zoo-code/release
Clone the repo
git clone --depth 1 https://github.com/Zoo-Code-Org/Zoo-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 1,540 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.01540
Opus 5 $0.00005 $0.00770
Sonnet 5 $0.00002 $0.00308
Haiku 4.5 $0.00001 $0.00154

Measured yesterday against content hash fef562b2b04e, 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.

.roo/commands/release.md · 113 lines

How it starts

The opening of the file, as written. The whole thing — 113 lines — stays where its author put it; the contents beside it link to each section on GitHub.

  1. Identify the most recent stable extension release:

    gh release view --json tagName,targetCommitish,publishedAt
    
  2. Analyze changes since that release:

    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 reporter:

    gh issue view ISSUE_NUMBER --json number,author -q '{number, reporter: .author.login}'
    
  4. Summarize the changes. If the user did not specify a release type, ask whether this should be a major, minor, or patch release.

    • Before choosing the target release version, treat the nightly pre-release lane as separate from the stable lane.
    • Zoo Code nightlies should stay on major.ODD_NUMBER.patch and use a large patch number for CI-generated pre-releases.
    • Stable releases should stay on major.EVEN_NUMBER.patch.
    • When preparing a stable release after an odd-minor pre-release line, advance to the next even minor instead of reusing the odd-minor pre-release lane.
  5. Review and update the Marketplace-facing root README.md.

    • Treat root README.md as the source of truth for Marketplace content.
    • Update the "What's New" section for the release when appropriate.
    • Do not manually edit src/README.md; the extension bundle step copies root README.md into src/README.md.
    • Check for stale upstream Roo Code wording that should now say Zoo Code.
  6. Write the release notes directly into CHANGELOG.md on the release branch.

    • Use the heading format ## [version] (with square brackets) — e.g. ## [3.58.1]. The publish workflow at .github/workflows/marketplace-publish.yml extracts release notes by matching this exact pattern; headings without brackets will be missed and the GitHub release will fall back to a generic message.
    • Always include contributor attribution and the PR number: use (PR #<prNumber> by @username).
    • For PRs that close issues, include both issue and PR 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.
    • Include every PR in the release window. Count the PRs and cross-reference the list before continuing.
  7. For a major or minor release:

    • Ask the user what three areas should be highlighted.
    • Update relevant announcement files and documentation, including webview-ui/src/components/chat/Announcement.tsx, README.md, and the latestAnnouncementId in src/core/webview/ClineProvider.ts.
    • Ask the user to confirm the English announcement before proceeding.
    • Arrange translation updates for all supported locales affected by README, announcement, or package localization changes. Use the /roo-translate skill to propagate the updated chat.json announcement highlight keys and the "What's New" section to all supported locales.
    • All 17 locale READMEs should contain a translated "What's New" section. Check each one and add a translated section where missing.
  8. Create the release branch:

    git checkout -b release/v[version]
    
  9. Bump the version in src/package.json to the target release version and ensure CHANGELOG.md and src/CHANGELOG.md are up to date.

    • Verify the CHANGELOG.md heading uses ## [version] (with brackets).
    • Copy or sync CHANGELOG.md to src/CHANGELOG.md if the project keeps both.
    • Review the generated version and changelog before opening the PR.
  10. Open a single release PR with the fully generated release state.

    git add CHANGELOG.md src/CHANGELOG.md src/package.json README.md locales/*/README.md src/package.nls*.json
    # If generated or updated:
    git add webview-ui/src/components/chat/Announcement.tsx src/core/webview/ClineProvider.ts
    git commit -m "chore: prepare v[version] release"
    git push origin release/v[version]
    gh pr create --title "Release v[version]" --body "Release preparation for v[version]. This PR includes the final version bump, changelog updates, Marketplace README updates, and any announcement changes." --base main --head release/v[version]
    

Read the full file on GitHub · 113 lines

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 · 113 lines · 9 tokens per session scan A fef562b2b04e

Subscribe to this mod's changes

release is a command published in the GitHub repository Zoo-Code-Org/Zoo-Code (1,752 stars, last pushed 2d ago), licensed Apache-2.0. It adds 9 tokens to every session and 1,540 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.