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/5uck1ess/devkit/changelognpx skills add 5uck1ess/devkit --skill changeloggit clone --depth 1 https://github.com/5uck1ess/devkitWhat 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.00035 | $0.00542 |
| Opus 5 | $0.00017 | $0.00271 |
| Sonnet 5 | $0.00007 | $0.00108 |
| Haiku 4.5 | $0.00003 | $0.00054 |
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 2d 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
Changelog Generation
Generate a structured changelog from git commits between two refs.
Parameters
- From — start ref (default: last tag, or first commit if no tags)
- To — end ref (default: HEAD)
- Format — output format (default: markdown)
Step 1: Gather Commits
# Find the range
FROM=${from:-$(git describe --tags --abbrev=0 2>/dev/null || git rev-list --max-parents=0 HEAD)}
TO=${to:-HEAD}
git log ${FROM}..${TO} --oneline --no-merges
Step 2: Categorize
Analyze each commit and categorize:
- Features — new functionality (
feat:,add:, new files) - Fixes — bug fixes (
fix:,bug:,patch:) - Performance — optimizations (
perf:, benchmark improvements) - Refactoring — code changes with no behavior change (
refactor:,chore:) - Documentation — doc changes (
docs:, README, comments) - Tests — test additions/changes (
test:) - Breaking Changes — anything that changes public API or behavior
Step 3: Output
## Changelog: {from} → {to}
### Features
- Added JWT authentication middleware (#42)
- New `/api/health` endpoint
### Fixes
- Fixed race condition in cache invalidation (#38)
- Corrected timezone handling in date parser
### Performance
- Optimized database queries — 2x faster list endpoints
### Breaking Changes
- Removed deprecated `/api/v1/users` endpoint — use `/api/v2/users`
### Other
- Updated dependencies
- Added CI pipeline for ARM builds
Presets
/devkit:changelog
/devkit:changelog --from v1.2.0 --to v1.3.0
/devkit:changelog --from main --to feature/auth
Rules
- Use actual commit messages — don't fabricate changes
- Group related commits together
- Include PR/issue numbers if present in commit messages
- Highlight breaking changes prominently
- Skip merge commits and trivial changes (typo fixes, formatting)
- If conventional commits are used, respect the prefixes
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.
- 2d ago First seen · 78 lines · 35 tokens per session scan A 93ba67a70bbc
changelog is a skill published in the GitHub repository 5uck1ess/devkit (5 stars, last pushed 13d ago), licensed MIT. It adds 35 tokens to every session and 542 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-31.
Other skills, from other repositories
dynamic-workflows
Ultracode / Max-Parallel mode — dynamic workflows fan work out across tens–hundreds of adversarially-verified parallel subagents for large, decomposable jobs (codebase-wide audits, big migrations, cross-checked research). Opt-in; higher token spend.
cost-efficiency
Smart Routing — the DEFAULT CCGodMode routing policy. Risk-based, minimal-agent paths that preserve required safety gates for the changed scope.
agent-teams
Experimental Agent Teams orchestration — run CCGodMode agents as parallel teammates with SharedTaskList coordination (requires CLAUDECODEEXPERIMENTALAGENTTEAMS=1).
quality-gates
Parallel quality gate orchestration — @validator and @tester run simultaneously after @builder, with mandatory decision matrix for pass/fail routing.
sprint-planning
Plan-first orchestration (ADR-004): comprehensive PLAN.md, sprint files with write-scope ownership, preflight checks, serialized integration, and the release sprint. Use for any non-trivial or multi-part request BEFORE dispatching agents.
workflows
CCGodMode Full-Gates workflow definitions — used for high-risk work and when Smart Routing escalates. Default routing is Smart Routing (skills/cost-efficiency/).