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.00040 | $0.01227 |
| Opus 5 | $0.00020 | $0.00613 |
| Sonnet 5 | $0.00008 | $0.00245 |
| Haiku 4.5 | $0.00004 | $0.00123 |
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 9d 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.
- 9d 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 (26 stars, last pushed 24d ago), licensed MIT. It adds 40 tokens to every session and 1,227 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-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.
changelog-rules
Shared changelog conventions and formatting rules referenced by /create-changelog and /update-changelog. Not typically invoked directly.
ship
Commit, push, and optionally create or update a PR for the current staged changes. Use when the user asks to "ship", "ship it", "ship changes", "commit push and PR", or "ship this".
stage
Stage implementation changes for commit with precise file selection. Use when the user asks to "stage changes", "stage files", "add files to staging", or "prepare changes for commit".
commit-staged-push
Commit already-staged changes and push in one step. Use when the user asks to "commit and push staged changes", "commit and push what's staged", or "commit staged and push".