Add a release skill, and put every release command in RELEASING.md

.agents/skills/release/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: release
+description: Cut a release of the WordPress Contributor Toolkit, stable or beta, from the version bump to the published GitHub release and docs deploy. Use when the user asks to release, cut, ship or publish a version, bump the version for a release, or names a version such as 2.0.0 or 2.1.0-beta.1 to release.
+---
+
+# Release
+
+Drive a release through `RELEASING.md`, pausing wherever a step is public or needs a person.
+
+## Procedure
+
+**Read [`RELEASING.md`](../../../RELEASING.md) and follow it.** It is the specification for this task, not background reading: every step and every command lives there, including the artifact checks, how to pick the base for the release notes, and the checks after publishing. Do not restate it here; run it. Changes to how releases work go there, not into this wrapper.
+
+The skill takes the version as its argument (`2.0.0`, `2.1.0-beta.1`). If none is given, ask. A version of the form `X.Y.Z` is stable and `X.Y.Z-beta.N` is a beta. Stop and ask about any other form, such as `2.1.0-rc.1`, rather than treating it as stable.
+
+What this skill adds on top:
+
+**Check the starting state first.** Run the checks in section 1, item 1 of `RELEASING.md`, and stop and report if any fails. If a milestone named for the full version exists, report any issues and pull requests still open in it, without stopping.
+
+**Wait for the person's yes before each of these:**
+
+1. Creating the release branch, after confirming its name.
+2. Pushing the branch and opening the bump pull request.
+3. Pushing to the branch again, when it has to be updated with trunk before the merge. Then repeat the artifact checks on the new head's build.
+4. `gh release create`, after showing the final notes and the exact command.
+5. Dispatching the docs workflow for a stable release (a beta skips it), and closing the milestone if the release has one.
+
+The merge is the person's. Wait to be told it is merged, unless the person asks this skill to merge: then merge with the command in section 3 of `RELEASING.md`, guarded by the head commit the artifacts were checked on. However it was merged, run the checks that follow the merge in section 3 before anything else. If the check after the merge prints anything, stop and report it; do not tag until the artifacts have been checked again as that section says.
+
+**The bump pull request is an ordinary pull request.** Fill in `.github/pull_request_template.md` and run the review AGENTS.md requires before opening it.
+
+**The person downloads the artifacts; this skill checks them.** This skill cannot see Buildkite: the build reports nothing to the pull request. Ask the person to confirm that the build's commit matches the pull request's current head, and to download the three files from it into a directory they name. Then run the checks in section 2 of `RELEASING.md`, *Check the signed artifacts*, and report each result. Do not report the build as matching the head until the person has said it does.
+
+**Draft the release notes once the pull request is merged.** Write them plainly, save them to a temporary directory outside the repository, and show them in the chat for editing before `gh release create` (item 4 above).
+
+**Run the checks in section 7 of `RELEASING.md`, *Check the result*, before reporting done**, and report each one.
+
+## Notes
+
+- This is the same skill as [`.claude/skills/release/`](../../../.claude/skills/release/), placed here because agents built on the Agent Skills open standard discover skills under `.agents/skills/`. Both are thin wrappers over `RELEASING.md`.
+- If a step in `RELEASING.md` turns out wrong or incomplete during a release, say so at the end. That file is meant to accumulate what each release teaches.

