Agent skill

Moraine Release Notes

by eric-tramel in eric-tramel/moraine

Rewrites a moraine GitHub release body into a usage-focused format with install block, what's new, platform table, upgrade notes and one deduplicated changelog.

Apache-2.0Auto-check passedDevelopment

Install Moraine Release Notes

skills CLI
$ npx skills add eric-tramel/moraine --skill release-notes -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install eric-tramel/moraine release-notes --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/eric-tramel/moraine.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/release-notes .claude/skills/release-notes && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
release-notes
GitHub stars
117
Token cost
~2.7k tokens
SKILL.md length
778 words
Files
2 (incl. scripts)
Skills in repo
19
Repo updated
First seen
Licence
Apache-2.0

At a glance

Rewrites a moraine GitHub release body into a usage-focused format with install block, what's new, platform table, upgrade notes and one deduplicated changelog.

  • Works in 5 steps: Gather context → Decide the shape of this release → Dedupe the changelog → …
  • Preparing the GitHub release page for a freshly tagged moraine version
  • SKILL.md covers Usage, Process, 🆕 What's new and 🛠 Under the hood, plus 4 more sections
  • Runs JavaScript scripts from its folder; calls gh, uv and bun

What it does

You run it as /release-notes with a tag such as v0.4.2. The agent reads the current auto-generated body, which repeats its changelog several times because each release matrix job appends one, collects PR summaries for user-visible features, and publishes the rewrite with gh release edit and a notes file. If the tag is not on GitHub yet, it stops and explains rather than creating a release.

It first classifies the release. A landmark release gets the full body with install, screenshots and upgrade notes, a patch release keeps only the under-the-hood section, and a minor one drops sections that did not change. The platform support table must match the wheel platform mapping in scripts/build-python-wheels.py, and exactly one changelog block is kept at the bottom. The folder also holds scripts/shoot-monitor.mjs. The model does not invoke this skill on its own.

When your agent uses it

  • Preparing the GitHub release page for a freshly tagged moraine version
  • Cleaning up an auto-generated release body that repeats its changelog
  • Deciding which sections a patch release and a landmark release each need

Example prompts

  • “/release-notes v0.4.2”
  • “Polish the v0.4.2 release notes and dedupe the changelog.”
  • “Prepare release notes for the new tag and keep the platform table current.”

Requirements

  • GitHub CLI (`gh`) authenticated for the moraine repository
  • The release tag already pushed to GitHub

Workflow steps

5 steps, taken from the step headings in SKILL.md.

  1. Gather context
  2. Decide the shape of this release
  3. Dedupe the changelog
  4. Write the new sections
  5. Publish

What it can do on your machine

Read from SKILL.md and the folder at commit 2fb4aec. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Ships 1 file in scripts/ (JavaScript), which the agent can run.

    Shell commands in SKILL.md call:

    • gh
    • uv
    • bun
    • node

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use gh and uv, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Moraine Release Notes loads about 2.7k tokens when it runs. Until then it costs about 111 tokens; SKILL.md has 778 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~111
When it runs · the whole SKILL.md, loaded when a task matches
~2.7k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); the scripts in this folder are not scanned.

SKILL.md

The full file from eric-tramel/moraine at commit 2fb4aec, republished under its Apache-2.0 licence (© eric-tramel). 778 words, ~2,689 tokens.

Download SKILL.mdSave it as .claude/skills/release-notes/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.
name
release-notes
description
Rewrite a moraine GitHub release body in the house format — one-sentence pitch, install block, usage-focused "what's new" sections with PR links and optional screenshots, a platform-support table, upgrade notes, and a single deduped auto-generated changelog at the bottom. Use when the user says "/release-notes v0.4.2", "polish the v0.4.2 release notes", or asks to prepare release notes for a tag. NOT auto-invoked by the model.
disable-model-invocation
true

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
bash
# 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 with TARGET_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.

Don't force a section that has nothing to say.

3. Dedupe the changelog

Every matrix job appended its own ## What's Changed ... **Full Changelog** block. Keep exactly one. The simplest path: open the current body in an editor, delete all but the first block, move it to the bottom under a ## Changelog heading.

Check the dedupe with:

bash
grep -c '^## What.s Changed' /tmp/release-body.current.md   # should be 1 after dedupe
grep -c 'Full Changelog'     /tmp/release-body.current.md   # should be 1
4. Write the new sections

Template (copy/paste, then fill in):

markdown
# moraine <TAG>

<one-sentence pitch — what is the headline story of this release?>

## 🚀 Install

