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 nimadorostkar/Claude-Skills-collection --skill changeloggit clone --depth 1 https://github.com/nimadorostkar/Claude-Skills-collectionWrote 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/nimadorostkar/claude-skills-collection/changelog)<a href="https://agentmods.dev/skills/nimadorostkar/claude-skills-collection/changelog"><img src="https://agentmods.dev/badge/skills/nimadorostkar/claude-skills-collection/changelog/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/nimadorostkar/claude-skills-collection/changelog"><img src="https://agentmods.dev/badge/skills/nimadorostkar/claude-skills-collection/changelog.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.00095 | $0.01282 |
| Opus 5.5 | $0.00038 | $0.00513 |
| Sonnet 5.5 | $0.00019 | $0.00256 |
| Haiku 4.5 | $0.00010 | $0.00128 |
Grade A, and why
changelog 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 17d 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 — 124 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Changelog
Purpose
Tell users what changed and what they must do about it. A changelog is not a git log; it is a communication with people who have built something on your software.
When to Use
- Writing release notes.
- Maintaining a CHANGELOG file.
- Announcing a breaking change.
- Deciding a version number.
Capabilities
- Changelog structure and categorization.
- Writing for users rather than for contributors.
- Semantic versioning.
- Breaking-change communication and migration guidance.
Inputs
- The commits, pull requests, or issues in the release.
- Who uses the software and what they have built on it.
- Whether anything breaks.
Outputs
- A changelog entry organized by impact.
- A version number that reflects what changed.
- Migration instructions for anything that breaks.
Workflow
- Group by what it means to the user — Added, changed, deprecated, removed, fixed, security. Not by component, and certainly not by commit.
- Lead with the breaking changes — They are what the reader is looking for. Bury them and someone's deployment fails.
- Write in terms of the user's experience — "Exports now include line items", not "refactored
ExportSerializerto includeLineItemMixin". - Version honestly — A breaking change is a major version, however small it is. Renaming a public field is breaking, even if it felt like a typo fix.
- Give the migration, not just the warning — "This is removed" is a problem. "This is removed; use X instead, like this:" is a solution.
- Skip the noise — Internal refactors, dependency bumps with no behavioral effect, and CI changes do not belong in a user-facing changelog.
Best Practices
- The reader of a changelog has one question: "will this break my build, and what do I have to change?" Answer it first.
- A commit log is not a changelog.
fix: handle nil case in parsermeans nothing to a user; "Fixed a crash when parsing an empty configuration file" does. - Any change to a public interface — a field name, a default value, an error type, a status code — is breaking. Version it accordingly, whatever it cost you to make.
- A deprecation needs a timeline and a replacement. "Deprecated" with neither is an announcement that something will break, eventually, with no notice.
- Link to the pull request or issue for detail. Keep the entry itself short.
- Date every release. "Unreleased" at the top, dated on release.
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.
- 17d ago Changed · +55 tokens per session 3f1b6a46e61d
- 1mo ago First seen · 124 lines · 40 tokens per session scan A d1e314ddbb42
changelog is a skill published in the GitHub repository nimadorostkar/Claude-Skills-collection (33 stars, last pushed 3d ago), licensed MIT. It adds 95 tokens to every session and 1,282 once invoked, about $0.0004 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
git-workflow-and-versioning
Structures git workflow practices. Use when making any code change. Use when committing, branching, resolving conflicts, splitting uncommitted work in a messy working tree into clean atomic commits, opening or reviewing a pull request (PR), pushing to a remote, or when you need to organize work across multiple…
comet-safe-delivery
A Chinese-language procedure for safely delivering specified Comet changes through Git. It covers checking worktrees and unrelated edits, staging exact files, validating hooks, and authorized commits or pushes.
git-workflow
Guided git workflows: prepare PRs, clean up branches, resolve merge conflicts, handle monorepo tags, squash-and-merge patterns. Use when asked to prepare a PR, clean branches, resolve conflicts, or tag a release.
changelog-generator
Convierte un git log, lista de commits o notas de lanzamiento en un changelog pulido orientado al usuario. Usa cuando estés escribiendo notas de versión, generando una entrada en CHANGELOG.md o documentando qué cambió en una versión. Produce una sección de changelog estructurada con encabezado de versión, cambios…
release-notes-from-git-log
Turn a git log into user-facing release notes grouped by feature and fix. Use when asked for release notes from this git log, a changelog entry from these commits, or to turn commits into release notes. Produces a grouped changelog with one line per change and a short headline.
changelog-rules
Shared changelog conventions and formatting rules referenced by /create-changelog and /update-changelog. Not typically invoked directly.