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 skills add Houseofmvps/ultraship --skill releasegit clone --depth 1 https://github.com/Houseofmvps/ultrashipWrote 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/houseofmvps/ultraship/release)<a href="https://agentmods.dev/skills/houseofmvps/ultraship/release"><img src="https://agentmods.dev/badge/skills/houseofmvps/ultraship/release/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/skills/houseofmvps/ultraship/release"><img src="https://agentmods.dev/badge/skills/houseofmvps/ultraship/release.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
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.00035 | $0.00780 |
| Opus 5 | $0.00017 | $0.00390 |
| Sonnet 5 | $0.00007 | $0.00156 |
| Haiku 4.5 | $0.00003 | $0.00078 |
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 6d 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 — 116 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Release
Full release pipeline: changelog → version bump → commit → tag → GitHub release → npm publish.
Process
Step 1: Determine Version Bump
Check recent commits since last tag to determine semver bump:
git describe --tags --abbrev=0 2>/dev/null || echo "none"
git log $(git describe --tags --abbrev=0 2>/dev/null || git rev-list --max-parents=0 HEAD)..HEAD --oneline
Analyze commit messages:
- Any
BREAKING CHANGE:or!:→ major bump - Any
feat:→ minor bump - Only
fix:,chore:,docs:,refactor:→ patch bump
If the user specifies a version (e.g., "release 2.0.0"), use that instead.
Step 2: Generate Changelog
Group commits by type:
## What's New
- feat: Add deploy command with pre-flight checks
- feat: Add content scoring with readability analysis
## Bug Fixes
- fix: Secret scanner false positive on .env.example
## Other Changes
- chore: Update dependencies
- refactor: Restructure SEO scanner for cross-page analysis
Step 3: Version Bump
Update version in:
package.json— theversionfield- Any other version references the project uses
# Read current version
node -e "console.log(JSON.parse(require('fs').readFileSync('package.json','utf8')).version)"
Use the Edit tool to update the version string.
Step 4: Commit & Tag
git add package.json CHANGELOG.md
git commit -m "release: v<new-version>"
git tag -a v<new-version> -m "v<new-version>"
Step 5: Push
git push origin main --tags
Step 6: GitHub Release
gh release create v<new-version> --title "v<new-version>" --notes "<changelog>"
Use the changelog from Step 2 as release notes.
Step 7: npm Publish (if applicable)
Only if package.json exists and has a name field (and is not private):
npm publish
If publish fails due to auth, show the user how to set up their npm token.
Step 8: Post-Release Summary
====================================
RELEASE COMPLETE
====================================
Package: ultraship
Version: 1.0.7
Tag: v1.0.7
Commits: 12 since last release
GitHub: https://github.com/Houseofmvps/ultraship/releases/tag/v1.0.7
npm: https://www.npmjs.com/package/ultraship
====================================
Changelog:
- 3 new features
- 2 bug fixes
- 1 breaking change
====================================
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.
- 6d ago First seen · 116 lines · 35 tokens per session scan A 69cc8d1e7e33
release is a skill published in the GitHub repository Houseofmvps/ultraship (121 stars, last pushed 2mo ago), licensed MIT. It adds 35 tokens to every session and 780 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-09-03.
Other skills, from other repositories
version-bump
This skill automates version bumping during the release process for the Claude Code Handbook monorepo. It should be used when the user requests to bump versions, prepare a release, or increment version numbers across the repository.
git-branchless
Use when asked for multi-commit stack edits, rebases, fixups, or stacked-PR publishing with branchless git idioms. Not for plain-git workflows in repos without branchless.
atomic-issues-prs
Use when the user says "atomic PRs" or requests one issue or PR per logical change. Don't use for single-change pushes or uncommitted change-sets.
git-workflow-and-versioning
Use when the user asks for release, version bump, changelog, or branch workflow beyond a single commit. Don't use for single commits or for publishing to a package registry.
post-merge-cleanup
Use when a landed merge, release, or completed change needs its cleanup surface reconciled. Scans for stale TODOs, deprecations, unused flags, and doc gaps. Not for unrelated refactoring.
lockstep-version-guard
Use when a human invokes the release gate to prove all 28 ODIN plugins share one canonical version. Emits a per-file comparison and exits non-zero on mismatch. Don't use to edit release metadata or for remote, credential, publish, deploy, or irreversible changes.