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/hhopke/intervals-icu-mcp/commitnpx skills add hhopke/intervals-icu-mcp --skill commitgit 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/commit)<a href="https://agentmods.dev/skills/hhopke/intervals-icu-mcp/commit"><img src="https://agentmods.dev/badge/skills/hhopke/intervals-icu-mcp/commit.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.00046 | $0.01639 |
| Opus 5 | $0.00023 | $0.00820 |
| Sonnet 5 | $0.00009 | $0.00328 |
| Haiku 4.5 | $0.00005 | $0.00164 |
Grade A, and why
commit 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 5d 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 — 90 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Context
Gather the following before composing the commit message:
- Current branch:
git branch --show-current - Working tree status:
git status --short --branch - Diff (staged + unstaged):
git diff $(git rev-parse --verify HEAD 2>/dev/null || echo --cached) - Recent history:
git log --oneline -10
Branch guard — MANDATORY first step
Never commit on main. Before staging or committing:
- Run
git branch --show-current. - If the result is
main:- Propose a branch name derived from the commit type/scope (e.g.
fix/hr-histogram-list-shape,feat/event-tags). - Confirm the name with the user, then
git switch -c <branch>. - Only then proceed to stage + commit.
- Propose a branch name derived from the commit type/scope (e.g.
- If on any other branch, commit there as-is — do not create a new branch.
No exceptions: trivial fixes, doc tweaks, one-liners — all go through a non-main branch.
Commit message rules
- Single line. No body. No
Co-Authored-By/ Claude attribution. This applies to every commit in this repo, regardless of size. - Format:
type(scope): description— Conventional Commits. - Types:
feat,fix,docs,style,refactor,test,chore,ci,build,perf. - Scope is optional but encouraged. Conventional scopes here:
tools,client,middleware,models,wellness,events,ci,release, or a specific tool module name. - Do not put issue refs (
Closes #N) in the commit message — those live in the PR body so GitHub auto-closes correctly on merge (and squash merges use a blank commit body, so commit-message refs would be dropped anyway).
Doc + count sync
For feat, fix, or anything user-visible, check whether docs need updating in the same commit:
CHANGELOG.md— add a bullet under## [Unreleased]. CHANGELOG is manual in this repo; nothing generates it. Group bullets under### Added/### Changed/### Fixedmatching the existing style.- Tool / resource / prompt counts — if tools were added or removed, update the counts that appear in:
README.md(header/intro line and any tool tables)CLAUDE.md(project overview line stating tool counts)docs/tools.mdif the registered set changed
- README discipline — keep
README.mdunder 300 lines. If a new section would push past ~30 lines and isn't core onboarding, extract it todocs/and link from the README. - SemVer flag — if the change removes or renames a tool/parameter, changes config env var semantics, changes default tool registration (e.g.
INTERVALS_ICU_DELETE_MODE), or removes information from a response, call it out in the PR body — this requires a major version bump per CLAUDE.md. Response-shape changes that preserve the information (key renames, restructuring, added fields) are minor, not breaking. - Do not reference upstream/comparison repos in commit messages, PR bodies, CHANGELOG, or README.
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.
- 5d ago First seen · 90 lines · 46 tokens per session scan A 8413e0fe2610
commit is a skill published in the GitHub repository hhopke/intervals-icu-mcp (59 stars, last pushed 5d ago), licensed MIT. It adds 46 tokens to every session and 1,639 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
commit-push
Commit and push the changes made on this chat session to the current branch. Use best practices from Conventional Commits.
commit
Commit the changes made on this chat session to the current branch. Use best practices from Conventional Commits.
conventional-commits
Enforces strict adherence to the Conventional Commits 1.0.0 specification for staging and saving changes. Use when a user asks to commit files, draft a git message, or finalize code tasks.
investigate-issue
Investigate a GitHub issue by fetching details, analyzing the codebase, researching documentation, and presenting an actionable implementation plan with test guidance. Use when asked to investigate, analyze, triage, or plan work for a GitHub issue. Invoked with /investigate-issue or /investigate-issue (prompts for ID).
resolve-pr-comments-stack
Resolve unresolved PR review comments across an entire Graphite (gt) stack of many PRs, bottom-up, in one working directory. Use when asked to "go through this stack and resolve comments", "clean up review comments across the whole stack", or given a list/range of PR numbers that form (or partially form) a gt stack.…
harness-test-writer
Add regression test cases to the Bifrost provider harness (the Postman collection run via make run-provider-harness-test) based on a merged PR or a GitHub issue. Fetches the PR/issue, traces the affected wire path in the codebase, checks existing harness coverage, designs cases following harness conventions, inserts…