```bash
uv tool install moraine-cli
moraine up

<one short paragraph expanding on the install command, plus the upgrade recipe for existing users if relevant>

🆕 What's new

<feature title> (#<PR>)

<2-4 sentences describing the user-visible outcome, in usage-first language. Start with what a user does or sees, not with what you changed.>

<optional: side-by-side screenshot table; see "Screenshots" below>

<repeat per major feature; 2-4 subsections is ideal, 5+ feels padded>

🛠 Under the hood

  • #<PR> — one line, user-facing angle if any
  • ...

🐧 Platform support

PlatformWheelNotes
Linux x86_64manylinux_2_28_x86_64glibc 2.28+ (Debian 12+, Ubuntu 20.04+, RHEL 9+, AL2023)
Linux aarch64manylinux_2_28_aarch64same floor
macOS Apple Siliconmacosx_11_0_arm64macOS 11.0+
macOS Intel—not published; use scripts/install.sh
Windows—not supported yet

(Pull the tags from scripts/build-python-wheels.py::TARGET_TO_WHEEL_PLATFORM. If the platform table hasn't changed since last release, skip this section.)

⬆️ Upgrading from <prev-tag>

bash
moraine down
uv tool upgrade moraine-cli   # or: uv tool install --reinstall moraine-cli
moraine up && moraine status

<only include this section if there's something the user has to do. If it's just a bug-fix release, skip it.>


Show full SKILL.md (333 more words)Show less

Changelog

<the single deduped auto-generated list from step 3 goes here>

Full Changelog: https://github.com/eric-tramel/moraine/compare/<prev-tag>...<TAG>


### 5. Tone + style rules

- **Usage-first sentences.** "You can now see tool-call latencies in the
  monitor" → good. "Adds a new flamegraph component" → bad.
- **Link every PR** the first time you mention a feature: `([#247](url))`.
- **No hedging.** Drop "essentially", "basically", "just". Say what it does.
- **Quote sparingly.** Never copy more than a few lines from a PR body
  verbatim; always rewrite for the release audience.
- **Emojis anchor the major sections only** (🚀 🆕 🛠 🐧 ⬆️). Don't sprinkle
  them through prose.
- **Call out breaking changes in the section they happen in**, with the
  word "removed" or "requires" — not buried in the changelog.
- **Honest platform support.** If Windows isn't supported, the table says
  "not supported yet", not "coming soon".
- **Don't promise canary-week timing.** The runbook in
  `docs/operations/pypi-release.md` covers that; the release notes are for
  the release itself.

### 6. Screenshots (optional, for UX-impacting releases)

Skip this section for patch releases. Include for any release where the
monitor UI visibly changed or install/CLI flows have a step the user can
see. Screenshots are especially worth the effort for the "landmark release"
class above.

**Preconditions:**

- `moraine up` is running on the host (check `curl -sf http://127.0.0.1:8080/
  >/dev/null && echo OK`). If not, stop and ask the user to start it.
- `web/monitor/node_modules/playwright` exists (part of the repo's dev
  install). If not, run `cd web/monitor && bun install --frozen-lockfile`.

**Capture:**

```bash
node .claude/skills/release-notes/scripts/shoot-monitor.mjs \
    "<session title substring>" /tmp/moraine-shots

The script drives headless chromium, waits for the Live Analytics charts + sessions list to render, clicks the first session card whose visible title contains <session title substring> (case-insensitive), and writes three PNGs:

  • 01-sessions-landing.png — the Sessions surface with Live Analytics
  • 02-session-detail.png — transcript pane for the clicked session
  • 03-session-flamegraph.png — flamegraph tab for the same session

Light theme is Playwright's default; use it (it reads better in release notes than dark chrome against the session rows).

Sensitivity review — mandatory before uploading:

  1. Read every visible session title in 01-sessions-landing.png. Session titles are the first user prompt of that session, verbatim. They often mention internal project names, ticket numbers, or colleague names.
  2. For 02-session-detail.png and 03-session-flamegraph.png, look for:
    • Absolute file paths containing /Users/<name>/ — reveals username + dir layout
    • Internal project names or acronyms in user prompts or tool args
    • Third-party ticket IDs (Jira, Linear, etc.)
    • Copy/pasted secrets (tokens, keys) in tool-call args — rare but possible
  3. Show the user the screenshots and flag specific concerns before uploading. The user decides whether to ship them, crop them, or pick a different session. Don't self-approve.

Pick a session whose content is already public (referenced by number in a public GitHub issue/PR, or directly about moraine's open-source development). Sessions about unrelated work are tempting because they're visually busy, but they're usually riskier.

Upload + embed:

bash
# Rename for a stable, human-legible asset name on the release page.
cp /tmp/moraine-shots/02-session-detail.png \
   /tmp/moraine-shots/moraine-monitor-sessions-transcript.png
cp /tmp/moraine-shots/03-session-flamegraph.png \
   /tmp/moraine-shots/moraine-monitor-sessions-flamegraph.png

gh release upload "$TAG" \
  /tmp/moraine-shots/moraine-monitor-sessions-transcript.png \
  /tmp/moraine-shots/moraine-monitor-sessions-flamegraph.png \
  --clobber

Embed side-by-side inside the relevant ### <feature> section of the body. Tables render cleaner than raw HTML in GitHub markdown and each image can link to its own full-size asset for click-to-zoom:

markdown
| Transcript view | Flamegraph view |
|---|---|
| [![Session transcript](https://github.com/eric-tramel/moraine/releases/download/<TAG>/moraine-monitor-sessions-transcript.png)](https://github.com/eric-tramel/moraine/releases/download/<TAG>/moraine-monitor-sessions-transcript.png) | [![Session flamegraph](https://github.com/eric-tramel/moraine/releases/download/<TAG>/moraine-monitor-sessions-flamegraph.png)](https://github.com/eric-tramel/moraine/releases/download/<TAG>/moraine-monitor-sessions-flamegraph.png) |

Release-asset URLs are stable — they won't rot when you clean up issue attachments. They render inline because GitHub serves them with the right Content-Type.

7. Publish
bash
gh release edit "$TAG" --notes-file /tmp/release-body.new.md

Then verify:

bash
# Count should drop to 1 of each
gh release view "$TAG" --json body -q .body | grep -c '^## What.s Changed'
gh release view "$TAG" --json body -q .body | grep -c 'Full Changelog'

# Total body length should be ~5-8k (v0.4.2 settled at 7.1k). If it's
# over 10k, you probably didn't dedupe; under 2k, you probably skipped
# sections the release needed.
gh release view "$TAG" --json body -q .body | wc -c

Show the user the final URL (https://github.com/eric-tramel/moraine/releases/tag/<TAG>) and the body length. They'll spot-check.

Reference: the v0.4.2 release

Use https://github.com/eric-tramel/moraine/releases/tag/v0.4.2 as the canonical example of this format. It was cut with this skill's predecessor workflow and is the specimen the format was distilled from.

© eric-tramel, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 1 other file (scripts) in .claude/skills/release-notes of eric-tramel/moraine.

  • SKILL.md
  • scripts/shoot-monitor.mjs

Open the folder on GitHubat commit 2fb4aec

Compare with similar skills

Moraine Release Notes next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Moraine Release Notes compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Moraine Release Notes this skilleric-tramel/moraine117—~2.7kAutomated safety check: PassApache-2.0
Tabler Release Notes Introtabler/tabler42k—~1.8kAutomated safety check: PassMIT
CicdRussellSB/pytrendy106—~1.6kAutomated safety check: PassMIT
Mole Release Notes Publishertw93/Mole69k—~1.9kAutomated safety check: PassGPL-3.0
RStudio What's New Pagerstudio/rstudio5.1k—~2kAutomated safety check: PassCustom licence
Release Feature Scoringdotnet/core22k—~2.2kAutomated safety check: PassMIT

Similar skills

  • Writes the hand-written intro for a Tabler GitHub release, built from changesets, docs pages and upgrade guides in a fixed layout with a picture per headline feature.

    42k GitHub stars~1.8k tokensUpdated today
    DevelopmentAuto-check passed
  • Cicd

    RussellSB/pytrendy

    A skill your agent uses when touching .github/workflows/, release config (.releaserc), mkdocs.yml, docs deploy, or the whats-new generator.

    106 GitHub stars~1.6k tokensUpdated yesterday
    DevelopmentAuto-check passed
  • Publishes curated, bilingual release notes for an existing Mole version tag with gh release edit, including contributor thanks and reactions, after the release workflow finishes.

    69k GitHub stars~1.9k tokensUpdated today
    DevelopmentAuto-check passed
  • Turns the current release's NEWS.md entries into the RStudio Desktop What's New page, picking only what Desktop users care about, then commits and opens a PR.

    5.1k GitHub stars~2k tokensUpdated today
    DevelopmentAuto-check passed
  • Official

    Ranks the changes in a release manifest and writes a scored features file that release notes, docs and blog posts can each cut at their own threshold.

    22k GitHub stars~2.2k tokensUpdated yesterday
    DevelopmentAuto-check passed
  • Official

    Writes customer-facing release notes for Azure App Configuration libraries and providers in a fixed file layout, version heading and category structure.

    263 GitHub stars~3.1k tokensUpdated 2 days ago
    DevelopmentAuto-check passed

More from eric-tramel/moraine

All 19 skills in this repo
  • Moraine Release Publisher

    eric-tramel/moraine

    Cuts and publishes a Moraine release end to end: version bump PR, tag, GitHub release notes, workflow check and PyPI package verification.

    117 GitHub stars~2.5k tokensUpdated 2 days ago
    Auto-check passed
  • Multi-Persona Code Review

    eric-tramel/moraine

    Coordinates a delegated review of a Moraine PR or local change by seven focused reviewer subagents, merges their findings and follows up on the fixes.

    117 GitHub stars~1.3k tokensUpdated 2 days ago
    Auto-check passed
  • Elegance-Focused Code Review

    eric-tramel/moraine

    Looks at a pull request for the smallest good design, hunting for simplifications and architectural moves that remove whole classes of problems.

    117 GitHub stars~473 tokensUpdated 2 days ago
    Auto-check passed
  • Idiomatic Code Review

    eric-tramel/moraine

    Reviews a pull request for idiomatic implementation: use of the language, standard library, ecosystem conventions and the repository's own patterns.

    117 GitHub stars~469 tokensUpdated 2 days ago
    Auto-check passed
  • Code Review Security Review

    eric-tramel/moraine

    Review a PR through the CodeReviewSecurityReview persona. An agent skill from eric-tramel/moraine.

    117 GitHub stars~497 tokensUpdated 2 days ago
    Auto-check passed
  • Crystallize

    eric-tramel/moraine

    Turn a rough feature, bug, refactor, architecture, documentation, or operations idea into a ready-to-implement local plan file.

    117 GitHub stars~1.6k tokensUpdated 2 days ago
    Auto-check passed

Works with

Questions about Moraine Release Notes

What does Moraine Release Notes do?

Rewrites a moraine GitHub release body into a usage-focused format with install block, what's new, platform table, upgrade notes and one deduplicated changelog. 2. The agent reads the current auto-generated body, which repeats its changelog several times because each release matrix job appends one, collects PR summaries for user-visible features, and publishes the rewrite with gh release edit and a notes file.

When should I use Moraine Release Notes?

Moraine Release Notes fits situations like: preparing the GitHub release page for a freshly tagged moraine version; cleaning up an auto-generated release body that repeats its changelog; deciding which sections a patch release and a landmark release each need.

How do I install Moraine Release Notes in Claude Code?

Run `npx skills add eric-tramel/moraine --skill release-notes -a claude-code`. Or copy the skill folder (.claude/skills/release-notes in eric-tramel/moraine) into .claude/skills/release-notes in your project. Claude Code loads it when a task matches its description.

How do I install Moraine Release Notes in Codex?

Run `npx skills add eric-tramel/moraine --skill release-notes -a codex`. Or copy the skill folder (.claude/skills/release-notes in eric-tramel/moraine) into .agents/skills/release-notes in your project. Codex loads it when a task matches its description.

Can I use Moraine Release Notes in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add eric-tramel/moraine --skill release-notes -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/release-notes, .gemini/skills/release-notes, .github/skills/release-notes and .opencode/skills/release-notes in your project.

What does Moraine Release Notes need to run?

Going by SKILL.md and its folder, Moraine Release Notes needs JavaScript for the scripts in its folder and the command-line tools its instructions call (gh, uv, bun and node). Our summary lists: GitHub CLI (`gh`) authenticated for the moraine repository; The release tag already pushed to GitHub.

Does Moraine Release Notes access the network?

SKILL.md contains no URLs. Its commands use gh and uv, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Moraine Release Notes safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. The check reads SKILL.md only: the scripts in the folder are not scanned, so read them before running anything.

What licence does Moraine Release Notes use?

Moraine Release Notes is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Moraine Release Notes use?

About 2.7k tokens (SKILL.md is roughly 11k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Moraine Release Notes?

Skills that share tags, products or a category with Moraine Release Notes: Tabler Release Notes Intro (tabler/tabler, 42k stars), Cicd (RussellSB/pytrendy, 106 stars), Mole Release Notes Publisher (tw93/Mole, 69k stars) and RStudio What's New Page (rstudio/rstudio, 5.1k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Moraine Release Notes?

eric-tramel (a GitHub user) maintains it in eric-tramel/moraine, which has 117 GitHub stars. The repository holds 19 skills in this directory. The repository was last updated on October 5, 2026.

Source: eric-tramel/moraine on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.