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 skills/noah-hrbth/agent-tool-sync/release-prepnpx skills add noah-hrbth/agent-tool-sync --skill release-prepgit clone --depth 1 https://github.com/noah-hrbth/agent-tool-syncWhat 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.00063 | $0.00861 |
| Opus 5 | $0.00032 | $0.00430 |
| Sonnet 5 | $0.00013 | $0.00172 |
| Haiku 4.5 | $0.00006 | $0.00086 |
Grade A, and why
release-prep 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 3d 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.
How it starts
The opening of the file, as written. The whole thing — 105 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Release Prep
Goal: produce a release-readiness report and a proposed version bump for the user to approve. Never tag, push, or invoke goreleaser release (non-snapshot) yourself — those actions affect remotes and are out of scope.
Procedure
1. Confirm clean state
git status --porcelain
git rev-parse --abbrev-ref HEAD
Abort with a clear message if there are uncommitted changes or the branch is not main. Releases should cut from a clean main.
2. Identify the current and previous tag
git describe --tags --abbrev=0 # latest tag, e.g. v0.4.2
git tag --sort=-v:refname | head -5
3. Summarize commits since the last tag
git log <last-tag>..HEAD --pretty=format:'%h %s'
Group the output by the changelog regex groups in .goreleaser.yaml (Features = ^.*feat[(\w)]*:+.*$, Bug fixes = ^.*fix[(\w)]*:+.*$, Refactors = ^.*refactor[(\w)]*:+.*$, Other = everything not excluded by ^docs:, ^chore:, ^test:, ^ci:, ^style:).
4. Propose the next version
Apply conventional-commit semver inference:
- Any
feat!:/BREAKING CHANGE:→ bump major. - Any
feat:(and no breaking) → bump minor. - Only
fix:/refactor:/chore:→ bump patch. - No commits since last tag → no release; report and stop.
State the proposed version and the rule that produced it.
5. Validate the goreleaser config
make release-check # runs `goreleaser check`
Surface any errors verbatim.
6. Build a snapshot
make release-snapshot # goreleaser release --snapshot --clean --skip=publish
This validates that the build pipeline (builds, archives, homebrew_casks rendering) succeeds locally without publishing. Then list dist/ and confirm the expected per-OS/per-arch archives are present:
ls dist/
7. Report
# Release prep: <proposed-version>
## Branch: main (clean)
## Last tag: <vX.Y.Z>
## Commits since: N
### Features
- <hash> <subject>
### Bug fixes
- <hash> <subject>
### Refactors
- <hash> <subject>
### Other
- <hash> <subject>
## Proposed version: <vX.Y.Z+1>
## Bump rule: <major | minor | patch> — <one-line justification>
## goreleaser check: <pass/fail>
## snapshot build: <pass/fail>
## dist artifacts: <count> archives
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.
- 3d ago First seen · 105 lines · 63 tokens per session scan A e0563c3e25ab
release-prep is a skill published in the GitHub repository noah-hrbth/agent-tool-sync (2 stars, last pushed 13d ago), licensed MIT. It adds 63 tokens to every session and 861 once invoked, about $0.0003 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-31.
Other skills, from other repositories
release
Cut a Symphony release by bumping the committed version, landing it, tagging the merged commit, and verifying the Burrito release workflow. Use when asked to release, tag, or retag Symphony.
release-notes
Draft concise release notes.
greptimedb-release
Runbook for publishing a new GreptimeDB version (tag + GitHub release + docs release-note PR) on the upstream GreptimeTeam/greptimedb repo. Use when asked to "release" / "publish" a GreptimeDB version (e.g. v1.1.0, v1.0.3).
refresh-arm-sdk-release
WORKFLOW SKILL — Prepares Azure.ResourceManager SDK refresh pull requests in azure-sdk-for-net. WHEN: "prepare sdk refresh", "refresh Azure.ResourceManager package", "update ARM SDK from autorest tag", "refresh changelog dependencies". INVOKES: git and GitHub pull request tools for branch, commit, push, and PR…
store-update
在 CCX Desktop 发布后下载 Store MSIX 并生成发布公告。用户提到 Store 上架、MSIX、从 GitHub Release 下载 store.msix、发布后同步 Windows Store、从 release 填写商店更新内容时必须使用此技能。该技能会下载最新 GitHub Release 的 amd64/arm64 MSIX，校验 sha256，从 Release body 生成 Store listing releaseNotes 预览，并输出手动上传指引。.
publish-registry
Publish @agentos-software/ registry packages from AgentOS. Use whenever the user asks to publish or release registry software/agent packages.