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 srnichols/plan-forge --skill release-notesgit clone --depth 1 https://github.com/srnichols/plan-forgeWrote 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/srnichols/plan-forge/release-notes)<a href="https://agentmods.dev/skills/srnichols/plan-forge/release-notes"><img src="https://agentmods.dev/badge/skills/srnichols/plan-forge/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/srnichols/plan-forge/release-notes"><img src="https://agentmods.dev/badge/skills/srnichols/plan-forge/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.00031 | $0.00893 |
| Opus 5.5 | $0.00012 | $0.00357 |
| Sonnet 5.5 | $0.00006 | $0.00179 |
| Haiku 4.5 | $0.00003 | $0.00089 |
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 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 — 109 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Release Notes Skill
Trigger
"Generate release notes" / "Prepare release" / "What changed since last release?"
Steps
1. Identify Release Range
# Find the last tag
git describe --tags --abbrev=0
# List commits since last tag
git log $(git describe --tags --abbrev=0)..HEAD --oneline --no-merges
Conditional: No Tags Found
If no tags found → ask user for the commit range to use.
2. Categorize Changes
Parse commit messages using conventional commit prefixes:
| Prefix | Category | Show In Notes |
|---|---|---|
feat |
New Features | ✅ Always |
fix |
Bug Fixes | ✅ Always |
perf |
Performance | ✅ Always |
docs |
Documentation | ✅ If significant |
refactor |
Internal | ⚠️ Only if user-visible |
test |
Tests | ❌ Skip |
chore |
Maintenance | ❌ Skip |
ci |
CI/CD | ❌ Skip |
3. Check CHANGELOG
Read CHANGELOG.md for additional context:
- Are there entries not yet in the CHANGELOG?
- Does the CHANGELOG match the git history?
4. Generate Release Notes
Format for GitHub Release:
## What's New
### Features
- **Feature name**: brief description (#PR)
### Bug Fixes
- Fix description (#PR)
### Performance
- Improvement description (#PR)
## Breaking Changes
- (list any breaking changes with migration steps)
## Contributors
- @username (N commits)
5. Verify
- All features from this release are listed
- No unreleased features included
- Breaking changes have migration instructions
- Commit references are correct
Safety Rules
- NEVER fabricate changes not in the git log
- ALWAYS flag breaking changes prominently
- Include migration steps for any breaking change
- Ask for human review before publishing
Temper Guards
| Shortcut | Why It Breaks |
|---|---|
| "The commit messages are good enough" | Commit messages are for developers. Release notes are for users — different audience, different detail level. |
| "Nobody reads release notes" | Users, support teams, and auditors rely on release notes. Missing notes cause support tickets and compliance gaps. |
| "I'll write them after release" | Post-release notes are always incomplete. Context fades fast — write them while the work is fresh. |
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 · 109 lines · 31 tokens per session scan A 419a02e96193
release-notes is a skill published in the GitHub repository srnichols/plan-forge (6 stars, last pushed today), licensed MIT. It adds 31 tokens to every session and 893 once invoked, about $0.0001 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-03.
Other skills, from other repositories
maf-release-watcher
Detects new MAF releases and keeps the registry, matrix and guides current. Pipeline: (1) the watcher diffs every tracked package surface and opens a scaffold PR on a per-version branch, (2) the maf-registry-fill agentic workflow fills the TODOs inside Actions, (3) required PR gates decide; releases without breaking…
release
Prepare and publish Perigon.CLI patch releases, including versioning, release notes, bilingual docs, validation, and the nuget-branch CI handoff.
update-changelog
Update the CHANGELOG.md files of C# projects. Parameters: csroot C# SDK repository root.
skill-ship
Package and finalize completed work for delivery — use when a feature is done and ready to ship.
skill-rollback
Roll back to a previous checkpoint via git — use when a change went wrong and you need to revert.
release
Release a new version of the DevoxxGenie IntelliJ plugin — prompt for the target version, bump it in the build files, write a curated CHANGELOG.md entry and plugin.xml change-notes from the git/PR history since the last tag, build to verify, then commit, tag, and publish a matching GitHub release. Use this whenever…