/deploy-check · slashskills

What you get back recorded run · 9 Oct 2026

claude · tallyroom

Using /deploy-check

Don't ship this tonight.

Claude Code 2.1.295·39s·no files changed

BLOCKED

The Stripe secret key ships to the browserA client component imports lib/checkout.js, so the key's fallback value ends up in a public JavaScript file.
Checkout doesn't take paymentThe pricing buttons point at a placeholder, so nobody can pay.
The build passes. Nothing was pushed or deployed.

CaveatIt had no access to the Vercel project, so production environment variables went unchecked.

Input → output from the run

The code it found

// TODO: move to env before launch
const STRIPE_SECRET_KEY = process.env.STRIPE_SECRET_KEY || "sk_test_FAKE_FOR_FIXTURE";

export const PLANS = {
  plus: { price: "price_plus_monthly", label: "Plus" },
  household: { price: "price_household_monthly", label: "Household" },
};

export function checkoutUrl(plan) {
  const p = PLANS[plan];
  // Placeholder until the real Checkout session endpoint exists.
  return `/dashboard?plan=${p.price}&k=${STRIPE_SECRET_KEY.slice(0, 7)}`;
}

Verdict

Verdict: BLOCKED. Don't ship this tonight. The build passes, but the pricing page's checkout buttons don't take payment, and the code handles the Stripe secret key in a way that will leak it to the browser. I didn't deploy or push anything.

When to use it

Use when

Use before deploying, pushing or approving a release.

Skip it when

Skip it if you want it to deploy for you; it never pushes or deploys without separate permission.

The thinking behind it
Most bad deploys were visible before the push. Check tests, secrets, migrations and rollback first, and you ship knowing it's safe.

Output contract from the skill's Output section

Report release base/head and scope, commands with exit status, blockers, warnings, migrations and rollout order, config/secrets findings without values, external confirmations, rollback/roll-forward notes, and the evidence behind the verdict. Never say “safe to push” solely because type checking passed.

How it checks its own work from the instructions

Verdict is READY, BLOCKED, or NEEDS CONFIRMATION with evidence
Every command reported with its exit status
Secrets findings reported without printing values
Never calls a release safe from type checks alone

Requirements what it needs

Works in: Codex, Claude Code, Cursor
Needs: project files, terminal commands

The instructions SKILL.md · 33 lines

Instructions & references

Back to overview ↑

Package file

On this page 4 sections

Deploy check

Assess release readiness without deploying or pushing unless the user separately authorizes that action. A preflight can establish observed checks and unknowns; it cannot guarantee production safety.

Workflow

Detect repository root, workspaces, package managers, CI config, deploy target, release branch/base, and current worktree state. Do not assume origin/main exists.
Determine release scope from the merge base or deployment range. Include committed, staged, unstaged, and untracked files as separate categories. Never overwrite or discard user changes.
Run the project’s existing verification commands in the same order/configuration as CI where feasible: formatting/lint, type checks, unit/integration tests, build, and relevant smoke tests. Do not use npx to download an undeclared checker when the project already defines scripts or lockfiles.
Scan staged content and release diff for likely credentials, private keys, tokens, connection strings, and accidentally tracked environment files. Filename matching alone is insufficient. Never print a discovered secret value, even one that looks fake, test-mode, placeholder, or already exposed. Name the file, line, variable, and key type, and show at most the key prefix (for example sk_test_…). Redact values in quoted code, command output, and build-artifact excerpts too.
Review dependency and lockfile changes, runtime/engine changes, generated artifacts, and known deployment-platform constraints. Report what was inspected; do not imply a vulnerability audit unless one actually ran.
Review migrations for target, ordering, backward compatibility, lock/rewrite risk, data backfill, expand-contract sequencing, and rollback/roll-forward plan. Never casually instruct the user to run a production migration before compatible code is deployed.
Diff environment-variable references and deployment config. Classify each value as public/server-secret/build-time/runtime and mark production presence as verified only if the target environment was actually inspected.
Check user-visible docs/release notes, monitoring/alerts, feature flags, scheduled jobs, queues, and third-party dashboard changes when relevant.

Verdict

Return one of:

READY: all required checks passed and no known blocker remains;
BLOCKED: a reproducible release blocker exists;
NEEDS CONFIRMATION: automated checks passed but external state or an authorized manual step is unverified.

Output

Report release base/head and scope, commands with exit status, blockers, warnings, migrations and rollout order, config/secrets findings without values, external confirmations, rollback/roll-forward notes, and the evidence behind the verdict. Always include a rollback section: how to return to the previous deploy, and which steps (migrations, data writes, sent messages) a code rollback does not undo. Never say “safe to push” solely because type checking passed.

View on GitHub ↗