Add version-named publish gate before gh release create in /deploy

.agents/skills/deploy/SKILL.md

@@ -228,6 +228,14 @@ gh pr merge <pr-number> --merge
 
 ## Step 8 — Create GitHub Release
 
+**Publish confirmation — required before writing the release notes or creating the Release.** The GitHub Release is a public-surface action. The single word from Step 5 authorized the promotion/merge (already done); the public publish gets its own explicit confirmation. Tell the user (substitute the actual tag, e.g. `v0.13.0`):
+
+> Publishing GitHub Release `<version-tag>` — the final public step. Confirm by pasting: `publish <version-tag>`
+
+Wait for the user to paste `publish <version-tag>` (or an explicit version-named variant such as `ship <version-tag>`). Any other response → stop and ask what they'd like to change. The version-named phrase is deliberate: Claude Code's auto-mode safety classifier requires authorization that names the release before `gh release create` runs, so the generic Step 5 confirmation is not relied on for the public publish. If a harness still blocks the call after this confirmation (e.g. an older client), the user can re-confirm with `publish <version-tag> release` to unblock.
+
+---
+
 The version tag (from Step 3) and the PR/issue list (from Step 4) are already known. Find the previous tag to build the changelog link:
 
 ```bash
@@ -266,4 +274,4 @@ After the command runs, note the release URL from the output.
 Tell the user:
 
 > "Released vX.Y.Z. Issues #N, #M closed automatically. GitHub Release vX.Y.Z created at `<url>`. Run `make deploy-prod` to ship to production."
-<!-- generated by CodeCannon/sync.py | skill: deploy | adapter: codex | hash: 29b237ab | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->
+<!-- generated by CodeCannon/sync.py | skill: deploy | adapter: codex | hash: 394bbaae | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->

.claude/commands/deploy.md

@@ -223,6 +223,14 @@ gh pr merge <pr-number> --merge
 
 ## Step 8 — Create GitHub Release
 
+**Publish confirmation — required before writing the release notes or creating the Release.** The GitHub Release is a public-surface action. The single word from Step 5 authorized the promotion/merge (already done); the public publish gets its own explicit confirmation. Tell the user (substitute the actual tag, e.g. `v0.13.0`):
+
+> Publishing GitHub Release `<version-tag>` — the final public step. Confirm by pasting: `publish <version-tag>`
+
+Wait for the user to paste `publish <version-tag>` (or an explicit version-named variant such as `ship <version-tag>`). Any other response → stop and ask what they'd like to change. The version-named phrase is deliberate: Claude Code's auto-mode safety classifier requires authorization that names the release before `gh release create` runs, so the generic Step 5 confirmation is not relied on for the public publish. If a harness still blocks the call after this confirmation (e.g. an older client), the user can re-confirm with `publish <version-tag> release` to unblock.
+
+---
+
 The version tag (from Step 3) and the PR/issue list (from Step 4) are already known. Find the previous tag to build the changelog link:
 
 ```bash
@@ -261,4 +269,4 @@ After the command runs, note the release URL from the output.
 Tell the user:
 
 > "Released vX.Y.Z. Issues #N, #M closed automatically. GitHub Release vX.Y.Z created at `<url>`. Run `make deploy-prod` to ship to production."
-<!-- generated by CodeCannon/sync.py | skill: deploy | adapter: claude | hash: 925944b9 | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->
+<!-- generated by CodeCannon/sync.py | skill: deploy | adapter: claude | hash: a8da1ce6 | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->

.cursor/rules/deploy.mdc

@@ -229,6 +229,14 @@ gh pr merge <pr-number> --merge
 
 ## Step 8 — Create GitHub Release
 
