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/flc1125/skills/github-release-notes-writernpx skills add flc1125/skills --skill github-release-notes-writergit clone --depth 1 https://github.com/flc1125/skillsWhat 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.00084 | $0.01438 |
| Opus 5 | $0.00042 | $0.00719 |
| Sonnet 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 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 — 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.
- 3d 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 4d ago), licensed MIT. It adds 84 tokens to every session and 1,438 once invoked, about $0.0004 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
app-release
Automates the release process for Skill Lake app, including version bumping, building, packaging, and publishing to GitHub and Homebrew.
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.
git-workflow-and-versioning
Use when managing branches, commits, versioning, and release workflows for Android projects. Covers trunk-based development, atomic commits, versionCode/versionName, and signing configurations.
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.
gemini
Use when the user requests to run Gemini CLI for code analysis, refactoring, or automated editing.
clawhub-production-release
Run and verify ClawHub production deploys and stable ClawHub CLI npm releases. Use when deploying backend or frontend changes to clawhub.ai, dispatching the Deploy workflow, publishing a stable CLI tag, checking release prerequisites, or proving the exact production SHA and workflow outcome.