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 codebygarv/Ai-skills --skill changelog-generatorgit clone --depth 1 https://github.com/codebygarv/Ai-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/codebygarv/ai-skills/changelog-generator)<a href="https://agentmods.dev/skills/codebygarv/ai-skills/changelog-generator"><img src="https://agentmods.dev/badge/skills/codebygarv/ai-skills/changelog-generator.svg" alt="Measured on agentmods" 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.00037 | $0.00473 |
| Opus 5 | $0.00018 | $0.00236 |
| Sonnet 5 | $0.00007 | $0.00095 |
| Haiku 4.5 | $0.00004 | $0.00047 |
Grade A, and why
changelog-generator 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 8d 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 — 36 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Purpose
Turn a raw list of commits, PR titles, or dev notes into a clean, categorized changelog entry that a user (not just an engineer) can read and understand what changed.
When to Use
- Preparing release notes for a new version.
- A commit history is a mix of styles/quality and needs to become one coherent changelog.
- The user pastes a list of merged PRs or commit messages and wants them turned into notes.
What to Analyze / Do
- Categorize each change — typically: Added, Changed, Fixed, Removed, Deprecated, Security (following a Keep a Changelog–style structure, or the project's existing convention if different).
- Rewrite for the reader, not the author — "fix null check in auth.js" becomes "Fixed an issue where login could fail unexpectedly for some users." Focus on user-visible impact, not implementation detail, unless the audience is technical (e.g. a library's changelog for other engineers, where technical specificity is appropriate).
- Merge duplicate/related entries — several commits fixing the same underlying issue become one changelog line, not three.
- Drop non-user-facing noise — pure refactors, test-only changes, CI config tweaks typically don't belong in user-facing release notes (may still belong in an "Internal" section for a technical audience).
- Flag breaking changes prominently — these should never be buried among minor fixes.
Output Format
- Version header (if known) and date.
- Grouped by category (Added / Changed / Fixed / Removed / Deprecated / Security), only including categories that have entries.
- Each entry: one clear sentence, user-facing language, imperative or past tense consistent throughout.
- Breaking changes called out in their own clearly marked subsection if any exist.
Avoid
- Listing every commit 1:1 — the point is synthesis, not transcription.
- Vague entries like "various fixes and improvements" — every entry should say what actually changed.
- Losing breaking-change information by burying it in a generic "Changed" bullet.
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.
- 8d ago First seen · 36 lines · 37 tokens per session scan A 68270b3a4ae6
changelog-generator is a skill published in the GitHub repository codebygarv/Ai-skills (25 stars, last pushed 19d ago), licensed MIT. It adds 37 tokens to every session and 473 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-30.
Other skills, from other repositories
git-pr
PR and MR workflows for GitHub (gh) and GitLab (glab). Creation, review comment handling, thread resolution, review state queries, merging, cost-aware bot review rounds (GitHub: Copilot, CodeRabbit), and Copilot code review configuration (rulesets, custom instructions, billing). Use when creating PRs/MRs, addressing…
git-project
GitHub Projects (v2) setup and management via gh CLI + GraphQL: organize a repo's issues into epics with native sub-issues, drive a board Status flow (Todo -> In Progress -> Done), set Project Priority, classify with native issue Types (Task/Bug/Feature) instead of labels, scope work with milestones (incl. resolving…
git-commit
Conventional Commits format for git commits and PR/MR titles. Type prefixes, scope rules, breaking change syntax, and commit message structure. Use when committing changes, writing commit messages, creating PR/MR titles, or formatting squash merge messages. Not for PR workflows (git-pr), CI/CD status (git-ci), or git…
ds-ship
Ship orchestrator — classify the project, pick a mode (improve/release/launch/maintain), delegate only the skills the project's signals justify, consolidate findings, produce an audit report. Use for an end-to-end audit or ship pipeline across multiple skills.
ds-freeze
Release scope triage — decide which features ship this release vs defer to backlog, then file/implement the kept set and sync docs to match. Use when a release has grown too complex to finish or polish everything and the team needs to cut scope deliberately.
ds-release
Release cutter — version from the commits, dated CHANGELOG section, every version surface bumped, project check green, local release commit + annotated tag; every publishing step (push, GitHub release, registry, store) handed to the human with the exact command. Use when a release is to be cut.