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 flc1125/skills --skill github-release-notes-writergit clone --depth 1 https://github.com/flc1125/skillsWrote 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/flc1125/skills/github-release-notes-writer)<a href="https://agentmods.dev/skills/flc1125/skills/github-release-notes-writer"><img src="https://agentmods.dev/badge/skills/flc1125/skills/github-release-notes-writer/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/flc1125/skills/github-release-notes-writer"><img src="https://agentmods.dev/badge/skills/flc1125/skills/github-release-notes-writer.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
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.00084 | $0.01438 |
| Opus 5.5 | $0.00034 | $0.00575 |
| Sonnet 5.5 | $0.00017 | $0.00288 |
| Haiku 4.5 | $0.00008 | $0.00144 |
Grade A, and why
github-release-notes-writer 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 1mo 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 — 151 lines — stays where its author put it; the contents beside it link to each section on GitHub.
GitHub Release Notes Writer
Write Release Notes that help users understand why a release matters and how to upgrade safely without losing the exact changelog record.
Operating Boundaries
- Default to a local Markdown draft. Do not create, edit, publish, or delete a GitHub Release unless the user explicitly asks for that write.
- Inspect release URLs, tags, pull requests, and repository content read-only when the user asks to research or draft.
- Treat Release Notes as user- and upgrader-facing. Do not copy a reviewer-focused Release PR description unchanged.
- Preserve the exact changelog baseline while curating its narrative and categories.
- Prefer current code, tests, documentation, tags, and GitHub state over recalled conversation details.
Workflow
1. Discover release conventions and inputs
Read applicable repository instructions, release documentation, recent Release Notes, version manifests, and any user-provided baseline.
Identify:
- repository and target version
- prerelease or stable status
- immediate previous tag
- target tag or immutable target commit
- release branch when the target tag does not yet exist
- last stable version of the previous major when preparing a stable major release
- monorepo or multi-module upgrade requirements
- requested output path and whether publication is authorized
Follow the repository's established tone and heading style unless the user asks for another format.
2. Resolve the exact changelog range
Use the immediate previous tag to target tag or commit for What's Changed and the Full Changelog link:
git fetch --tags
git rev-parse <previous-tag>^{commit}
git rev-parse <target-tag-or-commit>^{commit}
git log --format='%H%x09%s' <previous-tag>..<target>
When the target is a stable major release following prereleases, use two layers:
| Layer | Purpose |
|---|---|
| Immediate previous tag to target | Exact PR inventory and Full Changelog |
| Previous stable major to target | Concise cumulative upgrade and migration context, not automatically an exact Git range |
What ships with it
2 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 1mo ago First seen · 151 lines · 84 tokens per session scan A c8508ca791f3
github-release-notes-writer is a skill published in the GitHub repository flc1125/skills (36 stars, last pushed today), licensed MIT. It adds 84 tokens to every session and 1,438 once invoked, about $0.0003 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-08-30.
Other skills, from other repositories
git-workflow-and-versioning
Use when managing branches, commits, versioning, and release workflows for Android projects, or when cutting a release, choosing a version bump, tagging, or writing a changelog. Covers trunk-based development, atomic commits, versionCode/versionName derived from tags, semver for library modules, changelogs and Play…
shipping-and-launch
Use when preparing to release an Android app to production. Pre-launch checklist covering code quality, security, performance, accessibility, Play Store requirements, staged rollout, and rollback planning.
bump-version
Automate version bumping following semantic versioning and changelog management. Use when the user wants to bump a version, create a release, update the changelog, or tag a new version in a project using semver conventions and Keep a Changelog format.
app-release
Automates the release process for Skill Lake app, including version bumping, building, packaging, and publishing to GitHub and Homebrew.
release-openspec
Use this skill when releasing OpenSpec: audit merged work and changeset coverage, decide whether a catch-up changeset PR is needed, prepare or resume the Changesets Version Packages PR, cut a beta or stable release, verify publishing, and polish GitHub release notes. Also use when asked whether an open release PR is…
gh-cli
GitHub CLI (gh) comprehensive reference for repositories, issues, pull requests, Actions, projects, releases, gists, codespaces, organizations, extensions, and all GitHub operations from the command line.