eranw2000

Claude Release Workflow — DevOps skill for Claude Code

DevOps community

Two-verb ship-to-production workflow for Claude Code: /pr-checkpoint to iterate on a PR + local Docker, /release as the atomic ship gate (merge, docs, push, verify deploy), /production-smoke for read.

How to install Claude Release Workflow

This entry records only its repository, not the path inside it, so there is no exact command to give. Open eranw2000/claude-release-workflow and copy the folder into ~/.claude/skills/, or the file into ~/.claude/agents/.

What Claude Release Workflow does

Two-verb ship-to-production workflow for Claude Code: /pr-checkpoint to iterate on a PR + local Docker, /release as the atomic ship gate (merge, docs, push, verify deploy), /production-smoke for read-only post-deploy checks, plus a push-to-main guard hook.

Alternatives in DevOps

  • Ship Release — Systematic release workflow for RTK: build verification, version bump, changelog update, git tag, and push to 11.9k ★
  • Claudable — Claudable is an open-source web builder that leverages local CLI agents, such as Claude Code, Codex, Gemini CL 4k ★
  • 16 Testing — Prompt 16: Add Test Infrastructure & Smoke Tests 2.3k ★

README

Claude Release Workflow

A set of Claude Code skills and hooks for shipping code safely. It splits "ship it" into an iterate stage and a release stage, codifies the pre-release review loop, and puts a hook in front of `git push` so a release always goes through the skill instead of an ad-hoc push.

The idea is a small, repeatable path from a feature branch to a verified production deploy:

  1. pr-checkpoint: snapshot in-progress work as a GitHub PR and rebuild your local Docker container so you can test the feature branch on localhost. Does not merge, does not touch prod. Optionally runs the review loop as advisory reports.
  2. review-round: the codified three-reviewer loop. Author per-agent adversarial prompts aimed at the riskiest spots, launch the review agents in parallel, reproduce every finding by execution before fixing, prove each fix with a non-vacuous regression test, and post the PR verdict comment that release reads.
  3. release: the single ship-it verb. Auto-detects PR mode (merge open PRs targeting main) or trunk mode (commit straight to main), updates the README and project notes, pushes to every remote, verifies the auto-deploy landed on the right commit, and rebuilds local Docker so localhost matches prod. Refuses to merge a PR whose review-round verdict at the current head is CRITICALS-OPEN.
  4. production-smoke: a read-only check battery against the live service after a deploy: confirms the deployed commit matches what you pushed, hits the health endpoint and a few key routes, checks that debug mode is off in prod, and scans recent logs for tracebacks and 5xx.

A `block-git-push-main.sh` PreToolUse hook backs this up: it deterministically blocks any raw `git push` to `main` / `master` and points you at `/release`. It is the safety net for when the model forgets the workflow.

The flow

![Ship-to-production flow](docs/release-flow.png)

Source: [docs/release-flow.drawio](docs/release-flow.drawio) (editable in draw.io).

Why tw