agentleFS
yicheng47yicheng47/runner/.agents/skills/release/SKILL.md

release

Skill490 starsChanged 7 days agoMITView on GitHub

Cut a Runner production release — bump the workspace version, tag vX.Y.Z, let release.yml build the draft for macOS, Windows and Linux, write bilingual release notes (English, with 中文 collapsed in a details block), hand the publish switch to the user, and once the release is live write one Chinese plain-text post for the WeChat group and linux.do and sweep the shipped work's docs

  • Installs packages
  • Commits and pushes

196 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use create-agent-adapter, changelog-style and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • MicrosoftSkill

    create-agent-adapter

    Technical guide for creating a new Paperclip agent adapter. Use when building a new adapter package, adding support for a new AI coding tool (e.g. a new CLI agent, API-based agent, or custom process), or when modifying the adapter system. Covers the required interfaces, module structure, registration points, and conventions derived from the existing claude-local and codex-local adapters.

    Also in 5 projects that use this

  • GrinvSkill

    changelog-style

    Turn a commit range into CHANGELOG.md entries following common-changelog style. Use when finishing a PR or cutting a release, to write/fix the [Unreleased] section's entries — moving [Unreleased] under a new dated version heading is a separate, automated step (see the release skill / scripts/sync-version.ts), not this skill's job.

    Also in 4 projects that use this

  • GrinvSkill

    docs-consistency-check

    Check README/manifest.json/server.json/CHANGELOG.md/AGENTS.md and docs/*.md for drift against the actual registered tools and source. Use after adding, renaming, or removing a tool, or as part of a live-audit pass.

    Also in 4 projects that use this

  • Microsoft AzureSkill

    component-release

    Prepares a verifiable Agent Landing Zone UI release. Use for release branches, VERSION, changelog entries, tags, release notes, and compatibility evidence; never publish without explicit human approval.

    Also in 4 projects that use this

  • Microsoft AzureSkill

    documentation-consistency

    Keeps AI Landing Zone contributor, user, and operator documentation aligned with shipped Bicep behavior. Use for parameters, defaults, outputs, topology, deployment flow, operations, or releases.

    Also in 8 projects that use this

  • rivet-devSkill

    launch-graphics

    Generate agentOS marketing/launch graphics (launch & social heroes, code-snippet cards) from the committed generators in docs-internal/graphics. Use when asked to make, update, or render an agentOS launch image, social image, "agentOS Apps" graphic, or technical code-snippet image.

    Also in 3 projects that use this

  • +3 more from Grinv

The file

We split this skill into the rules it gives an agent

4 rules. 0 are common, 0 are distinctive, and 4 are very specific to this project.

  • 0

    Common

    Most of the 186 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    No release run is in flight: gh run list --workflow release.yml --limit 3 --json status.

    line 22
  2. Very specific:

    Notes: Follow notes <version> below and set them on the draft: gh release edit v<version> --notes-file <file>.

    line 26
  3. Very specific:

    Keep a blank line after <summary> and before </details>, or GitHub renders the markdown inside as literal text.

    line 82
  4. Very specific:

    Write it to /tmp/runner-v<version>-release-note.zh-CN.txt, print the same text in the reply inside a text fence, and give the file path.

    line 112

“Common” is measured: kept by at least 6 in 10 of the 186 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Release

A production release is a vX.Y.Z tag on a main commit whose workspace version is exactly X.Y.Z. release.yml builds the signed, notarized macOS DMG with its one-item Sparkle appcast and the Windows x64 installer with its minisign signature, plus Linux ARM64/x86_64 tar/deb packages, then attaches everything to a draft release. Publishing the draft is the user's switch: it moves releases/latest and the production Sparkle feed. Contract: docs/arch/arch.md §14; nightlies are a separate channel handled by the nightly skill.

An explicit request to run authorizes the bump commit, the push, the tag, and editing the draft's notes; after the user publishes, it also authorizes the sweep's docs commit and push. An explicit sweep request authorizes that commit and push on its own. Nothing in this skill publishes the draft, deletes a release, moves an existing tag, or posts to a forum or social media. Record only observed results.

Usage

/release [run <version> | notes <version> | post <version> | check <version> | sweep <version>] — no action means run.

run <version>

  1. Preflight — stop on any failure and report it.
    • <version> must match ^[0-9]+\.[0-9]+\.[0-9]+$ and be greater than the current tag from gh release list.
    • git fetch origin; require branch main, a clean tree, and git rev-parse main origin/main equal. Everything meant for the release is already merged.
    • CI on origin/main is green: gh run list --branch main --workflow ci.yaml --limit 1 --json conclusion.
    • No release run is in flight: gh run list --workflow release.yml --limit 3 --json status.
  2. Bump. Set version under [workspace.package] in the root Cargo.toml to <version>. Every crate inherits it with version.workspace = true (since #635), so there is no per-crate edit. Run cargo check --workspace to refresh Cargo.lock, which updates each crate's entry, then cargo test -p runner-app --test bundle_mac. Commit Cargo.toml and Cargo.lock as chore: bump version to <version> and push main.
  3. Tag. git tag -a v<version> -m "Runner <version>" && git push origin v<version>. The push starts release.yml.
  4. Watch. Find the run with gh run list --workflow release.yml --limit 1 --json databaseId,status,headSha and gh run watch <id> --exit-status. All platform build jobs (including both Linux matrix instances) and the publish job must succeed. On failure, gh run view <id> --log-failed, report the failing step, and stop; the tag stays, the draft may be partial.
  5. Notes. Follow notes <version> below and set them on the draft: gh release edit v<version> --notes-file <file>. Do not pass --draft=false.
  6. Report. The draft URL, every platform asset name, and the reminder that publishing is the user's action. A draft's untagged-… URL changes each time it is edited, so link the latest one. After the user publishes, confirm gh release view v<version> --json isDraft is false before anything that assumes the release is live, then verify gh api repos/yicheng47/runner/releases/latest --jq .tag_name is v<version> and that releases/latest/download/appcast.xml names the new DMG.
  7. Post. Once the release is live, follow post <version> below.
  8. Sweep. Then follow sweep <version> below.

notes <version>

Release notes are bilingual: the full English text first, then the same content in 中文 inside a <details> block so the page reads as English-only until a reader expands it (GitHub has no tabs; a collapsed block is the nearest thing, and the in-app updaters open the release page in a browser where it renders). 0.8.3 used a horizontal rule instead; every release since 0.8.4 ships the collapsed form. A draft with only the workflow's one-line stub is not ready to publish.

Source the content from git log v<previous>..v<version> --no-merges --format='- %s (%h)' and the closed issues those commits reference. Write for users, not for the repo: what changed for them, in their words, one bullet per change with the issue number at the end. Skip internal work (tests, CI, docs, refactors) unless it changes what users see.

Structure, both languages:

Runner <version> is a <bug-fix | feature> release for macOS, Windows and Linux on top of <previous>.

## New                      (omit if empty)
- **Short bold lead.** One or two sentences. (#123)

## Bug fixes                (omit if empty)
- ...

## Nightly channel          (only when the nightly channel changed; nightly users read these)
- ...

## Download and upgrade
- **macOS, Apple Silicon:** download `Runner-<version>-arm64.dmg`, or update through Sparkle. The app is signed and notarized.
- **Windows x64, Windows 10 version 1809 or later:** download `Runner-Setup-<version>.<stamp>-x64.exe`. The installer, app, and CLI sidecars are Authenticode-signed by Open Source Developer Yicheng Wang. You can also update through Settings → Updates → Update, then choose Install and restart. Settings, chats, and missions are retained.

- **Linux ARM64/x86_64:** use `Runner_<version>_linux-<arm64|x64>.tar.gz` or `.deb`; install/update through the same package installer. The opt-in user service is disabled on install, and uninstall retains user data. Each Linux package carries a matching minisign signature verified by the in-app updater.

Windows ARM64 and Intel Macs are not supported. Linux ARM64/x86_64 downloads use tar/deb packages; signed in-app updates support managed tar installations and system-authorized APT installation. State the actual build baseline and native validation gaps, and do not claim local artifacts have already been published.

**Full changelog:** https://github.com/yicheng47/runner/compare/v<previous>...v<version>

<details>
<summary>中文</summary>

Runner <version> 是 macOS、Windows 和 Linux 上基于 <previous> 的<修复版本 | 功能版本>。

## 新功能
...
## 问题修复
...
## Nightly 渠道
...
## 下载与升级
...

Windows ARM64 和 Intel Mac 暂不支持。Linux ARM64/x86_64 提供 tar/deb 包及对应 minisign 签名,支持应用内验证更新:用户 tar 安装原子替换,deb 包经授权由 APT 安装;说明实际构建基线与原生验证缺口,不把本地包写成已发布。

**完整变更记录:** https://github.com/yicheng47/runner/compare/v<previous>...v<version>

</details>

Keep a blank line after <summary> and before </details>, or GitHub renders the markdown inside as literal text.

Rules for the 中文 half: translate the meaning, not the words; keep product terms as they appear in the app (Runner, Sparkle, Nightly, ⌘, Settings → Updates); keep file names, issue numbers, and links identical to the English; use the same headings in the same order so a reader can line the two halves up. Headings inside the details block use ## like the English half; they render collapsed until expanded. Read the exact Windows installer name from the draft's assets (gh release view v<version> --json assets --jq '.assets[].name') rather than guessing the stamp.

post <version>

One Chinese plain-text release post for the user to paste into Runner's WeChat user group and its linux.do thread (Jason, 2026-11-05: one post for both, no separate markdown version). It needs the published release (gh release view v<version> --json isDraft is false), because linux.do turns the release link into a preview card only for a public page. Build it from the published body's 中文 half (gh release view v<version> --json body), not from the git log, so the post agrees with the release page:

【Runner <version> 发布】
macOS / Windows / Linux 均已上线,应用内 Settings → Updates 即可更新,设置、聊天和 mission 都会保留。

✨ 新功能
1. 终端设置重新分组,新增行高、光标闪烁、回滚行数、选中即复制四项设置
2. ……

🛠 问题修复
1. Windows / Linux:Ctrl+D、Ctrl+K、Ctrl+S、Ctrl+M 在终端里不再被 Runner 占用……
2. ……

完整更新说明:
https://github.com/yicheng47/runner/releases/tag/v<version>

有问题欢迎在群里反馈 🙏
  • Plain text only: WeChat renders no markdown, so no # headings, **bold** or [links](…). Number the items under the ✨ 新功能 and 🛠 问题修复 lines; omit a section that is empty.
  • Shorten each 中文 bullet to one line in plain words, keeping product terms as the app shows them and dropping issue numbers. Keep the changes users notice; drop internal ones and minor polish, which the release page still lists. Leave out Nightly 渠道 unless the release is about it.
  • The release URL sits bare on its own line, which linux.do renders as a card and WeChat as a link.

Write it to /tmp/runner-v<version>-release-note.zh-CN.txt, print the same text in the reply inside a text fence, and give the file path. Do not post it anywhere; the user does that.

sweep <version>

Reviews and cleans up the docs of everything shipped since the previous sweep in one doc-only commit on main, so merges themselves add no docs commits (AGENTS.md, Docs Sweep At Release). Run it only once v<version> is published (gh release view v<version> --json isDraft is false): a main push while a release or nightly run is in flight cancels the CI run its publish job waits on.

  1. Preflight. On main, clean tree, git rev-parse main origin/main equal after git fetch origin, and nothing in flight in gh run list --workflow release.yml --limit 3 --json status or the same for nightly.yml.
  2. Find what shipped. Read docs/README.md's Archive policy and the relevant archive README first; do not batch-read archived files for orientation. Walk the in-progress docs rather than a commit range, so anything an earlier sweep missed is caught: each brief in docs/impls/briefs/, each test record directly under docs/tests/ (excluding README.md and full-smoke-test.md), and each spec in docs/features/. Check each one's issue with gh issue view <n> --json state,stateReason,closedAt and its PRs with gh pr list --state merged --search <n>. Anything whose work is still open stays put.
  3. Test records. Move each shipped record to docs/tests/archive/ and promote its lasting live checks into docs/tests/regression/ under that README's promotion rules, reconciled with current code, or have the record state why none apply. Run results stay separate from maintained cases.
  4. Briefs. Prune the brief of every merged mission; git history keeps it. Keep the ones docs/impls/briefs/README.md lists as references, and the brief of any mission still running.
  5. Specs and plans. Once an issue closes (after the last PR for a multi-PR feature), delete completed small-feature, bug-fix, UI-polish and routine-refactor specs/plans. Retain only important features, architectural changes and consequential migration/platform/runtime/security contracts under docs/README.md's Archive policy, with a concrete retention reason in the archive README. Avoid duplicate spec/plan coverage; a second record needs distinct lasting context. Preserve unique current decisions in docs/arch/ and deferred scope in the issue; preserve embedded validation results and task history separately before pruning planning text. Do not prune test/run evidence or task/review logs. Repair references to current docs/code or fixed commit URLs, protect uncommitted user edits and update the indexes.
  6. Roadmap. Record the release in docs/roadmap.md: latest release, the Releases table, milestone state and open-work counts, reconciled with GitHub, and move the snapshot date.
  7. Commit. Repoint every link to a moved file and check the relative links with a script. Commit as docs: record the <version> release and clean up its shipped docs, push main, and report what was retained or pruned, the regression case IDs added, and anything left in place with the reason.

check <version>

Read-only. gh release view v<version> --json isDraft,isPrerelease,assets,body: report draft state, that the DMG, appcast.xml, installer, and .sig are all present, and whether the body has the English section and a <details> block containing the 中文 section. After publishing, also verify releases/latest resolves to the tag and the production appcast's enclosure names the new DMG.

Notes

  • The workspace version stays at X.Y.Z after the release; nightlies do not bump it (see the nightly skill).
  • workflow_dispatch of release.yml with dry_run builds the same artifacts into a throwaway draft named dry-run-<stamp> for inspection; delete that draft afterwards.
  • Windows Authenticode signing shipped with #497: release.yml signs the installer, app and CLI sidecars through Certum SimplySign, so the notes carry the signed sentence above. If a release ever ships unsigned, say so in its notes and warn about SmartScreen.
  • Apple credentials for local notarization checks live in ~/.zshrc; xcrun notarytool history and stapler validate <file> are the tools.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.