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/eric-tramel/moraine/release-notesnpx skills add eric-tramel/moraine --skill release-notesgit clone --depth 1 https://github.com/eric-tramel/moraineWrote 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/eric-tramel/moraine/release-notes)<a href="https://agentmods.dev/skills/eric-tramel/moraine/release-notes"><img src="https://agentmods.dev/badge/skills/eric-tramel/moraine/release-notes.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.00110 | $0.02834 |
| Opus 5 | $0.00055 | $0.01417 |
| Sonnet 5 | $0.00022 | $0.00567 |
| Haiku 4.5 | $0.00011 | $0.00283 |
Grade A, and why
release-notes 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 4d 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.
- `moraine up` is running on the host (check `curl -sf http://127.0.0.1:8080/ How it starts
The opening of the file, as written. The whole thing — 276 lines — stays where its author put it; the contents beside it link to each section on GitHub.
release-notes
You are rewriting a GitHub release body in moraine's house format. The input
is a tag (e.g. v0.4.2); the output is an updated release body published via
gh release edit <tag> --notes-file <path>.
Your goal is usage-focused, not commit-focused. A reader skimming the release page should understand in 30 seconds: how do I install this, what new thing can I do with it, and am I supposed to do anything when I upgrade?
Usage
/release-notes v0.4.2 — rewrite the v0.4.2 release body.
If the tag doesn't exist on GitHub yet, stop and explain. Do not create a
release; the release is cut by .github/workflows/release-moraine.yml on tag
push.
Process
1. Gather context
# Current (auto-generated) body. It's usually duplicated 3-6× because the
# release matrix runs softprops/action-gh-release from each target job, each
# time with generate_release_notes: true. You will dedupe in step 3.
gh release view "$TAG" --json body -q .body > /tmp/release-body.current.md
# Previous release tag, for the compare link and upgrade section.
prev_tag="$(gh release list --limit 20 --json tagName,isDraft,isPrerelease -q \
'[.[] | select(.isDraft==false and .isPrerelease==false and .tagName!=env.TAG) | .tagName] | .[0]')"
# Full list of PRs merged since the previous tag, for context.
gh pr list --state merged --search "merged:>=<prev-tag-date>" --json number,title,url
# or simpler — trust the auto-generated list and just read it.
Also read:
scripts/build-python-wheels.py— keep the "Platform support" table in sync withTARGET_TO_WHEEL_PLATFORM.- Any PR body that introduces a user-visible feature (via
gh pr view <n> --json body -q .body). Prefer the PR's own summary over inventing one.
2. Decide the shape of this release
Before writing, classify the release:
- Landmark release — new install path, big UI change, or a breaking change. Deserves a full-body treatment with install section, screenshots, upgrade notes. v0.4.2 is the canonical example.
- Patch release — bug fixes only. Skip "🚀 Install", "🐧 Platform support", and "⬆️ Upgrading". The "🛠 Under the hood" section becomes the whole body. Still dedupe the auto-generated changelog.
- Minor release between the two — include "🆕 What's new" but drop sections that didn't change. Don't pad.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 4d ago First seen · 276 lines · 110 tokens per session scan A 1c1f1103c6bd
release-notes is a skill published in the GitHub repository eric-tramel/moraine (116 stars, last pushed 17d ago), licensed Apache-2.0. It adds 110 tokens to every session and 2,834 once invoked, about $0.0006 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
vector-hybrid-search
Retrieve knowledge from a vector-store collection via the vector-mcp MCP server's vectorsearch tool — semantic (ANN) search, lexical BM25 search, or a hybrid of the two fused with Reciprocal Rank Fusion. Use when the agent must answer a question from an indexed corpus, pull top-k relevant chunks for RAG context, or…
smart-search
Use this for hybrid Vector+BM25 search to find specific existing info in the knowledge base—use only for factual, pre-existing content (skip guidance on creating/structuring docs, formatting, external queries, or search method questions).
knowledge-base
Ingest documents (URLs, local files, PDFs) into a searchable local knowledge base and query stored knowledge. Use when ingesting or storing documents, searching previously stored knowledge, or building research context.
release
Cut a Symphony release by bumping the committed version, landing it, tagging the merged commit, and verifying the Burrito release workflow. Use when asked to release, tag, or retag Symphony.
changelog-entry
Add a new entry to CHANGELOG.yml under the current unreleased version (or create the version block if needed), then regenerate documentation. Use when the user says things like "add a changelog entry", "log this fix in the changelog", or "/changelog-entry".
snapshot-release
Drives the snapshot-release flow for the current branch's PR. Posts a /snapshot comment on the PR if one isn't already there (with confirmation), waits for the Continuous Releases workflow to finish, and reports the tarball URLs from the resulting 📦 Snapshot Release comment. Use for both triggering and waiting …