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 skilletmd/skillet --skill changelog-draftgit clone --depth 1 https://github.com/skilletmd/skilletWrote 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/skilletmd/skillet/changelog-draft)<a href="https://agentmods.dev/skills/skilletmd/skillet/changelog-draft"><img src="https://agentmods.dev/badge/skills/skilletmd/skillet/changelog-draft/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/skilletmd/skillet/changelog-draft"><img src="https://agentmods.dev/badge/skills/skilletmd/skillet/changelog-draft.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.00047 | $0.00669 |
| Opus 5 | $0.00023 | $0.00334 |
| Sonnet 5 | $0.00009 | $0.00134 |
| Haiku 4.5 | $0.00005 | $0.00067 |
Grade A, and why
changelog-draft 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 10d 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 — 65 lines — stays where its author put it; the contents beside it link to each section on GitHub.
changelog-draft
A changelog is for the reader deciding whether to upgrade, not a reprint of your git log. "Refactor auth middleware" means nothing to them; "you stay logged in across browser restarts now" does. This skill turns one into the other.
When to use
Cutting a release or writing release notes. Works from git history or a list of merged PRs.
Gather the raw material
# Find the last release tag (empty if the repo has none yet)
LAST=$(git describe --tags --abbrev=0 2>/dev/null)
# Commits since that tag — or the whole history if there's no tag yet
git log ${LAST:+$LAST..}HEAD --oneline
# Or merges since a date, if that's your workflow
git log --merges --since="2 weeks ago" --oneline
Group by what the reader cares about
Drop the internal categories (refactor, chore, test). Use these:
- Added — new things the user can now do.
- Changed — behavior that's different; flag anything that changes a default.
- Fixed — bugs that are gone. Describe the symptom they saw, not the code you touched.
- Deprecated / Removed — what will stop working, and what to use instead.
- Security — vulnerabilities fixed. Always its own section; never buried.
Internal-only commits — refactors, test changes, dependency bumps with no user impact — don't go in the changelog. If nothing user-facing changed, write "Internal improvements" and stop.
Rewrite each line for the user
| Commit | Changelog entry |
|---|---|
fix: null check in session loader |
Fixed a crash when opening the app with an expired session. |
feat: add --json flag to export |
export now accepts --json for machine-readable output. |
refactor: extract validation helper |
(omit — no user-facing change) |
Lead each entry with what the user can do, or no longer has to worry about. Past tense, plain language, no ticket numbers mid-sentence (link them at the end if you must).
Call out breaking changes loudly
Anything that breaks existing usage goes at the top, under Breaking changes, with the exact migration step:
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.
- 10d ago First seen · 65 lines · 47 tokens per session scan A a73e7baf1a43
changelog-draft is a skill published in the GitHub repository skilletmd/skillet (3 stars, last pushed 10d ago), licensed Apache-2.0. It adds 47 tokens to every session and 669 once invoked, about $0.0002 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-31.
Other skills, from other repositories
github-release-briefing-skill
Create a source-linked briefing for the latest published GitHub release of a public repository. Use for engineering teams tracking a dependency release; do not use it to publish releases or change repositories.
ijfw-ship
Use when the user says 'ship it', 'ship this', 'release', 'publish', 'launch', 'deploy', 'go live', 'wrap this up', 'time to ship', or invokes '/ijfw-ship'. Domain-aware release — software (test → tag → push → publish), book (final edit → format → KDP / agent / Substack), campaign (review → schedule → launch →…
ijfw-preflight
Run the IJFW preflight pipeline (11 gates, fail-fast). Trigger: 'ijfw preflight', 'run preflight', 'check before ship', 'preflight gates', 'validate before release'.
github-pr-merge
Merges GitHub Pull Requests after validating pre-merge checklist. Use when user wants to merge PR, close PR, finalize PR, complete merge, approve and merge, or execute merge. Runs pre-merge validation (tests, lint, CI, comments), confirms with user, merges with proper format, handles post-merge cleanup.
git-authoring
Authors and executes git work end to end — Conventional Commits messages, pull-request content, release notes, and pull-request review, plus the repository operations an engineer runs daily: branching, rebasing, squashing, cherry-picking, reverting, merge-conflict resolution, stashes, tags, remotes, and recovery…
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.