+**Publish confirmation — required before writing the release notes or creating the Release.** The GitHub Release is a public-surface action. The single word from Step 5 authorized the promotion/merge (already done); the public publish gets its own explicit confirmation. Tell the user (substitute the actual tag, e.g. `v0.13.0`):
+
+> Publishing GitHub Release `<version-tag>` — the final public step. Confirm by pasting: `publish <version-tag>`
+
+Wait for the user to paste `publish <version-tag>` (or an explicit version-named variant such as `ship <version-tag>`). Any other response → stop and ask what they'd like to change. The version-named phrase is deliberate: Claude Code's auto-mode safety classifier requires authorization that names the release before `gh release create` runs, so the generic Step 5 confirmation is not relied on for the public publish. If a harness still blocks the call after this confirmation (e.g. an older client), the user can re-confirm with `publish <version-tag> release` to unblock.
+
+---
+
 The version tag (from Step 3) and the PR/issue list (from Step 4) are already known. Find the previous tag to build the changelog link:
 
 ```bash
@@ -267,4 +275,4 @@ After the command runs, note the release URL from the output.
 Tell the user:
 
 > "Released vX.Y.Z. Issues #N, #M closed automatically. GitHub Release vX.Y.Z created at `<url>`. Run `make deploy-prod` to ship to production."
-<!-- generated by CodeCannon/sync.py | skill: deploy | adapter: cursor | hash: ac038953 | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->
+<!-- generated by CodeCannon/sync.py | skill: deploy | adapter: cursor | hash: 6908f47a | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->

.gemini/skills/deploy/SKILL.md

@@ -228,6 +228,14 @@ gh pr merge <pr-number> --merge
 
 ## Step 8 — Create GitHub Release
 
+**Publish confirmation — required before writing the release notes or creating the Release.** The GitHub Release is a public-surface action. The single word from Step 5 authorized the promotion/merge (already done); the public publish gets its own explicit confirmation. Tell the user (substitute the actual tag, e.g. `v0.13.0`):
+
+> Publishing GitHub Release `<version-tag>` — the final public step. Confirm by pasting: `publish <version-tag>`
+
+Wait for the user to paste `publish <version-tag>` (or an explicit version-named variant such as `ship <version-tag>`). Any other response → stop and ask what they'd like to change. The version-named phrase is deliberate: Claude Code's auto-mode safety classifier requires authorization that names the release before `gh release create` runs, so the generic Step 5 confirmation is not relied on for the public publish. If a harness still blocks the call after this confirmation (e.g. an older client), the user can re-confirm with `publish <version-tag> release` to unblock.
+
+---
+
 The version tag (from Step 3) and the PR/issue list (from Step 4) are already known. Find the previous tag to build the changelog link:
 
 ```bash
@@ -266,4 +274,4 @@ After the command runs, note the release URL from the output.
 Tell the user:
 
 > "Released vX.Y.Z. Issues #N, #M closed automatically. GitHub Release vX.Y.Z created at `<url>`. Run `make deploy-prod` to ship to production."
-<!-- generated by CodeCannon/sync.py | skill: deploy | adapter: gemini | hash: 43c0a968 | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->
+<!-- generated by CodeCannon/sync.py | skill: deploy | adapter: gemini | hash: 7c176ebc | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->

docs/skills/deploy.md

