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 no-human-ai/no_human --skill release-notesgit clone --depth 1 https://github.com/no-human-ai/no_humanWrote 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/no-human-ai/no_human/release-notes)<a href="https://agentmods.dev/skills/no-human-ai/no_human/release-notes"><img src="https://agentmods.dev/badge/skills/no-human-ai/no_human/release-notes/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/no-human-ai/no_human/release-notes"><img src="https://agentmods.dev/badge/skills/no-human-ai/no_human/release-notes.svg" alt="Reviewed on agentmods" width="80" height="20"></a>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.00041 | $0.01954 |
| Opus 5.5 | $0.00016 | $0.00782 |
| Sonnet 5 | $0.00008 | $0.00391 |
| Haiku 4.5 | $0.00004 | $0.00195 |
Grade A, and why
release-notes 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 9d 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 — 141 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Release notes
Turn one release (a tag, or a range of commits) into notes a reader skims in under a minute: what the release does for them, stated as impact, and a thank- you to everyone whose work is in it. Not a changelog, not a commit list.
Three rules, in priority order:
- Lead with business impact, not mechanism. Every line answers "what does this change let me do / stop worrying about," not "what file moved." Group by the value to the reader, not by subsystem. Drop anything a user never sees (CI wiring, test-only changes, internal refactors) unless it changed a guarantee they rely on.
- Thank every contributor whose commits are in the release (see below). Completeness here is not optional — a missing name is the one error people notice.
- Short. If a section is not impact or thanks, cut it. No methodology hedging, no "we're excited to", no filler. A reader should reach the end without scrolling twice.
Step 1 — establish the exact range, then read it
Never write from memory or from a PR list. Read the real commits.
- Find the previous release tag and this one:
git tag --sort=-creatordate | head. - List the commits:
git log <prev-tag>..<this-tag> --format='%h %an%x09%s'. (If there is no tag yet, use<prev-tag>..HEADand say so.) - Verify both endpoints resolve (
git rev-parse <tag>), and that the range is non-empty. An empty range means the wrong tags — stop and fix it.
Read every subject line. Cluster them by what the user gets. A cluster of five commits that together fix one thing is ONE bullet about that thing.
Step 2 — write the impact, and claim only what the range establishes
For each cluster, write one line of impact. Constraints:
- State only what the commits actually did. If you cannot point to the commit that establishes a claim, do not make the claim. No numbers without a source you can name (a command, a file). If you quote a measurement, say where it was measured.
- Platform coverage and signing, when relevant, are stated plainly and honestly — what is signed, what is not, and what the user must do about it. Never imply a signature or an auto-update path that does not exist.
- Keep the project's own voice. Do not add a tagline the project has not adopted; if it has a pinned one, use it verbatim and do not reword it.
- Banned, because they read as machine-written or as marketing haze: "verbatim", "delve", "seamless", "robust", "we're thrilled/excited", "leverage" (as a verb), "in today's fast-paced". Say the plain thing instead.
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.
- 9d ago First seen · 141 lines · 41 tokens per session scan A b8adce480127
release-notes is a skill published in the GitHub repository no-human-ai/no_human (320 stars, last pushed today), licensed MIT. It adds 41 tokens to every session and 1,954 once invoked, about $0.0002 per session on Opus 5.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-09-16.
Other skills, from other repositories
release-verification
A release-verification checklist for software versions and packages. It covers changelogs, tests, packaging, installation smoke checks, version-control actions, publishing, and checks after release.
audit-release
A pre-release review assistant that checks whether a software package or plugin is ready to publish.
github
Interact with GitHub using the gh CLI. Use for issues, PRs, CI runs, releases, and advanced API queries.
add-changelog-entry
Add a changelog entry to UNRELEASED.md.
changelog
Turn a range of commits or merged PRs into a changelog entry grouped by change type. Use when the user asks for release notes, a changelog, or "what changed" between two points.
goal-issues-and-release
Clear the open issue backlog and then cut a release, in one autonomous run: use the batch-all-issues skill to resolve every open issue, then the goal-release skill to draft, merge, and see the release through publication. Never asks the user anything — every decision is made autonomously, and blockers are reported at…