Production Guard

The problem

code generation ≠ production correctness

A change can pass its tests, compile, look reasonable and satisfy the ticket — and still break an existing workflow, expose another tenant's data, corrupt records under concurrency, double-charge on retry, time out at real data volumes, silently swallow errors, or leave no trace of what it did at 3 AM.

What Production Guard does instead

code change  →  behavior model  →  regression model  →  failure model
   →  security / data / performance / operations
   →  execute available validation
   →  readiness report  →  ship / conditional ship / do not ship

When it activates

No slash command needed. Installed, it is loaded when a request needs it and stays out of the way otherwise — and when it does shape the work, one ⚡ line says so. How the skills work together →

Not a code review

No invented scores

The single most important rule. Production Guard never emits this:

Code quality: 94%     Security: 87%     Overall: 91%

Those numbers feel authoritative and mean nothing. It reports what it actually did:

FUNCTIONAL VALIDATION     14/14 passed
REGRESSION VALIDATION     21/23 passed
SECURITY                   8/8  passed
DATA INTEGRITY             5/6  passed
FAILURE SCENARIOS          6/9  validated
PERFORMANCE                3/4  validated
OBSERVABILITY              2/4  validated

and derives the verdict from explicit rules:

Executed vs analyzed

The other rule that makes the report trustworthy. Every check is labeled:

EXECUTED
  pytest tests/payments/ -q          →  24 passed
  npx tsc --noEmit                   →  PASS

ANALYZED (not executed)
  Behavior at 100k records           →  STATUS: UNVERIFIED
  Provider timeout handling          →  STATUS: UNVERIFIED — no sandbox creds

Reasoning is legitimate evidence — reading a loop is enough to prove a missing transaction. Presenting reasoning as an observed test result is not. A failure scenario only gets an actual result when it was actually exercised.

Example output

Abbreviated, from the bulk-deletion example:

CHANGE    Add bulk deletion to user management.
RISK      High — destructive, multi-record, irreversible.
VERDICT   🔴 DO NOT SHIP
BLOCKERS  2   HIGH 2   MEDIUM 1   LOW 1

🔴 #1 Authorization is checked once for the actor, never per target.

   Evidence:  BulkDeleteController.php:34 authorizes once, then deletes every
              id in the request body. The single-delete path checks per record.
   Risk:      A team admin can delete users outside their team by supplying
              their ids. The UI never offers them; the ids come from the body.
   Confidence: High — observed, a test posting a foreign id deleted it.

🔴 #2 Partial failure leaves the operation half-applied with no record.

   Evidence:  BulkDeleteService.php:28-41 commits per item inside a loop.
   Risk:      Failure at item 47 of 100 leaves 46 deleted, 1 failed and 53
              untouched. The client cannot tell which, and retrying deletes
              an arbitrary further subset.

Five full worked reports ship with the skill: payment, bulk operation, API change, database migration, and authentication. One ends in 🟢 SHIP deliberately — a gate that never passes anything is not a gate.

Risk-based depth

Not every change earns every check. The skill classifies first.

Install

Any Agent Skills-compatible agent

Claude Code

Using it

• “Is this change safe to ship?”
• “Run a production readiness check on the bulk delete feature.”
• “Validate this before I merge it — it touches payments.”
• “What breaks in production if I ship this?”

Safety

Production Guard runs your project's own checks where it can — targeted tests first, then type checks, lint, integration tests and build. It establishes a baseline first, so a pre-existing failure is never blamed on your change, and it states the scope of what it ran rather than implying a full suite.

It will not drop databases, reset environments, delete data, destroy containers, rewrite git history, force push, deploy, or touch production-like systems. It reads git state and never modifies it — no commits, no resets, no stashing.

Pairs with Impact Map

ticket  →  impact-map  →  implement  →  production-guard  →  ship

Impact Map runs before implementation and maps what a change will touch. Production Guard runs after and validates that what was built is safe to ship. Neither requires the other.

Limitations

Production Guard improves the evidence available before shipping. It does not guarantee production safety, and no tool that reads your code can.

• Dynamic runtime behavior can be hidden — reflection, dynamic dispatch, runtime configuration and feature flags defeat static reasoning
• External systems are often unavailable locally, so integration behavior is reasoned rather than observed
• Production traffic differs from local tests — concurrency, data volume and infrastructure limits usually cannot be reproduced
• Static analysis cannot prove completeness; an absent finding is not proof of absence
• AI reasoning can miss dependencies, particularly indirect ones
• Unexecuted checks are not equivalent to executed ones — which is exactly why the report labels them separately
• The verdict is advisory. A human owns the release decision.