Agent skill · software engineering · sickn33
pre-ship-gate
A ship gate that runs before any production deploy: checks the silent failure modes that make a deploy 'succeed' while prod stays broken, then verifies the live revision instead of trusting deploy output.
Why this skill is useful
Adds a specific verification script for confirming live deployment status that isn't commonly known or practiced.
What it needs
Requires jq installed locally. About 5k tokens when loaded. Last updated 2026-08-07. 44,571 stars on the source repository.
What this skill does
Pre-Ship Gate Overview Most bad deploys do not fail loudly. The pipeline goes green, the CLI prints "deployed", and the old or broken version is still what users hit. This skill is the gate you run right before a production deploy and right after, so an agent stops trusting deploy output and starts confirming what is actually live. It exists because "the deploy command exited 0" and "the new version is serving traffic" are two different facts, and agents routinely confuse them. When to Use This Skill Use before running any command that pushes to a production or staging environment. Use when an agent is about to report "shipped", "deployed", or "live". Use when a deploy reported success but users still see the old behavior. Use when a release involves database migrations, feature flags, or a staged rollout. How It Works The gate has three phases. Do not skip to phase 3. Phase 1: Pre-flight (before the deploy runs) Walk the silent failure catalog. These are the modes that let a deploy "succeed" while production stays broken. For each one, confirm it or flag it. Do not assume. Migrations: Are schema migrations part of this release, and will they run against the target before the new code serves traffic? A deploy that ships code expecting a column that does not exist yet fails silently for users, not for the pipeline. Feature flags: Is the flag that gates this change actually enabled in the target environment, not just in dev? Shipped code behind an off flag looks like a no-op deploy. Build cache / stale assets: Could a cached build or CDN layer serve the previous bundle after deploy? Confirm the artifact hash or asset fingerprint changed. Release pointer: Does the deploy update the symlink, active revision, or traffic pointer, or does it only upload the new build? Uploading is not releasing. Staged rollout / canary: If traffic is staged, is it stuck at 0 percent or waiting on a manual promote? A canary that never promotes is not a deploy. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills sickn33/pre-ship-gate--0b2f96