@@ -44,14 +44,16 @@ No arguments. Must be run from the correct branch (determined by your branching
 
 6. **Human gate** — shows a release summary and waits for you to type "release".
 
-7. **Create GitHub Release** (trunk mode) or **Create promotion PR, merge, then create GitHub Release** (multi-branch modes).
+7. **Create GitHub Release** (trunk mode) or **Create promotion PR, merge, then create GitHub Release** (multi-branch modes). Creating the public Release has its own confirmation: you paste `publish vX.Y.Z` (the actual version) right before it publishes.
 
 ## Why it's built this way
 
 **Version bump and release in one flow.** Previously these were separate `/version` and `/release` commands. Combining them reduces the workflow from six commands to five and eliminates the possibility of bumping a version but forgetting to release, or vice versa. The version bump step is optional — if you've already tagged, you can skip straight to release.
 
 **Human gate is mandatory.** The "type release to confirm" gate exists because promoting to production is irreversible in practice. The summary gives you one last chance to verify that the right changes are going out.
 
+**The public Release has a second, version-named gate.** Single-word `release` authorizes the promotion and merge, but creating the public GitHub Release asks you to paste `publish vX.Y.Z` (with the real version). Two reasons: (1) it names the exact version you're publishing, so the authorization is unambiguous in the audit trail; and (2) Claude Code's auto-mode safety classifier treats publishing a Release as a public-surface action that needs authorization naming the release — a bare word doesn't satisfy it. Making this an expected, designed step means the publish never stops as a surprise mid-flow after the merge has already landed. If a harness still blocks after you confirm, re-paste `publish vX.Y.Z release` to unblock.
+
 **Issues close on release, not on feature merge.** In multi-branch modes, feature PRs use `Closes #N`, but the keyword is inert until it reaches the default branch — so issues only auto-close when the promotion PR merges to `BRANCH_PROD`. This means issues stay open through the QA/staging phase, giving you visibility into what's deployed where. `/deploy` parses each constituent PR's `Closes #N` lines into a **close set** (reproduced verbatim into the promotion PR, so nothing is dropped) and keeps `Related to #N` / legacy `Issue #N` references in a separate **reference set** that the human gate lists as "referenced but not closing" — letting you catch any straggler that should have closed.
 
 **State check surfaces surprises early.** Showing open unmerged PRs at the start prevents accidental releases that miss in-flight work.

skills/github-agile/deploy.md

@@ -264,6 +264,14 @@ Wait for the user to type "release" or an explicit confirmation. Any other respo
 {{#if !BRANCH_DEV}}
 ## Step 6 — Create GitHub Release
 
+**Publish confirmation — required before writing the release notes or creating the Release.** The GitHub Release is a public-surface action. The single word from Step 5 authorizes the promotion/merge; the public publish gets its own explicit confirmation. Tell the user (substitute the actual tag, e.g. `v0.13.0`):
+
+> Publishing GitHub Release `<version-tag>` — the final public step. Confirm by pasting: `publish <version-tag>`
+
+Wait for the user to paste `publish <version-tag>` (or an explicit version-named variant such as `ship <version-tag>`). Any other response → stop and ask what they'd like to change. The version-named phrase is deliberate: Claude Code's auto-mode safety classifier requires authorization that names the release before `gh release create` runs, so the generic Step 5 confirmation is not relied on for the public publish. If a harness still blocks the call after this confirmation (e.g. an older client), the user can re-confirm with `publish <version-tag> release` to unblock.
+
+---
+
 The version tag and PR/issue list are already known. If no previous tag exists, omit the "Full changelog" line.
 
 First, create a temp directory for this invocation:
@@ -362,6 +370,14 @@ gh pr merge <pr-number> --merge
 
 ## Step 8 — Create GitHub Release
 
+**Publish confirmation — required before writing the release notes or creating the Release.** The GitHub Release is a public-surface action. The single word from Step 5 authorized the promotion/merge (already done); the public publish gets its own explicit confirmation. Tell the user (substitute the actual tag, e.g. `v0.13.0`):
+
+> Publishing GitHub Release `<version-tag>` — the final public step. Confirm by pasting: `publish <version-tag>`
+
+Wait for the user to paste `publish <version-tag>` (or an explicit version-named variant such as `ship <version-tag>`). Any other response → stop and ask what they'd like to change. The version-named phrase is deliberate: Claude Code's auto-mode safety classifier requires authorization that names the release before `gh release create` runs, so the generic Step 5 confirmation is not relied on for the public publish. If a harness still blocks the call after this confirmation (e.g. an older client), the user can re-confirm with `publish <version-tag> release` to unblock.
+
+---
+
 The version tag (from Step 3) and the PR/issue list (from Step 4) are already known. Find the previous tag to build the changelog link:
 
 ```bash
@@ -457,6 +473,14 @@ gh pr merge <pr-number> --merge
 
 ## Step 8 — Create GitHub Release
 
+**Publish confirmation — required before writing the release notes or creating the Release.** The GitHub Release is a public-surface action. The single word from Step 5 authorized the promotion/merge (already done); the public publish gets its own explicit confirmation. Tell the user (substitute the actual tag, e.g. `v0.13.0`):
+
+> Publishing GitHub Release `<version-tag>` — the final public step. Confirm by pasting: `publish <version-tag>`
+
+Wait for the user to paste `publish <version-tag>` (or an explicit version-named variant such as `ship <version-tag>`). Any other response → stop and ask what they'd like to change. The version-named phrase is deliberate: Claude Code's auto-mode safety classifier requires authorization that names the release before `gh release create` runs, so the generic Step 5 confirmation is not relied on for the public publish. If a harness still blocks the call after this confirmation (e.g. an older client), the user can re-confirm with `publish <version-tag> release` to unblock.
+
+---
+
 The version tag (from Step 3) and the PR/issue list (from Step 4) are already known. Find the previous tag to build the changelog link:
 
 ```bash