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 commands/naimkatiman/continuous-improvement/release-traingit clone --depth 1 https://github.com/naimkatiman/continuous-improvementWhat 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.00060 | $0.01143 |
| Opus 5 | $0.00030 | $0.00571 |
| Sonnet 5 | $0.00012 | $0.00229 |
| Haiku 4.5 | $0.00006 | $0.00114 |
Grade A, and why
release-train 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 — 82 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/release-train
Long-running autonomous orchestrator for stacked-PR rollouts. Driven by the user's session report (1,218 messages, 178 sessions): the audit-then-execute pattern landed at fully_achieved when sessions opened with a stacked-PR plan; sessions that started as big-bang multi-file edits landed at partially_achieved.
This command formalizes the pattern. It does NOT bypass branch protection, force-push, or merge unreviewed PRs.
Preconditions
Before invoking this command:
- A
RELEASE_PLAN.md(ordocs/plans/YYYY-MM-DD-<slug>.md) exists in the repo with a per-PR table, dependency graph, worktree-per-PR, and out-of-scope list. Per the Stacked-PR Plan Precondition in the unified/superpowersdispatcher. - The plan was reviewed and explicitly approved by the operator.
- The base branch (
main) is clean and up to date withorigin/main. - CI is green on
origin/main.
If any precondition fails, this command halts and reports what is missing rather than improvising.
Behavior
For each PR in the plan, in dependency order:
- Worktree —
git worktree add -b <branch> ../<branch> origin/main(or off the previous PR's branch when the dependency requires it). - Implement — TDD-first per
superpowers:test-driven-development: failing test, watch it fail, write minimal code, watch it pass, commit. - Verify —
superpowers:verification-before-completionbefore claiming done. Smallest check that proves correctness. - Review — dispatch a fresh subagent for spec-compliance + code-quality two-stage review per
superpowers:subagent-driven-development. Critical findings block progress. - Open PR —
gh pr create --base <base-of-this-PR> --head <branch>with single-concern description that cites the plan doc. - Wait for CI — poll until green. Auto-rebase on conflicts (max 2 attempts; halt on third).
- Address review —
superpowers:receiving-code-reviewto walk reviewer comments. Critical findings produce a fix commit; non-critical are logged on the PR. - Merge when green and approved — never bypass branch protection. If branch protection blocks, post a status comment and continue with the next independent PR.
- Deploy receipt — when the merged branch is on an auto-deploy target, run
deploy-receiptto verify deployed SHA matches merge SHA + healthcheck 200 before reporting the PR as done.
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 · 82 lines · 60 tokens per session scan A 160f391be452
release-train is a command published in the GitHub repository naimkatiman/continuous-improvement (7 stars, last pushed 8d ago), licensed MIT. It adds 60 tokens to every session and 1,143 once invoked, about $0.0003 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 commands, from other repositories
workflow-changelog
Track Claude Code changelog and find what needs updating in this repo.
publish-core
Trigger the canonical publish pipelines in this repo.
ng-ship-review
Portable command prompt generated from skills/checking-release-readiness/SKILL.md. Edit the skill, then run python tools/ng.py gen-commands; do not edit this file by hand.
ship
Deliver completed work with validation and documentation.
publish
Publish a new release of Coral to PyPI. The user provides the version number as $ARGUMENTS (e.g. "2.2.0").
changelog
Automatic changelog generation. Produces a structured changelog from commit history.