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.
npx agentmods add commands/zoo-code-org/zoo-code/releasegit clone --depth 1 https://github.com/Zoo-Code-Org/Zoo-CodeWhat 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.
| Model | Per session | Once 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 |
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.
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.
-
Identify the most recent stable extension release:
gh release view --json tagName,targetCommitish,publishedAt -
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)' -
For each PR with linked issues, fetch the issue reporter:
gh issue view ISSUE_NUMBER --json number,author -q '{number, reporter: .author.login}' -
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.patchand 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.
-
Review and update the Marketplace-facing root
README.md.- Treat root
README.mdas 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 rootREADME.mdintosrc/README.md. - Check for stale upstream Roo Code wording that should now say Zoo Code.
- Treat root
-
Write the release notes directly into
CHANGELOG.mdon the release branch.- Use the heading format
## [version](with square brackets) — e.g.## [3.58.1]. The publish workflow at.github/workflows/marketplace-publish.ymlextracts 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.
- Use the heading format
-
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 thelatestAnnouncementIdinsrc/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-translateskill to propagate the updatedchat.jsonannouncement 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.
-
Create the release branch:
git checkout -b release/v[version] -
Bump the version in
src/package.jsonto the target release version and ensureCHANGELOG.mdandsrc/CHANGELOG.mdare up to date.- Verify the
CHANGELOG.mdheading uses## [version](with brackets). - Copy or sync
CHANGELOG.mdtosrc/CHANGELOG.mdif the project keeps both. - Review the generated version and changelog before opening the PR.
- Verify the
-
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]
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.
- yesterday First seen · 113 lines · 9 tokens per session scan A fef562b2b04e
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.
Other commands, from other repositories
checklist
Generate a custom checklist for the current feature based on user requirements.
clarify
Identify underspecified areas in the current feature spec by asking up to 5 highly targeted clarification questions and encoding answers back into the spec.
specify
Create or update the feature specification from a natural language feature description.
analyze
Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.
converge
Assess the current codebase against the feature's spec, plan, and tasks, then append any remaining unbuilt work as new tasks to tasks.md so implement can complete it.
implement
Execute the implementation plan by processing and executing all tasks defined in tasks.md.