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/jhlee111/ash_grant/releasegit clone --depth 1 https://github.com/jhlee111/ash_grantWrote 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/jhlee111/ash_grant/release)<a href="https://agentmods.dev/commands/jhlee111/ash_grant/release"><img src="https://agentmods.dev/badge/commands/jhlee111/ash_grant/release.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.00000 | $0.00871 |
| Opus 5 | $0.00000 | $0.00436 |
| Sonnet 5 | $0.00000 | $0.00174 |
| Haiku 4.5 | $0.00000 | $0.00087 |
Grade A, and why
release 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.
How it starts
The opening of the file, as written. The whole thing — 143 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Release
End-to-end release workflow: analyze changes, update docs + version, verify, PR, merge, tag. Run this on main after feature PRs are merged.
Input
$ARGUMENTS — version number (e.g., 0.11.0) or semver bump type (major, minor, patch).
If omitted, suggest version based on changes since last tag.
Steps
1. Pre-checks
git checkout main && git pull
Verify clean working tree (no uncommitted changes except PLAN.md, docs/).
2. Analyze changes since last release
# Find last version tag
git describe --tags --abbrev=0
# All commits since last tag
git log --oneline <last-tag>..HEAD
# All changed files since last tag
git diff --stat <last-tag>..HEAD
Categorize:
- Features (feat:)
- Fixes (fix:)
- Docs (docs:)
- Refactors (refactor:)
- Tests (test:)
Determine version bump if not specified:
- Breaking change → major
- New feature → minor
- Bug fix / docs only → patch
3. Documentation gate
Check ALL of these before creating release branch:
CHANGELOG.md:
- Add new version section with date
- List all changes categorized by Added/Changed/Fixed/Removed
- Move from commit messages, but write user-facing descriptions (not just commit text)
README.md:
- Installation version matches new release?
- Any new features from this release missing from README?
- Examples still accurate with current API?
- Feature list at top of README reflects new capabilities?
@moduledoc:
- New public modules have
@moduledoc? - Changed modules have accurate
@moduledoc?
CLAUDE.md:
- Architecture section reflects new modules?
- Any new commands, patterns, or test structures?
usage-rules.md:
- AI-agent-facing rulebook — audit as seriously as README.
- New DSL options / entities / recommended patterns since last release are surfaced as "DO:" rules?
- Deprecated or removed options are surfaced as "DON'T:" rules?
- Examples still reflect current API (e.g., post-deprecation they no longer demonstrate the deprecated path)?
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 · 143 lines · 0 tokens per session scan A 4ad0701653d8
release is a command published in the GitHub repository jhlee111/ash_grant (17 stars, last pushed 1mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 871 tokens. 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-01.
Other commands, from other repositories
changelog
Generate a new changelog entry by reading all changeset files and creating a properly formatted entry in .changelog/v3.mdx.
merge-and-status
Merge the current PR, pull main, surface any open contributor PRs and untriaged contributor issues, and show open milestone issues.
ship
Deliver the increment. Then go live with a rollback you have run.
update-changelog-and-tag
You are preparing a release. Follow these steps precisely.
release-tag
Create and push a version tag after a release PR has been merged.
release
Orchestrate a complete release workflow with quality gates, version bumping, and publishing automation.