app-readiness-audit
Skill1 starsChanged 9 days agoMITView on GitHub
Audit an application before launch for mobile support, secret keys, database safety, rate limiting, password reset, rollbacks, backups, usage limits, analytics, input sanitizing, error handling, log flow and monitoring/alerts. Use when asked to check if an app is production-ready, do a launch review, or find security and reliability gaps. Use proactively, without being asked, before you tell the user a feature or app is ready to ship.
In this repository8 other files it gives its agents.
- skills/zero-trust-review/references/agents.mdAGENTS.md
- api-security-guardSkill
- build-flow-mapSkill
- monitor-alerts-builderSkill
- motionsiteSkill
- session-journalSkill
- skeletonizerSkill
- zero-trust-reviewSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 4 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- could be automatic: a setting could enforce it
- Distinctive: line 10
Runs on its own: before Claude calls a feature or app ready to ship, it skims the change against these areas and fixes what it broke.
- Very specific: line 39
Add --format json if you want to process it.
- Distinctive: line 52
Never paste a real secret into the report or chat.
- Distinctive: line 53
If you find a committed live secret, say it must be rotated, not just removed from the file, because git history keeps it.
- Distinctive: line 54
Do not run load tests, port scans, or exploit attempts against anything you do not own.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
App Readiness Audit
Checks a codebase against 13 launch-readiness areas and produces an evidence-based report with a fix list. It reads the code; it does not attack a live system.
Runs on its own: before Claude calls a feature or app ready to ship, it skims the change against these areas and fixes what it broke. A full audit still runs when you ask.
What it covers
| # | Area | Question it answers |
| 1 | Mobile | Does it work on phones (responsive web, PWA, or native build config)? |
| 2 | Secret keys | Are keys out of the code, out of git, rotatable, and not shipped to the browser? |
| 3 | Database | Constraints, indexes, least-privilege user, migrations, connection limits? |
| 4 | Rate limiting | Are login, signup, reset, and expensive endpoints throttled? |
| 5 | Password reset | Single-use, expiring, hashed tokens; no account enumeration? |
| 6 | Rollbacks | Can a bad deploy or migration be undone quickly? |
| 7 | Backups | Automated, off-site, encrypted, and restore-tested? |
| 8 | Usage limits | Per-user quotas, upload/size caps, cost caps on paid APIs? |
| 9 | Analytics | Are key events tracked without leaking personal data? |
| 10 | Input cleaning | Server-side validation, output encoding, upload checks? |
| 11 | Error handling | Safe messages to users, full detail in logs, no stack traces leaked? |
| 12 | Log flow | Structured logs, request IDs, no secrets in logs, retention? |
| 13 | Monitor and alerts | Someone is told within minutes when it breaks? (build with monitor-alerts-builder) |
The criteria, how to verify each one, and severity guidance are in references/checklist.md. Read it before judging.
Procedure
- Scope. Identify the stack and what the app does (web, mobile, API, worker). Ask only if you cannot tell from the repo. Note what is out of reach (production infra, cloud console, third-party dashboards) so those items are marked UNKNOWN rather than guessed.
- Run the scanner for fast evidence (it is heuristic, so treat hits as leads, not verdicts):
Addpython3 <skill-dir>/scripts/scan.py <project-root> --format markdown > /tmp/readiness-scan.md--format jsonif you want to process it. The scanner never prints full secret values. - Verify by reading code. For every area, open the real files behind the scanner's leads and look for what the scanner cannot see: is the rate limiter actually applied to the login route, does the reset token get invalidated after use, does the backup have a restore test. Use
references/checklist.mdas the guide. - Rate each area with one of:
PASSevidence shows it is handledWARNpartly handled or handled inconsistentlyFAILmissing or clearly brokenUNKNOWNcannot be determined from the repo (say what to check and where)
- Report using
references/report-template.md. Order fixes by severity: anything that can leak data or take over accounts first, then data loss, then abuse and cost, then polish. - Offer to fix, one finding at a time, and re-run the scanner after fixes.
Rules
- Report only what you saw in the files. Quote the path and line for each finding.
- Never paste a real secret into the report or chat; show the first 4 characters and the file location.
- If you find a committed live secret, say it must be rotated, not just removed from the file, because git history keeps it.
- Do not run load tests, port scans, or exploit attempts against anything you do not own.
- A passing scan is not a security audit. Say so in the report summary.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.