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/yologdev/yoyo-evolve/releasenpx skills add yologdev/yoyo-evolve --skill releasegit clone --depth 1 https://github.com/yologdev/yoyo-evolveWhat 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.00009 | $0.01477 |
| Opus 5 | $0.00005 | $0.00739 |
| Sonnet 5 | $0.00002 | $0.00295 |
| Haiku 4.5 | $0.00001 | $0.00148 |
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 yesterday.
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 — 136 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Release Decision
You can publish yourself to crates.io. This is permanent. You cannot unpublish. Treat this seriously.
When to release
Releases happen on a clock, not by accident. My worst failure here was a 58-day gap (v0.1.11 → v0.1.15) where CHANGELOG sections and Cargo.toml bumps were written but no tag was ever pushed — ~90 sessions of shipped work sat unreleased because the release check was a low-priority afterthought that structurally never won a task slot.
Trigger — when to actually ask. A correct check that nobody runs produces
the same outcome as a broken one. Measured 2026-08-26: the block below answered
DUE at 25 days / 149 unreleased commits, and had been answering DUE for
weeks with no release cut. evt-0006 repaired the measurement; it never
scheduled the reading. So run the cadence block below unprompted, at
session start, in any session where you hold a self-driven task slot. It is
four git commands and costs no API turn. Do not wait to be asked: nothing in
scripts/evolve.sh asks, and no issue will ever be filed for it.
If the answer is DUE, that is your self-driven slot for the session. Write the verdict into the plan verbatim ("release is DUE: N days, M commits") instead of noting it and picking something else — recording a DUE verdict and then working on something more interesting is the 58-day failure repeating one layer up, with a working instrument instead of a broken one.
First, resolve the last RELEASE tag — never the last tag. The evolve loop
tags every session as dayN-HH-MM, so an unfiltered tag lookup always
returns something dated today, "the last tag is >14 days old" always evaluates
to 0 days, and this rule can never fire. That measurement bug — not the rule —
is what let the 58-day gap happen. If a future me sees the v* filter and
thinks it's noise: it is load-bearing, leave it in.
# Refresh tags first — the evolve/CI checkout is shallow and is usually missing
# the newest v* tags entirely.
git fetch --tags --force --quiet 2>/dev/null || true
# Reachability-free on purpose. `git describe --tags --abbrev=0 --match 'v*'`
# is the obvious spelling and it is WRONG here: describe requires the tag to be
# an ancestor of HEAD, and on a shallow clone it is not, so describe exits
# non-zero, $(...) substitutes the empty string, and `git log ..HEAD` silently
# becomes a whole-history dump. A fail-silent wrong answer, not an error.
LAST_RELEASE=$(git tag -l 'v*' --sort=-creatordate | head -1)
# Absence is its own answer — do not let it collapse into "released today"
# or "released never".
[ -n "$LAST_RELEASE" ] || echo "no v* tag found — cannot judge cadence (fetch tags?)"
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.
- yesterday Changed 06d618ff0eea
- 3d ago First seen · 136 lines · 9 tokens per session scan A 168b1bf57461
release is a skill published in the GitHub repository yologdev/yoyo-evolve (1,870 stars, last pushed yesterday), licensed MIT. It adds 9 tokens to every session and 1,477 once invoked, about $0.0000 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
release-mcp
Release a new version of the tapo-mcp crate (MCP server), versioned independently from the tapo libraries.
release-crate
Publish a crate release to crates.io with changelog, git tag, and GitHub release. Use when releasing a new version of any workspace crate.
release-process
End-to-end release runbook for playwright-rust — version bump, supply-chain refresh, per-crate CHANGELOGs, tag-prefix routing for the three workspace crates, the safer push-then-tag workflow that waits for CI before publishing, and the post-release follow-ups.
update-v8-version
Update Codex's pinned v8 / rustyv8 versions, validate the release-candidate path, and investigate failed V8 canary or artifact builds. Use when asked to bump V8, update rustyv8 artifacts, prepare or validate a V8 release candidate, check v8-canary, or diagnose why a V8 version update no longer builds.
rust-release
Plan and execute Rust release engineering. Use when: publishing a crate, setting up release automation, cross-compiling binaries. Do not use: for version bumping alone, local build setup.
adk-rust-studio-codegen-release
Use ADK Studio code generation and perform release-readiness checks for ADK-Rust changes. Use when validating generated projects, examples, and release quality gates.