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 agentmods add skills/dotcommander/cclint/updaternpx skills add dotcommander/cclint --skill updatergit clone --depth 1 https://github.com/dotcommander/cclintWrote 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/dotcommander/cclint/updater)<a href="https://agentmods.dev/skills/dotcommander/cclint/updater"><img src="https://agentmods.dev/badge/skills/dotcommander/cclint/updater.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 | $0.00071 | $0.02400 |
| Opus 5 | $0.00036 | $0.01200 |
| Sonnet 5 | $0.00014 | $0.00480 |
| Haiku 4.5 | $0.00007 | $0.00240 |
Grade A, and why
updater 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 3d 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 — 192 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Quick Reference
| Step | Action | Tool |
|---|---|---|
| 1. Version gap | Read CLAUDE.md → extract claude_code_last_updated |
Read |
| 2. Fetch changelog | aic claude (primary) or gh api (fallback) |
Bash |
| 3. Classify + summarize | Emit user-visible table covering every changelog entry, then map to cclint domains | — |
| 4. Task list | TaskCreate per domain group | TaskCreate |
| 5. Implement | Parallel Task(sonnet) per task |
Task |
| 6. Verify | Task(sonnet): build, test, cclint |
Task |
| 7. Review docs | Check docs for stale references | Task |
| 8. Ship | Update version, delegate commit | Task |
Domain Classification Table
For each changelog entry, classify against these domains:
| cclint Domain | Signal in Changelog | Source Files |
|---|---|---|
| CUE schema (agent) | New agent frontmatter field, new allowed value | internal/cue/schemas/agent.cue |
| CUE schema (command) | New command frontmatter field | internal/cue/schemas/command.cue |
| CUE schema (skill) | New skill frontmatter field | internal/cue/schemas/skill.cue |
| CUE schema (settings) | New settings field, new setting type | internal/cue/schemas/settings.cue |
| Hook events | New hook event name, changed hook behavior | internal/lint/settings.go |
| Known tools | New tool name in allowed-tools | internal/textutil/lineutil.go |
| Lint rules (agents) | New agent validation requirement, naming rule | internal/lint/agent_linter.go |
| Lint rules (skills) | New skill validation requirement | internal/lint/skill_linter.go |
| Lint rules (commands) | New command validation requirement | internal/lint/command_linter.go |
| Cross-file validation | New reference pattern, new component type | internal/lint/crossfile/ |
| Discovery | New file path pattern, new component directory | internal/discovery/ |
Skip: CLI flags, UI changes, SDK fields, performance improvements, bug fixes to existing behavior.
Output: | Changelog Entry | Domain | Action Required |
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.
- 3d ago First seen · 192 lines · 71 tokens per session scan A 9c0c057c0a14
updater is a skill published in the GitHub repository dotcommander/cclint (16 stars, last pushed 5d ago), licensed MIT. It adds 71 tokens to every session and 2,400 once invoked, about $0.0004 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
doc-comments
Use this skill whenever writing or editing Rust //, ///, or //! comments in Biome, including comments added incidentally and end-user rustdoc inside lint/assist declarations. For lint/assist rustdoc, also load lint-rule-development for content requirements. Do not use for formatter handling of comments in user code.
eslint-migrate-options
Use this skill when biome migrate eslint must preserve configurable ESLint rule options through source-option models, Biome conversions, typed rule variants, and migration fixtures. Do not use for generated severity-only mapping or general rule-option design.
migrate-oxfmt
Guide for migrating a project from Prettier or Biome to Oxfmt. Use when asked to migrate, convert, or switch a JavaScript/TypeScript project's formatter from Prettier or Biome to Oxfmt.
migrate-oxlint
Guide for migrating a project from ESLint to Oxlint. Use when asked to migrate, convert, or switch a JavaScript/TypeScript project's linter from ESLint to Oxlint.
formatter-development
Use this skill when implementing or debugging Biome formatter behavior, IR composition, node rules, layout selection, source-comment handling, verbatim formatting, idempotency, internal specs, or Prettier comparison. Do not use for generic snapshot commands or parser changes.
parser-development
Use this skill when implementing or modifying Biome parser behavior, including .ungram grammars, lexers, token sources, parse rules, separated lists, error recovery, and parser fixtures. Do not use merely for consuming an existing AST/CST.