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 skills add duthaho/claudekit --skill release-and-changeloggit clone --depth 1 https://github.com/duthaho/claudekitWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/duthaho/claudekit/release-and-changelog)<a href="https://agentmods.dev/skills/duthaho/claudekit/release-and-changelog"><img src="https://agentmods.dev/badge/skills/duthaho/claudekit/release-and-changelog/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/duthaho/claudekit/release-and-changelog"><img src="https://agentmods.dev/badge/skills/duthaho/claudekit/release-and-changelog.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to high
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- high Anti-Refusal · line 183 Skill instructs the agent to omit warnings, disclaimers, or ethical commentary. Stripping safety caveats hides risk from the user and is a common jailbreak preamble.Fix: Remove instructions that suppress warnings, disclaimers, or ethical commentary. Let the agent surface safety-relevant caveats to the user.
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.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00099 | $0.02833 |
| Opus 5 | $0.00049 | $0.01417 |
| Sonnet 5 | $0.00020 | $0.00567 |
| Haiku 4.5 | $0.00010 | $0.00283 |
Grade A, and why
release-and-changelog 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 11d 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 — 220 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Release and Changelog
Overview
A workflow for cutting a clean release: bump the version, write changelog
entries that reflect the actual diff, tag, publish. The skill exists because
the most common release-time failure isn't the publishing mechanism — it's the
changelog that says "various improvements" or "performance enhancements"
without naming what changed. Users reading the notes can't decide whether to
upgrade; engineers debugging six months later can't bisect on the release.
This skill enforces that the changelog is built from the diff, not from a
remembered list of features. Used after code-review-loop and before
publishing/tagging.
When to Use
- Cutting a numbered release (
v1.2.0,v2.0.0-rc1, etc.) - Updating a
CHANGELOG.mdafter a feature merge in projects with a rolling-changelog policy - Bumping a package version in a published library
- Writing release notes for a deploy that crosses a version boundary
When NOT to Use
- Continuous-deployment projects with no version concept (every merge is a deploy; there's no release event)
- Internal services where deploys don't carry version semantics for consumers
- A trivial doc-only or test-only change (changelog entry optional per project policy)
Process
Step 1: Determine the version bump
Goal: Pick the correct SemVer level.
Inputs: The set of changes since the last release.
Actions:
- List every change since the last tag:
git log <last-tag>..HEAD --oneline. - Classify each change:
- Breaking (incompatible API change, removed feature, changed behavior that callers depend on) → MAJOR bump
- New feature (additive, backward-compatible) → MINOR bump
- Bug fix or internal improvement (no behavioral change for callers) → PATCH bump
- The bump is the highest classification across all changes. One breaking change in a release of 50 fixes is still a MAJOR bump.
- If the project is pre-1.0 (
0.x.y), treat MINOR as breaking-allowed and PATCH as the conservative bump. The 0.x.y SemVer license to break is real but should still be exercised consciously.
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.
- 11d ago First seen · 220 lines · 99 tokens per session scan A 6efb678de572
release-and-changelog is a skill published in the GitHub repository duthaho/claudekit (97 stars, last pushed 1mo ago), licensed MIT. It adds 99 tokens to every session and 2,833 once invoked, about $0.0005 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 skills, from other repositories
land-and-deploy
Merge PR, wait for CI, verify deploy, run canary. The complete landing pipeline.
source-command-update-infos-release
Update Codex releases tracking (guide + landing + version bump).
release-notes-generator
Generate release notes in 3 formats (CHANGELOG.md, PR body, Slack announcement) from git commits. Automatically categorizes changes and converts technical language to user-friendly messaging. Use for releases, changelogs, version notes, what's new summaries, or ship announcements.
release-notes
Generate release notes in multiple formats from git commits.
ship
Comprehensive pre-deployment verification to ensure release readiness.
talk-stage2-research
Performs git archaeology, changelog analysis, and builds a verified factual timeline by cross-referencing git history with source material. REX mode only (skipped automatically in Concept mode). Use when building a REX talk and you need verified commit metrics, release timelines, and contributor data from a git…