deploy-check · diff
git:20260720.e99f6c4 to git:20260807.fac9f85
19 added, 61 removed. Audit A to A.
---
name: deploy-check
- description: Run a production preflight across changes, types, secrets, migrations, dependencies, and documentation. Use when preparing to deploy or push a release.
+ description: Run a production preflight across release scope, tests, builds, secrets, migrations, dependencies, configuration, observability, and rollback. Use when deploying, pushing, or approving a release.
license: MIT
---
- Run a pre-flight check before pushing to production. Works with any stack.
-
- ## Steps
-
- ### 1. Check what's being pushed
- ```bash
- git status
- git diff origin/main...HEAD --stat
- git log origin/main..HEAD --oneline
- ```
- Show the user: "X commits, Y files about to go live." List the commit messages so they can see at a glance what's shipping.
-
- ### 2. TypeScript check (if applicable)
- Look for `tsconfig.json` in the repo. If found:
- ```bash
- npx tsc --noEmit
- ```
- Run from the directory that contains `tsconfig.json` (could be root or a `frontend/` subfolder — check first).
-
- If errors: list every error with file + line number. Do NOT recommend pushing until fixed.
- If no TypeScript in project: skip this step and note it.
-
- ### 3. Check for accidentally staged secrets
- ```bash
- git diff --cached --name-only | grep -iE '\.env|secret|key|credential|token|password'
- ```
- If ANY file matches: STOP. Warn loudly. Never let secrets get committed.
+ # Deploy check
- Also check unstaged changes:
- ```bash
- git diff --name-only | grep -iE '\.env'
- ```
+ 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.
- ### 4. Dependency / schema changes
- - Look for migration files (common patterns: `migrations/`, `schema.sql`, `*.migration.ts`, `db/migrate/`). If any changed since last commit, remind user to run migrations before deploying.
- - Check `package.json`, `requirements.txt`, `go.mod`, `Cargo.toml` — if dependencies changed, flag which ones are new so user can confirm they're available in the production environment.
- - If new environment variables appear in the diff (search for `os.getenv`, `process.env`, `ENV[`), list them and ask: are these set in your production environment?
+ ## Workflow
- ### 5. Hygiene reminders (not blockers)
- Read the commit messages and changed files, then surface these as gentle reminders:
+ 1. Detect repository root, workspaces, package managers, CI config, deploy target, release branch/base, and current worktree state. Do not assume `origin/main` exists.
+ 2. 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.
+ 3. 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.
+ 4. Scan staged content and release diff for likely credentials, private keys, tokens, connection strings, and accidentally tracked environment files. Filename matching alone is insufficient. Do not print discovered secret values.
+ 5. 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.
+ 6. 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.
+ 7. 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.
+ 8. Check user-visible docs/release notes, monitoring/alerts, feature flags, scheduled jobs, queues, and third-party dashboard changes when relevant.
- - **Changelog / release notes**: Did anything user-visible ship (new feature, fix, UI change)? If yes, remind them to update their changelog.
- - **README**: Did the setup steps, architecture, or env vars change? If yes, remind them to update the README.
- - **Docs / API docs**: If new endpoints were added, remind them to document them.
+ ## Verdict
- These do NOT block the push. Just surface them.
+ Return one of:
- ### 6. Output the verdict
+ - `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.
- **Green:**
- ```
- ✅ TypeScript: no errors
- ✅ No secrets staged
- ✅ No migrations pending
- ✅ Dependencies: no new packages
- 📝 Changelog: [reminded / not needed]
- → safe to push
- ```
+ ## Output
- **Red:**
- ```
- ❌ TypeScript: 3 errors — fix these first
- src/auth.ts:42 — Property 'user' does not exist on type 'Session'
- ⚠️ .env.local is staged — remove it before committing
- ⚠️ schema.sql changed — run migrations in prod first
- 📝 2 new env vars in diff — confirm they're set in production
- → fix blockers before pushing
- ```
+ 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.