Borrowing it
Nothing to install: this file belongs to hhopke/intervals-icu-mcp. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/hhopke/intervals-icu-mcp/main/.claude/skills/release-check/SKILL.mdgit clone --depth 1 https://github.com/hhopke/intervals-icu-mcpWrote 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/hhopke/intervals-icu-mcp/release-check)<a href="https://agentmods.dev/skills/hhopke/intervals-icu-mcp/release-check"><img src="https://agentmods.dev/badge/skills/hhopke/intervals-icu-mcp/release-check/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/hhopke/intervals-icu-mcp/release-check"><img src="https://agentmods.dev/badge/skills/hhopke/intervals-icu-mcp/release-check.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.00041 | $0.00573 |
| Opus 5 | $0.00020 | $0.00287 |
| Sonnet 5 | $0.00008 | $0.00115 |
| Haiku 4.5 | $0.00004 | $0.00057 |
Grade A, and why
release-check 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 11d 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
Instructions
-
Run the full pre-release check:
make can-release -
Check CHANGELOG coverage — CHANGELOG.md is manual, and community PRs deliberately don't include entries (the maintainer adds them at merge), so this is the last line of defense before a release is cut. List everything merged since the last tag and compare against the
[Unreleased]section:git describe --tags --abbrev=0 git log --oneline --no-merges vX.Y.Z..HEAD awk '/^## \[Unreleased\]/{flag=1; next} /^## \[/{flag=0} flag' CHANGELOG.mdEvery user-facing change (feat, fix, breaking change — including merged community PRs) must have a bullet under
## [Unreleased]. Internal-only commits (ci, chore, docs about the repo itself, release/publish plumbing) don't need entries. PRs are squash-merged, so eachmaincommit maps 1:1 to a PR via its(#N)suffix. For each user-facing commit with no matching bullet, report it as a failure and draft a suggested entry (source it from the PR description viagh pr view N, taking N from the commit subject's suffix). -
Parse the output and report a clear summary:
If everything passes:
✅ Release check passed. All tests, linting (ruff + pyright), and formatting checks are green, and every user-facing change since the last tag has a CHANGELOG entry.
If something fails:
❌ Release check failed.
List each failing check with:
- What failed (test name, lint rule, file, or missing CHANGELOG entry)
- A brief explanation of the issue
- A suggested fix
-
If tests fail, offer to run the specific failing test in verbose mode:
make test/verbose -
If lint fails, offer to auto-fix:
make format
What make can-release checks
make lint— ruff check + pyright type checkingmake test— full pytest suite- Code formatting compliance
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.
- 11d ago First seen · 62 lines · 41 tokens per session scan A d31ba14e4299
release-check is a skill published in the GitHub repository hhopke/intervals-icu-mcp (64 stars, last pushed today), licensed MIT. It adds 41 tokens to every session and 573 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-30.
Other skills, from other repositories
mem0-test-integration
Verify a Mem0 integration produced by /mem0-integrate. Runs in the same workspace on the same branch (loose coupling) — installs dependencies, runs the repo's native test suite, then exercises a real end-to-end smoke flow against the user's API key. Produces a scorecard. TRIGGER when: user has just run /mem0-integrate…
mem0-integrate
Integrate Mem0 into an existing repository using a goal-driven, TDD pipeline. Detects the repo's language automatically and asks the user to pick between Mem0 Platform (managed) and Mem0 Open Source (self-hosted). Writes failing tests before any implementation. Produces a local feature branch plus .mem0-integration/…
pi-package-sandbox-test
Use when verifying that published Pi packages install and load for normal users, including pi.dev package compatibility checks, release validation, Daytona sandbox tests, and package installability audits.
prep-repo
Use when the user wants to prepare a local project for GitHub or public release. Runs a release-readiness sweep over README structure, bilingual docs, commit hygiene, sensitive-data exposure, broken links, markdown rendering, project layout, tests, CI, Docker, and final cleanup. Fixes issues only inside the target…
pre-release-check
The final gate before a release is cut — go green, reconcile the release PR against what actually landed, sweep what CI can't see, check the roadmap and ADR statuses, optionally deep-review, then return a ship-or-hold verdict.
ship
Ship phase. Runs isolated integration test in a fresh worktree, creates a PR with full spec + audit report in the body, watches CI, and auto-fixes failures.