Release gate — how a change ships

A release is a decision: the owner says go; the agent supplies the evidence. This skill is what the evidence has to be at each moment of shipping, how a promotion is done, and how to prove afterwards that the build serving is the one that was reviewed.

The rules come from two kinds of product, named here only by kind. The web-app half — the bars, the preview, the promotion checklist, go-live, the verify probes, Netlify's edge — was learned on Next.js (App Router) + Supabase + Clerk + Netlify, with Vitest and Playwright, by several products (a live Q&A product, a monitoring product with worker boxes and edge workers beside its web app, and others). The client+backend half — any release as one logged checklist, the backend before the client, artifacts and store listings, issues — was learned on a remote-control product: a relay service with a web client, and an editor extension with desktop installers that drives a CLI agent (references/runbook.md). Each rule states its principle first and the stack's mechanism second; on another stack, keep the principle and swap the mechanism. The product's own instructions come first: where its agent instructions or release doc name the branches, the gate, the backlog or the record files, follow them. What follows is the default where they say nothing.

Two branches, named once

• The product branch (<product>) is where stage work lands.
• The production branch (<product>-prod) is what the host deploys to production. It moves only by fast-forward, after the local gate, the independent review and the owner's go.

Write the real names into the product's release doc at the first push, and nowhere else. Until the production branch exists, the host deploys the product branch itself, so every push to it is a deploy. How branches map to environments is the environments skill.

A host that deploys by CLI upload deploys the working tree, not a commit. With railway up and its like, the upload is the push: the review round closes before it, and the upload runs from a clean worktree of the reviewed commit, never a tree with edits in it. Name the target on the command (railway up --ci -p <project> -e <environment> -s <service>): a bare railway up in an unlinked folder offers to create a new project. (2026-11-01, an evals product's first deploy: this skill and environments both assumed a host that builds from a git branch.) Stamp every upload with its commit (railway up --message <commit>, recorded as the deployment's meta.cliMessage): an upload records no commit and gets its own snapshot id, so without the stamp nothing shows that the web app and a worker run the same tree. Scripts that read Railway's state must allow for two more things: a stopped deployment stays in activeDeployments with status SUCCESS and deploymentStopped: true, and reading environmentStagedChanges creates an empty staged record ({ patch: {} }), so a "nothing staged" check ignores an empty patch. (2026-11-03, an evals product's worker stop and start script: each found only by running it.)

The product's records

Whatever your product calls them, this skill means: the plan (its stages, each with a done-when, and the one current status); the backlog (deferred work, each entry with its reason and the trigger that reopens it); the coverage map (what was verified, by which run — test-harness); the integrations doc (each provider's dashboard configuration, with screenshots); the environments doc (which deployment uses which database, identity instance and keys, and a dated log of environment events); the release history (one dated section per release). gate, smoke -- <url>, visual and agents:live are the script names this skill and test-harness suggest — call yours what you like.