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

[sebastientaggart]

What changed

Adds a dedicated, version-named publish confirmation to /deploy so the GitHub Release step is no longer surprise-blocked by Claude Code's auto-mode safety classifier.

skills/github-agile/deploy.md — Step 5's HUMAN GATE is unchanged (still single-word release, which authorizes the promotion/merge). A publish micro-gate is inserted at the top of all three "Create GitHub Release" steps (trunk Step 6, dev Step 8, test Step 8), before the release-notes Write and gh release create — since the classifier can block either. It asks the user to paste publish <version-tag>, accepts explicit version-named variants (ship <version-tag>), stops-and-asks on anything else, explains the classifier rationale, and includes a publish <version-tag> release long-tail fallback for harnesses that still block.

docs/skills/deploy.md — updated the step-7 summary and added a "Why it's built this way" paragraph documenting the two-gate design.

Adapters (.claude / .cursor / .agents / .gemini) regenerated via sync.py --force.

Why

Under Claude Code auto mode, the single word release passes Step 5 but is not retained as authorization for the public gh release create. The classifier re-evaluates at the public action and demands authorization that names the release, blocking mid-flow after the tag is pushed and dev→main is already merged — leaving a half-published state. Making the version-named confirmation an expected gate at the publish moment satisfies the classifier and removes the surprise.

Design decision (diverges from the ticket)

The ticket proposed changing Step 5 itself to require release vX.Y.Z. We instead keep Step 5 as a single word (preserving the one-word go/release confirmation ergonomic used throughout the workflow) and move the version-named confirmation to a dedicated publish gate. Same classifier-satisfying outcome, better UX. Reordering publish-before-merge was rejected because it just trades the half-published window for a "Release page exists for a version not yet on main" window. Rationale recorded as a comment on #187.

Test plan

Prompt-skill markdown, no executable suite. make check (placeholder + permission validation via sync.py --validate) passes; the rendered two-branch adapter was spot-checked and shows a single Step 8 with the publish gate, with the trunk/test conditionals correctly omitted. Full end-to-end confirmation (Step 8 completing without a re-prompt under auto mode) happens on the next real /deploy.

Closes #187

[sebastientaggart]

Review Summary

Verdict: APPROVE

This PR adds a version-named "publish micro-gate" (publish <version-tag>) at the top of every "Create GitHub Release" step in the deploy skill, before the release-notes write and gh release create. The substantive change is in skills/github-agile/deploy.md and its human docs docs/skills/deploy.md; the .claude/.cursor/.agents/.gemini adapters are regenerated mirrors and are excluded from duplicate-work concerns per the auto-generation contract.

Findings

• [CRITICAL] PR adds an authorization gate guarding the public gh release create (production-publish surface) — operator review required regardless of code quality. The gate is correctly designed; this finding exists only to satisfy the sensitive-area gate (production configuration / public-surface action). No defect implied.

• [NOTE] The gate is inserted identically across all three branching variants (trunk Step 6, dev Step 8, test Step 8), placed as the first block under each "Create GitHub Release" heading — i.e. before both the release-notes Write and the gh release create call, exactly as intended. Placement is unambiguous.

• [NOTE] The wording is correctly differentiated per variant: the trunk variant (Step 6, no preceding merge step) says the Step 5 word "authorizes the promotion/merge" (present tense, no "already done"), while the dev/test variants (Step 8, after the Step 7 merge) say it "authorized the promotion/merge (already done)". This matches the actual control flow in each mode.

• [NOTE] Step 5's single-word release gate is left unchanged, and the new gate text explicitly explains why a second version-named confirmation is needed (auto-mode safety classifier requires authorization that names the release). No contradiction with the existing flow: the dev/test temp-dir is created in Step 6 and reused in Step 8, and the new gate sits ahead of that reuse, so nothing in the surrounding instructions conflicts.

• [NOTE] The generated adapters match their source. The repo renders in two-branch/dev mode: .claude/commands/deploy.md contains only the dev Step 8 variant (trunk Step 6 and test Step 8 blocks are absent), which matches the source's {{#if BRANCH_DEV}}{{#if !BRANCH_TEST}} path. ./sync.py --dry-run reports all deploy adapters up to date for every adapter (claude, cursor, codex, gemini), confirming the generated copies are in sync with the source.

No correctness, consistency, or placement issues found in the substantive change.