production-audit

Trigger phrases

Phrases that activate this skill when typed to Claude Code:

• is this app production-ready
• what would break in prod
• audit this repo before launch

What it does

production-audit is the local-evidence production-readiness skill in Affaan M’s everything-claude-code — see skills/production-audit. It’s a maintainer-safe rewrite of the original community production-audit idea: keeps the production-readiness lens, removes the unpinned external execution and third-party data sharing the original required. Repo contents stay local unless the operator explicitly approves a specific external tool and its data flow.

The five-step flow: establish the release surface, read recent changes and current branch state, inspect runtime / auth / data / payment / background-job / AI / deployment boundaries that actually exist in the repo, check CI / tests / migrations / environment documentation / rollback path, produce a short ship/block recommendation with specific fixes. Cheap local signals come first — git status --short --branch, git log --oneline --decorate -20, git diff --stat origin/main...HEAD.

Risk lenses covered: security and auth (public vs admin route separation, server-side enforcement, secrets out of bundles / logs / checked-in files, rate limits / CSRF / CORS / upload validation, AI surface defense against prompt injection and tool abuse), data integrity (migrations forward-clean with rollback, idempotent retries, tenancy boundaries match service-role grants), payments and webhooks (signature verification before parsing trusted fields, idempotent fulfillment per webhook). The skill is explicit that it’s not a compliance audit — it’s engineering triage, not legal / financial / medical / regulatory certification.

When to use it

• Operator asks “is this production-ready”, “what would break in prod”, “what did we miss”, or “ready to ship?”
• A feature was merged and needs a pre-deploy or post-merge risk pass
• A public launch, demo, customer rollout, or investor walkthrough is close
• CI is green but the operator wants production risk, not just test status
• A deployed URL, release branch, PR, or current checkout is available for evidence gathering

When not to reach for it:

• Active implementation — that’s security-review for line-level secure coding
• Pure libraries / templates / docs-only repos / scaffolds — unless the operator wants packaging/release readiness specifically
• Formal compliance audits — engineering triage isn’t legal certification
• Pre-implementation product ideas — no repo, no deployment, no runtime surface to audit

Install

From affaan-m/everything-claude-code at skills/production-audit/. Drop the folder into ~/.claude/skills/production-audit/. The skill is a workflow + risk-lens checklist; no extra MCP server or installed scanner required. The operator must explicitly approve any external scanner (Snyk, Semgrep, dependabot beyond what’s already wired) before the skill calls it — the default is local-only evidence.

What a session looks like

1. Establish the release surface. What’s deploying — a feature branch, a release tag, a hotfix? Is there a deployed URL in scope?
2. Cheap local signals first. git status --short --branch, git log --oneline --decorate -20, git diff --stat origin/main...HEAD. Surfaces the recent change set without reading the whole repo.
3. Inspect existing boundaries. Package scripts, CI workflows, release scripts, Docker files, deployment manifests. API routes, webhooks, auth middleware, background workers, cron jobs, database migrations. Skip what doesn’t exist — the audit is shaped by the repo, not by a checklist demanding artifacts the repo doesn’t have.
4. Apply risk lenses. Security and auth (route separation, server-side enforcement, secrets handling). Data integrity (migrations + rollback, idempotent retries). Payments and webhooks (signature verification, fulfillment idempotency). AI / agent boundaries (prompt injection defense, tool-abuse guards).
5. Check the deploy plumbing. Env var docs, startup checks, observability hooks, error reporting, health checks, rollback / seed / backfill instructions, E2E coverage for the user paths that matter.
6. Emit the verdict. Short ship/block recommendation. Specific fixes — not “improve security” but “the /api/admin/* routes don’t check role server-side; add the middleware before deploy.” Each finding linked to where the evidence came from.

The discipline that makes it work: local-evidence default. The skill is explicit that uploading repo contents to a third-party scanner or running unpinned remote code requires operator approval per-tool, per-data-flow. The audit is engineering triage from what’s actually in the checkout, not a polished compliance theater.

Receipts

TODO — to be filled in from a real session. Once the audit has been run on a real pre-launch codebase, this section will capture: which risk lens turned up the most findings (the upstream suggests security-and-auth is usually heaviest), whether the local-evidence default caught issues a third-party scanner would’ve missed (or vice-versa), the specific ship/block verdict and which one finding was decisive, and whether the AI / agent boundary lens applied to the project or was empty (most projects don’t have agent surfaces yet — when they do, the lens is unusual and worth documenting).

Source and attribution

From Affaan M’s everything-claude-code — an MIT-licensed skill collection covering harness construction, agent ops, video, payments, and platform-specific patterns.

License: MIT.

Quoting the local-evidence rule verbatim: “Build the audit from local and user-authorized evidence. Do not run unpinned remote code, upload repository contents to third-party services, or call external scanners unless the user explicitly approves that specific tool and data flow.” That’s the wedge — most production audits today involve uploading source to a SaaS, the skill insists on local-first with explicit operator consent per tool.