.claude/skills/release/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: release
+description: Cut a release of the WordPress Contributor Toolkit, stable or beta, from the version bump to the published GitHub release and docs deploy. Use when the user asks to release, cut, ship or publish a version, bump the version for a release, or names a version such as 2.0.0 or 2.1.0-beta.1 to release.
+---
+
+# Release
+
+Drive a release through `RELEASING.md`, pausing wherever a step is public or needs a person.
+
+## Procedure
+
+**Read `RELEASING.md` and follow it.** It is the specification for this task, not background reading: every step and every command lives there, including the artifact checks, how to pick the base for the release notes, and the checks after publishing. Do not restate it here; run it. Changes to how releases work go there, not into this wrapper.
+
+The skill takes the version as its argument (`2.0.0`, `2.1.0-beta.1`). If none is given, ask. A version of the form `X.Y.Z` is stable and `X.Y.Z-beta.N` is a beta. Stop and ask about any other form, such as `2.1.0-rc.1`, rather than treating it as stable.
+
+What this skill adds on top:
+
+**Check the starting state first.** Run the checks in section 1, item 1 of `RELEASING.md`, and stop and report if any fails. If a milestone named for the full version exists, report any issues and pull requests still open in it, without stopping.
+
+**Wait for the person's yes before each of these:**
+
+1. Creating the release branch, after confirming its name.
+2. Pushing the branch and opening the bump pull request.
+3. Pushing to the branch again, when it has to be updated with trunk before the merge. Then repeat the artifact checks on the new head's build.
+4. `gh release create`, after showing the final notes and the exact command.
+5. Dispatching the docs workflow for a stable release (a beta skips it), and closing the milestone if the release has one.
+
+The merge is the person's. Wait to be told it is merged, unless the person asks this skill to merge: then merge with the command in section 3 of `RELEASING.md`, guarded by the head commit the artifacts were checked on. However it was merged, run the checks that follow the merge in section 3 before anything else. If the check after the merge prints anything, stop and report it; do not tag until the artifacts have been checked again as that section says.
+
+**The bump pull request is an ordinary pull request.** Fill in `.github/pull_request_template.md` and run the review AGENTS.md requires before opening it.
+
+**The person downloads the artifacts; this skill checks them.** This skill cannot see Buildkite: the build reports nothing to the pull request. Ask the person to confirm that the build's commit matches the pull request's current head, and to download the three files from it into a directory they name. Then run the checks in section 2 of `RELEASING.md`, *Check the signed artifacts*, and report each result. Do not report the build as matching the head until the person has said it does.
+
+**Draft the release notes once the pull request is merged.** Write them plainly, save them to a temporary directory outside the repository, and show them in the chat for editing before `gh release create` (item 4 above).
+
+**Run the checks in section 7 of `RELEASING.md`, *Check the result*, before reporting done**, and report each one.
+
+## Notes
+
+- This is the same skill as [`.agents/skills/release/`](../../../.agents/skills/release/), for agents that read the Agent Skills open-standard path. Both are thin wrappers over `RELEASING.md`.
+- If a step in `RELEASING.md` turns out wrong or incomplete during a release, say so at the end. That file is meant to accumulate what each release teaches.

AGENTS.md

@@ -4,7 +4,7 @@ Instructions for AI coding agents working in this repository. Tool-neutral and c
 
 ## Where things are, whatever agent you use
 
-Two files, and neither is specific to one tool despite what their paths suggest:
+Three things, none of them specific to one tool despite what their paths suggest:
 
 **The review standard** — [`.github/instructions/code-review.instructions.md`](.github/instructions/code-review.instructions.md). The five dimensions, this project's invariants, the procedure to run them, and the reporting format. Read it directly if your agent has not already.
 
@@ -15,12 +15,14 @@ It sits under `.github/instructions/` because Copilot code review reads that dir
 - [`.claude/skills/self-review/`](.claude/skills/self-review/) — Claude Code and Copilot. In Claude Code it is `/self-review`.
 - [`.agents/skills/self-review/`](.agents/skills/self-review/) — the Agent Skills open-standard path that Command Code and others scan.
 
-Both are pointers to the one instructions file, not copies of the standard. If your agent looks somewhere else again (`.github/skills/`, `.cursor/skills/`, `.codex/skills/`, or its own convention), add a wrapper there or skip it entirely and follow the instructions file — that is where all the content lives. The wrapper only adds two things: run the judgement pass in a fresh context, and report without touching GitHub.
+Both are pointers to the one instructions file, not copies of the standard. If your agent looks somewhere else again (`.github/skills/`, `.cursor/skills/`, `.codex/skills/`, or its own convention), add a wrapper there or skip it entirely and follow the instructions file — that is where all the content lives. The review wrapper only adds two things: run the judgement pass in a fresh context, and report without touching GitHub.
 
 In Codex, `/review` is the built-in user-facing review command. Whenever `/review` runs, read and follow [`.github/instructions/code-review.instructions.md`](.github/instructions/code-review.instructions.md) in full as the review standard. `self-review` is the local skill name, not a Codex command; do not tell users to invoke `self-review`.
 
 There is deliberately no per-tool copy of the *standard*. A wrapper is a few lines that defer to it; duplicating the standard itself is the thing to avoid — if you find yourself doing that, fix the pointer, not the number of copies.
 
+**Releasing** — [`RELEASING.md`](RELEASING.md) is the procedure. The `release` skill wraps it the same way, in [`.claude/skills/release/`](.claude/skills/release/) (`/release X.Y.Z` in Claude Code) and [`.agents/skills/release/`](.agents/skills/release/). The wrapper adds the stops before each public step and leaves the merge to the person unless they ask it to merge.
+
 ## What this is
 
 An Electron desktop app ("WordPress Contributor Toolkit") that sets up a full WordPress core (`wordpress-develop`) dev environment with zero prerequisites — no Git, Node, npm, or Docker required on the host. Everything is bundled and run as JS/WASM inside the Electron process. Built to fix a Contributor Day problem: newcomers burning the whole session on local setup instead of contributing. Still labeled "experimental."