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/hyperlogue/r3/releasenpx skills add hyperlogue/r3 --skill releasegit clone --depth 1 https://github.com/hyperlogue/r3What 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.00081 | $0.01931 |
| Opus 5 | $0.00041 | $0.00966 |
| Sonnet 5 | $0.00016 | $0.00386 |
| Haiku 4.5 | $0.00008 | $0.00193 |
Grade A, and why
release scanned grade A with 1 finding 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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
Release (curl / Homebrew) and publishes the npm launcher (`@hyperlogue/r3`) with How it starts
The opening of the file, as written. The whole thing — 141 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Releasing r3
A release is one version-bump commit plus an annotated tag on it. The whole job
is: write the changelog, move every version string to the new number
together, commit, tag that commit, and push. The release CI reads
CHANGELOG.md out of the tagged tree for the GitHub release notes, so the
changelog entry is the release's public face and the tag carries no notes of its
own.
The one rule: bump before you tag
The tag must point at the version-bump commit. Cutting the tag first and bumping afterward leaves the tag on a commit whose in-code version is still the previous release — this skill exists because that exact mistake happened once. Do the changelog and the version bump in the release commit, then tag that commit.
Version sources — all must read the same number
Three files hold the version. The release-build scripts
(scripts/release-binaries.ts, scripts/stage-npm-packages.ts) refuse to build
if they drift, so keep them in lockstep:
shared/version.ts—R3_VERSION(baked into the binary + CLI, reported by/api/health; the CLI warns on skew).package.json— top-level"version".npm/package.json—"version"and all fouroptionalDependenciespins:@hyperlogue/r3-darwin-arm64,-darwin-x64,-linux-x64,-linux-arm64. All four must equal the new version (the launcher resolves the matching per-platform binary at exactly its own version).
Steps
-
Pick the version (SemVer). Previous tag:
git describe --tags --abbrev=0. -
Draft the CHANGELOG entry (
CHANGELOG.md, [Keep a Changelog] format). Survey what shipped since the last tag —git log v<prev>..HEAD --oneline— then:- Insert a new
## [X.Y.Z] - YYYY-MM-DDsection directly under the intro block, above the previous version. Use the release date. - Group bullets under
### Added/### Changed/### Fixed/### Removed— only the groups that apply, in that order. - Write from the user's vantage point: what they can now do, or no longer
run into — not the internal mechanics, refactors, or scaffolding that got it
there. Frame each entry as what shipped, not what was turned off or reworked
mid-development; internal churn a user never observes doesn't belong in the
log at all. Match the existing voice: a bold lead-in (
**Feature.**) then a sentence or two on the change and why it matters; fold related commits into one bullet. - Add the compare link at the very bottom, with the others:
[X.Y.Z]: https://github.com/hyperlogue/r3/compare/v<prev>...vX.Y.Z
- Insert a new
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 · 141 lines · 81 tokens per session scan A 436e30480346
release is a skill published in the GitHub repository hyperlogue/r3 (23 stars, last pushed 7d ago), licensed MIT. It adds 81 tokens to every session and 1,931 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
source-command-update-infos-release
Update Codex releases tracking (guide + landing + version bump).
source-command-changelog
View recent CHANGELOG entries.
update-changelog
Updates a project changelog with entries for changes since the branch diverged from main. Use when about to open a PR, cutting a release, or when the user asks about changelog, release notes, or migration notes.
git-master
MUST USE for ANY git operations. Atomic commits, rebase/squash, cherry-pick, worktree, reflog recovery, and history search (blame, bisect, log -S). STRONGLY RECOMMENDED: Use with task(category='quick', loadskills=['git-master'], ...) to save context. Triggers: 'commit', 'rebase', 'squash', 'cherry-pick', 'worktree'…
docs-changelog
Generates and formats changelog files for a new release based on provided version and raw changelog data.
ship
Build, commit, push & version bump workflow - automates the complete release cycle.