release

name	release
description	Pre-release audit, GPG tag signing, and download-URL update for a target repo. Runs audits autonomously; pauses at the human-only signing step.
user-invocable	true
argument-hint	["new-tag-name"]

Release $ARGUMENTS

Encode the release checklist as a repeatable flow: run audits autonomously, pause at the human-only step (GPG signing), then verify and summarise. The skill never signs a tag — that is the human's sole responsibility.

When to use

• Invoke from the target repo's working directory, on its main branch, with all feature work already merged.
• Cross-repo prerequisite: the caller must ensure cwd is the target project before invoking /release. The skill is cwd-based — it never takes a repo or path argument. For cross-repo flows, change into the target project directory and fetch from the forge before the call.

1. Pre-flight gate

• Run the target repo's make check. HALT on failure — print the failing output and stop. A release never ships on a red suite.
• Scan open tickets for the needs-human tag. If any are tagged, HALT, list them, and stop — these are blocking human-judgment items that must be resolved before a release. Degrade gracefully with a warning if there is no tickets/ directory or no erg binary available (the gate is informational in that case, not blocking).

2. Parallel audits

Launch two background agents in parallel (single message, both as background agents). Wait for both to return, then consolidate.

Agent A — security audit. Review the release surface for:

• supply chain (dependencies, pinned versions, fetched scripts),
• permissions (file modes, capabilities, token scopes),
• injection (unsanitised input reaching a shell, eval, or template),
• signing (tag-signing path, key handling, attestation of downloads).

Agent B — UX dry-run. Read the target repo's tickets/0152 for the audience definitions and install paths, and walk each one. If 0152 is absent, degrade to generic heuristics: a clean install from scratch, plus a first-use walkthrough of the primary command.

Each agent files one ticket per finding via /ticket-new, with a severity of HIGH / MEDIUM / LOW in the title or body. If there is no tickets/ directory, the agent prints its findings to output instead of filing.

After both return, print a consolidated summary: count of findings by severity, grouped by agent.

3. Resolve HIGH findings

If any finding is HIGH, print the list, STOP, and await a human "continue". A release does not proceed past an open HIGH finding without explicit human go-ahead.

4. Update the download URL

• Determine the new tag: the skill argument if given, else the current UTC date in YYYY-MM-DD form.

• Verify the tag does not already exist: git tag -l <tag> must be empty. If it exists, STOP — a release tag is never reused.

• Run the helper on README.md (and on src/go/assets/integration.md if that file is present):

  ~/.claude/skills/release/rewrite-download-url README.md <tag>
  

  The helper rewrites the tag-like segment inside raw-download / release URLs to the new tag and prints a match count; it exits non-zero (with a diagnostic) if no such URL is found, so a missing URL surfaces immediately. An already-current URL is a normal match: the helper prints its count and exits 0 (idempotent no-op).

• Commit the change: release(<tag>): update download URL to <tag>.

5. GPG signing pause (human-only)

Print exactly this command, then end the turn:

git tag -s <tag> HEAD && git push --tags

The human signs the tag with their GPG key and pushes it, then replies to resume. The skill never runs this step itself.

6. Verify the tag

On resume, confirm the signature:

git verify-tag <tag>

If verification fails, print the error and STOP — an unverifiable tag is not a release.

7. Blog post (stub)

File a deferred ticket via /ticket-new titled Write release blog post for <tag>. This is a documented placeholder — there is no blog implementation until blog infrastructure exists.

8. Summary

Print: the tag, the findings count (by severity), whether the download URL was updated, and whether the tag verified.

Language and identity

• Forge-agnostic: "merge request" not the forge-specific term, "ticket" not the tracker-specific term, "forge" for the hosting service.
• No forge-CLI commands in this prose.
• The Imperial Dragon is not a bird — no avian analogies. Scale, power, taxonomy.