`/deploy` Step 5 confirmation phrase "release" is too generic for Claude Code auto-mode classifier; blocks Step 8 publish

[sebastientaggart]

Problem to Fix

The /deploy skill's Step 5 (HUMAN GATE) instructs the user to "Type release to confirm" before the deploy proceeds. When running under Claude Code in auto mode, that single-word confirmation passes Step 5 but is not retained as authorization for Step 8 (creating the GitHub Release via gh release create vX.Y.Z).

At Step 8, the auto-mode safety classifier blocks either the Write to the release-notes file or the subsequent gh release create call with:

Creating a GitHub release for v0.13.0 is a public-surface/release action that requires explicit user authorization naming the release, not just "release". If you have other tasks that don't depend on this action, continue working on those.

The user is then forced to re-confirm with a more specific phrase (e.g. "publish v0.13.0 release") before the agent can complete Step 8. The release tag is already pushed, the dev → main PR is already merged, and the rollback path (delete tag, revert merge commit) is non-trivial — so the deploy lands in a half-published state: main has the version commit and the closing-keyword issue closures have fired, but no GitHub Release page exists until the user gives the second confirmation.

Why it Matters

This is a small but high-friction papercut on the most stakes-laden command in the workflow. The skill currently leaves the deploy in a partially-published state and requires manual recovery action mid-execution, exactly when the user least wants ambiguity. The /deploy flow is supposed to be the moment of highest clarity in the lifecycle, and Step 5's gate is supposed to cover everything downstream — not just up to and including the main merge.

It also undermines the skill's stated guarantee: "Wait for the user to type 'release' or an explicit confirmation. Any other response → stop and ask what they'd like to change." Users reasonably believe that typing the prescribed word authorizes the whole flow. When it doesn't, they're left wondering whether they did something wrong.

General Approach

Change Step 5's required confirmation phrase to name the version so the classifier sees an authorization that satisfies its "name the release" requirement at Step 8. The version is known at Step 5 (it was determined in Step 3 or by git describe), so embedding it in the prompt is free.

Current Step 5 prompt (from the skill):

Have you tested all of the above on preview? Type 'release' to confirm.

Proposed Step 5 prompt:

Have you tested all of the above on preview? Type release vX.Y.Z to confirm.

Where vX.Y.Z is substituted with the actual version tag the deploy is about to publish (e.g. release v0.13.0).

Acceptance for "explicit confirmation" should still accept the named form plus reasonable variants ("publish v0.13.0", "ship v0.13.0", etc.), but the canonical instruction is the version-named one. Any other response → stop and ask, same as today.

If keeping a generic confirmation fallback is desirable for non-classifier harnesses, the skill can accept both, but the printed instruction should be the version-named form so users default to it. The version-named confirmation is also more meaningful audit-trail content if the conversation is logged.

Complexity

Verification / QA effort: trivial

Single-line change in skills/deploy/skill.md (or wherever Step 5's prompt lives). No code changes. Verify by running /deploy end-to-end under Claude Code auto mode against a throwaway repo and confirming Step 8 completes without re-prompting.

Acceptance Criteria

• Step 5's HUMAN GATE prompt instructs the user to type release vX.Y.Z (with the actual version substituted), not just release.
• Step 8's Write of the release-notes file and gh release create vX.Y.Z complete without re-prompting under Claude Code auto mode.
• The skill still treats any unconfirmed response as "stop and ask".
• A note is added near Step 8 mentioning that if the classifier still blocks (e.g. older client, different harness), the user can re-confirm with "publish vX.Y.Z release" to unblock the publish step — covers the long tail without bloating the main path.

Repro

Claude Code, auto mode, /deploy against any repo with at least one merged PR since the last tag. Pick minor, confirm at Step 5 with literal release. Step 8 will block on either the release-notes Write or the gh release create call with the classifier message quoted above.

Observed: 2026-06-17 against Discovery-Platform/Discovery_Platform deploying v0.13.0. Tag was pushed, dev → main PR #346 merged, GitHub Release publish blocked mid-step.

Workaround (today)

User re-confirms with a version-named phrase (e.g. "publish v0.13.0 release"); skill resumes Step 8 from where it stopped. Tag and merge are already done at that point, so the only remaining work is the release-notes file write and the gh release create call — no rollback needed.

[sebastientaggart]

Investigation Findings

Confirmed the root cause and settled on an approach that diverges deliberately from the proposed fix:

• Root cause confirmed. The auto-mode safety classifier re-evaluates at the public-surface action (gh release create) independently of the Step 5 confirmation, and from the reported data point it wants the version named in the user's own words at the publish moment. A short generic word won't satisfy it regardless of where it's placed.

• The real harm is the surprise mid-step block, not the second prompt. By the time the classifier fires, the tag is pushed and dev→main is merged, so the deploy looks half-published. Making the publish confirmation an expected, designed step removes the surprise.

• Divergence from the ticket's proposal: rather than changing Step 5's phrase to release vX.Y.Z (awkward, error-prone, and against the one-word go/release confirmation ergonomic used everywhere else in the workflow), Step 5 stays single-word release (authorizes the promotion/merge). A dedicated publish micro-gate is added at the top of each "Create GitHub Release" step — before the release-notes write and gh release create, since the classifier can block either — where the agent prints the exact phrase to paste (publish vX.Y.Z). Same classifier-satisfying outcome, better UX.

• Reordering rejected. Publishing the Release before the dev→main merge just trades the half-published window for an arguably-worse "Release page exists for a version not yet on main" window, so merge-before-publish is kept.

• Scope note: the source template carries three branching-mode variants (trunk Step 6, dev Step 8, test Step 8), so the gate is added in three places plus a long-tail note (re-confirm with publish vX.Y.Z release if a harness still blocks) — slightly more than the "single-line change" the ticket anticipated, but still trivial.

[sebastientaggart]

Resolution

Deploying no longer stalls partway through publishing a release. The final confirmation now names the exact version you're shipping, so the safety check that guards public release publishing is satisfied up front instead of interrupting mid-deploy after the code has already been promoted. The first "ready to release" confirmation stays a single word; only the public publish step asks you to confirm the version by name — and it's now a clearly expected step rather than a surprise stop.

See #189 for full technical details.