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.
git clone --depth 1 https://github.com/cosmix/loomWrote 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/commands/cosmix/loom/changelog)<a href="https://agentmods.dev/commands/cosmix/loom/changelog"><img src="https://agentmods.dev/badge/commands/cosmix/loom/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/commands/cosmix/loom/changelog"><img src="https://agentmods.dev/badge/commands/cosmix/loom/changelog.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.00025 | $0.00758 |
| Opus 5.5 | $0.00010 | $0.00303 |
| Sonnet 5.5 | $0.00005 | $0.00152 |
| Haiku 4.5 | $0.00003 | $0.00076 |
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 14d 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.
What it actually says
$1 is the version this changelog entry is being written for (e.g. 0.9.0). If it is missing, tell the user to run /changelog <next-version> and stop — do not guess a version.
Find where the last release left off: run git tag --list 'v*.*.*' --sort=-v:refname and take the first line, or git describe --tags --abbrev=0 --match 'v*.*.*' if that is empty. If there are no matching tags, fall back to git log -1 --format=%H -S'## [' -- CHANGELOG.md to find the commit that most recently added a version heading. If neither resolves to a ref, stop and tell the user you cannot find a starting point.
Review every commit in <that ref>..HEAD for user-facing features only: new commands, subcommands, flags, stage types, plan-YAML fields, operator-visible hooks, new output surfaces, new platform support, and changed defaults an operator would notice, plus anything removed or renamed. Explicitly exclude bug fixes, refactors, internal tests, knowledge/doc commits, CI plumbing, and invisible performance work. git diff <ref>..HEAD -- README.md and the diff of loom/src/main.rs are the highest-signal cross-checks, since they surface new clap commands and flags directly. Be strict: a large range should still yield a handful of bullets, one per coherent capability rather than one per commit.
Update CHANGELOG.md in place:
- Sections are grouped by minor version, headed
## [X.Y.x] - YYYY-MM-DD. Derive the group from $1:0.9.0becomes0.9.x;0.8.2becomes0.8.x. - If that group's section already exists, merge the new bullets into its existing
### Added/### Changed/### Removedsubsections and bump the heading's date to today. Do not duplicate a capability already described there — extend the existing bullet instead. - If it does not exist yet, prepend a new section directly below the file's preamble, above every existing version section.
- The file never has a
## [Unreleased]section: the section being written is always the next version. Never add one; if one exists, fold its bullets into the version section being written and delete the heading. - Never reorder or reword sections for versions older than the one you are writing.
- There is no
### Fixedsubsection in this file — do not add one.
Match the file's existing voice: one bullet per feature, a bolded short name, an em dash, then one or two sentences of concrete prose naming the actual command or flag involved. Keep each bullet to one long line, no hard wrapping. No marketing language and no LLMisms — no "seamless", "robust", "unlock", "leverage" as a verb, no "not X but Y" constructions, and no closing summary line recapping what you wrote.
When done, tell the user exactly what you wrote (the section heading and the bullets added or merged), and remind them this has to run before cutting the release: .github/workflows/release.yml pulls the tagged version's section straight out of CHANGELOG.md for the GitHub release notes, so an unwritten section means a release published with no notes.
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.
- 14d ago Changed 5372e07cf940
- 1mo ago First seen · 24 lines · 25 tokens per session scan A 72874ed28130
changelog is a command published in the GitHub repository cosmix/loom (62 stars, last pushed today), licensed MIT. It adds 25 tokens to every session and 758 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-17.
Other commands, from other repositories
ship
Run the pre-launch checklist via parallel fan-out to specialist personas, then synthesize a go/no-go decision.
commit-push-pr
Commit, push, and open a PR.
vios-release-note
Generate a complete VIOS multi-arch release note for a given build drop version. Fetches container images from GitLab compose.env, GitLab commit titles since the previous release tag, Jira VST tickets, NVBugs entries, Slack channel evidence, and Outlook email evidence, then renders and saves a formatted release note.
release-update
(dev-only) release-update maintainer harness — Claude Code upstream change tracker (release-notes version-delta sweep + docs sync). NOT distributed to user projects.
release
Release manager for frontend and mobile. Writes App Store notes, user-facing changelog, flags stale docs and landing copy. Actions: notes | changelog | docs | sync.
devkit.github.review-pr
Provides comprehensive GitHub pull request review with code quality, security, and best practices analysis. Use when reviewing a PR before merging.