Skill · from merge to users, and back

Release Engineer

A change that passes on a laptop is not yet a change users have. This builds the path in between — checks on every pull request, one artifact, staging on merge, a production step someone authorized — and a way back that was tried before it was needed.

Soumya Rauth · Creator & maintainer

npx skills add soumyaRauth/skills-hub --skill release-engineer

The problem

merge → ssh in, rebuild, paste a secret → no way back

Without a pipeline, every deploy is a hand-typed ritual. The server rebuilds what the laptop tested, so production runs something nobody checked. Secrets end up in files. And when the new version answers 503, the only rollback is remembering what was there before.

Coding agents make it faster to ship and no easier to undo. A deploy that “went fine” is only as true as the output someone read.

When it activates

No slash command needed. Installed, it is loaded when a request needs it and stays out of the way otherwise — and when it does shape the work, one ⚡ line says so. How the skills work together →

Engages	Setting up or fixing CI/CD, automated deploys, staging or production environments, secrets in CI, rollback, a migration-safe deploy — or “deploy this” when no repeatable path exists.
Stays quiet	Comments or formatting in CI and Docker files, generic questions about CI products, local setup, and whether a change is safe to ship.
Depth	Shapes the work: it writes the pipeline and runs the deploys. It gates only the production deploy it performs itself.
Works with	Production Guard, Deployment Compatibility, Dependency Guard, Impact Map, Engineering Investigator

What it does

pull request → checks install · lint · test · build
→ main build the artifact once · staging · smoke · roll back on failure
→ production the same artifact · only with a ship verdict and authorization

You:    Set up CI/CD so every merge to main runs the tests and deploys to staging.

Agent:  PIPELINE    GitHub Actions · .github/workflows/ci.yml
        PR CHECKS   install ✓ · lint ABSENT (no script) · test ✓ · build ✓
        STAGING     on merge to main → VPS over SSH, docker compose
        ROLLBACK    ./deploy/rollback.sh staging · NOT RUN
        STATUS      WRITTEN, NOT RUN — set STAGING_SSH_KEY, STAGING_HOST,
                    STAGING_KNOWN_HOSTS, then open a PR

Never its own ship verdict

RELEASE     production · ghcr.io/acme/shop@sha256:7ac3…
BLOCKED     production-guard returned DO NOT SHIP for 5e81d0a
RAN         nothing in production

Whether a change is safe to ship is Production Guard’s decision. A production deploy waits for its SHIP — or your explicit go-ahead — and for authorization, even when autonomy says deploys are automatic.

A rollback tried before it is needed

Before the first production deploy, the rollback command is run on staging: deploy, roll back, smoke-check, roll forward. Migrations are expand-then-contract, so the old version can still run after a rollback. When a smoke check fails, the rollback runs at once and the report shows both results — quoted from real output, never assumed.

Where it fits

Deployment Compatibility says whether a server can run the app; this builds the path to it. Production Guard says whether a change is safe to ship; this carries it there. New CI actions and images go through Dependency Guard, and a deploy that fails for no visible reason goes to Engineering Investigator.