release

Human output. Read ${CLAUDE_PLUGIN_ROOT}/skills/build-item/references/plain-language-output.md once per top-level run; composed skills reuse it. Apply it to every message.

Promote release.releaseSource → release.productionBranch (default develop → master). That merge triggers release.autoDeployOnMerge, so prepare autonomously but require explicit owner approval before merging. After confirmed deploy, invoke the repo's local docs.updateSkill unless no docs; write release notes only when --release-notes explicitly asks.

Optional arguments — documentation switches and a scope: $ARGUMENTS

• --release-notes <false|true|draft> — absent = false. Bare flag/“release notes” = true; draft leaves it unpublished. Step 5c runs only after confirmed merge and live deploy.
• no docs / skip docs — suppress the core-documentation update (step 5b) for this run. Docs are otherwise updated by default whenever a docs skill is registered.
• docs only — run step 5b alone against an already-shipped release, with no PR and no merge. release-notes only — run step 5c alone against an already-shipped release, still subject to the deploy confirmation. Asking for this scope IS the request: it implies --release-notes true, or draft when the word draft accompanies it (release-notes only draft).

Repo config. Load .claude/ds-config.json first and treat it as authoritative: the keys this skill reads are release.productionBranch, release.releaseSource, release.autoDeployOnMerge (a plain-English string quoted back to the owner — never assume a provider), release.deployVerification, docs.updateSkill and docs.releaseNotesSkill (LOCAL skill names; their contract is ${CLAUDE_PLUGIN_ROOT}/skills/release/references/docs-hooks.md, the authority over anything restated here), plus baseBranch / protectedBranches / ci.freezeBaseWhileReleasePrReady and the review.* / verify.* / preShipChecks / prBodyTemplate blocks the composed skills consume. Inline literals are shipped defaults — if the file disagrees, the file wins; if it is absent, fall back to them and say so.

IMPORTANT — autonomy boundary:

• Run steps 0–3 (delta → PR → full gated review → documentation preparation) autonomously; only surface genuine forks (an ambiguous/risky/unverifiable review finding, an unresolvable conflict, or an infra/secret gate that is the owner's to provision).
• The master merge is a hard gate. NEVER merge develop → master without an explicit, in-the-moment owner go-ahead — it deploys production. Present the release summary and ask. Invoking /devstride:release is intent to PREPARE a release, not standing authorization to deploy.
• The core-documentation update is pre-authorized by default whenever docs.updateSkill is registered — the local skill decides what publishing means and may pause for a look — but it is still an outward action: explain the result plainly and preserve exact pages, links, branch and pull request. It runs only after the merge is confirmed (step 5b); nothing is published before the owner approves the production merge. "no docs" skips it.
• Release notes are NEVER written without --release-notes. There is no size, scope or "user-facing" threshold this skill interprets on the owner's behalf; the flag is the only trigger, and the note comes after the confirmed deploy (step 5c). If it seems a release deserves a note the owner did not ask for, say so in the step-4 summary and let them add the flag.

IMPORTANT — the DevStride MCP targets PRODUCTION; git/gh act on the real repos. Treat the production merge, and anything the local docs skills publish, as real, user-visible production events.

0. Preconditions and the release delta

• Confirm this is a release. The release is release.releaseSource (develop) → release.productionBranch (master). If invoked standalone with the tree on some other branch, that's fine — this skill operates on the two named branches, not the current checkout. If a develop → master PR is already open, adopt it instead of cutting a duplicate.
• Prove CI can stay last before opening anything. Inspect pull-request workflows, excluding the convention-only shape in ${CLAUDE_PLUGIN_ROOT}/skills/setup/references/ci-cost-patterns.md. None → valid no-CI release, said plainly. Any expensive PR workflow without all draft-hold flags true → STOP with /devstride:setup ci; false, mixed or ambiguous facts cannot prove a hold.
• Sync both branches. git fetch origin master develop. Confirm origin/develop is ahead of origin/master (there is something to release); if not, STOP and say there's nothing to release.
• Settle the release source BEFORE cutting (when ci.freezeBaseWhileReleasePrReady is true, the default; false skips this and the freeze, and says so): list every open NON-DRAFT PR into releaseSource — green, pending or red alike — and decide each NOW: merge it first (it joins this release; the delta is recomputed) or park it (gh pr ready --undo) until this release merges. Say which choice was made for each and keep the parked list — step 6 un-parks them.
• Record <sourceHead> — the SHA of origin/<releaseSource> the delta was computed from — whatever the freeze switch says. Every later integrity check compares against this immutable value, never against the branch tip (the release PR's head IS the branch, so the tip and "the PR head" move together and comparing them proves nothing).
• Compute the delta — what this release ships. Read git log --first-parent origin/master..origin/develop and the merged PRs in that range (gh pr list --base develop --state merged cross-referenced to the range) to assemble: the epics/stories that landed, and — importantly — which changes are user-facing (new/changed UI, API, behavior, permissions, migrations) vs internal. This delta drives BOTH the PR body and the docs pass. Note anything that looks like a breaking change or a migration explicitly.
• Report the delta summary (epic/story list + the user-facing subset) before cutting the PR.