Shipping

The gate exists because the expensive failures are boring: a secret committed, a type error nobody ran, a deploy from a dirty tree.

Before anything else, check for secrets

This runs first because it is the only step that cannot be undone after the fact. A key pushed to a public repo is compromised the moment it lands, and deleting the commit does not recall it.

git diff --cached --name-only | grep -E '^\.env|\.env\.' && echo "STOP: .env staged"
git diff --cached | grep '^+' | grep -iE '(sk-ant|sk-[a-z0-9]{20}|api[_-]?key|secret|password|token)=' \
  | grep -viE 'example|placeholder|your_|process\.env\.|os\.environ' | head

If a real secret appears: stop, unstage it, tell the user plainly, and do not continue. Do not offer to "be careful" with it.

The gate

Detect the project rather than assuming. package.json means Node, pyproject.toml or requirements.txt means Python, and both means run both.

Run typecheck, lint, and tests, in that order, because a type error makes lint output noise and a lint failure makes a test run a waste of time. Use the project's own scripts (npm run typecheck) before reaching for a global tool, since a project pins its versions for a reason and a different major version locally lets CI-only failures through.

Report what actually happened. If tests fail, show the output. If a step was skipped because the script does not exist, say which. "Quality gate passed" after a skipped test run is the single most damaging sentence available here, because it is believed.

Writing tests

When asked to write tests, cover the case that was actually broken, not the happy path that already worked. A test that passes before and after the fix pins nothing. Mirror the suite's existing harness and helpers rather than inventing a parallel mock style in the same file, and name the test after the scenario, not the implementation.

Deploying

Before production: the gate passes clean, no .env staged, no hardcoded localhost, no debug logging left in a hot path, environment variables set in the host dashboard rather than only locally. Check the mobile view at 375px if there is a UI.

After: open the URL, run the primary flow once, and read the function logs. A deploy that returned success and a page that renders are different claims.

Many hosts deploy on push. Pushing and then running a deploy command again is how a double deploy or a rollback race happens, so know which the project does before doing both.

Pushing

Commit messages explain why, in prose, like a person wrote them. No bullet-list changelog for a three-line change, no "enhanced" or "robust".

If on the default branch and the change is not trivial, branch first. Never force push over a branch someone else may have pulled without saying so out loud.