# Skill: Run a production-readiness audit before launching a project to real users

> Use this skill when a project is about to go live -- or just did -- to verify that "works on my machine" gaps (security, payments, data rollback, cold-start, mobile) will not cause failures in production.

Source: sodigi-learn -- vibecoding/gotov-li-k-lyudyam - https://sodigi.io/learn/vibecoding/gotov-li-k-lyudyam

## When to use
- Before turning on any public traffic or ads for the first time.
- After a significant code change that touches auth, payments, or database schema.
- When the developer has only tested on their own device and never on a clean server or a phone.
- When you need a clear go / no-go verdict, not just "tests are green."

## Core rules
- Green tests are not a readiness signal -- tests prove the code does what it was meant to do, not that prod will survive real users.
- Always check server-side access control -- hiding a UI element is not security.
- Secrets (API keys, passwords, tokens) must never appear in browser-visible code or logs.
- Every payment flow must handle duplicate notifications without charging twice (idempotency).
- Before every launch there must be a tested rollback path -- not a plan, a practiced procedure.
- Database migrations must be reversible; verify this before shipping.
- The project must start from scratch on a clean server by following the written instructions alone.
- Half of visitors arrive on a phone -- test core flows on mobile, not just on a desktop.
- Demand a named verdict (Blocked / Risky / OK with caveats / Confident) plus a list of exactly what was checked.

## Procedure
1. Identify what changed and what is being shipped to production.
2. Check security: is access enforced on the server? Are secrets absent from client-visible code?
3. Check payments: can a duplicate payment notification result in a double charge or double delivery?
4. Check data: can the latest migration be reversed if it corrupts data?
5. Check cold start: does the project start on a clean server by following only the written docs?
6. Check mobile: do all main flows and forms work on a phone screen?
7. Return a verdict (Blocked / Risky / OK with caveats / Confident) and a blockers list sorted by priority.
8. List every file and section that was actually checked -- a verdict without a checklist is guesswork.

## Ready-to-use prompt
```
Run a readiness audit on my project for launching to real users.
Do not treat green tests as production readiness.

Check in this order and state plainly whether each item is OK or not:
1. Security -- is access verified server-side, not just by a hidden button?
   Are any secrets visible in browser-accessible code?
2. Payments -- if payments exist, what happens if a notification arrives twice?
   Can a user be charged or receive an item twice?
3. Data -- can database migrations be rolled back if the new version corrupts data?
4. Cold start -- will the project start on a clean server following only the written instructions?
5. Mobile -- do the main flows and forms work on a phone?

End with a clear verdict: Blocked / Risky / OK with caveats / Confident.
List the blockers by priority. List exactly which files and sections you checked.
```

## Pitfalls
- Treating passing tests as production clearance -- tests and prod readiness are different questions.
- Launching without a rollback path -- when something breaks (not if), no rollback means catastrophe.
- Relying on UI-level access control -- a hidden button is bypassed in seconds; verify on the server.
- Hardcoding secrets in source code -- keys in page code are visible to anyone.
- Skipping idempotency in payments -- a duplicate webhook equals a double charge.
- Testing only on your own large monitor -- a form that is unreachable on mobile is a form nobody fills in.
- Accepting a verdict with no list of what was checked -- that is a guess wearing an audit badge.