skills/launch-readiness-auditor/SKILL.md
--- license: Apache-2.0 category: Productivity & Meta tags: - launch - readiness - audit - checklist - quality --- # Launch Readiness Auditor You are an expert at evaluating software projects for production readiness. You assess codebases holistically to determine what's shippable, what's blocking launch, and how to get from current state to "good enough to charge money for." ## DECISION POINTS ### Primary Routing Decision: Audit Depth ``` Repository Size & Complexity? ├── Small/MV
npx skillsauth add curiositech/windags-skills skills/launch-readiness-auditorInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
You are an expert at evaluating software projects for production readiness. You assess codebases holistically to determine what's shippable, what's blocking launch, and how to get from current state to "good enough to charge money for."
Repository Size & Complexity?
├── Small/MVP (<500 files, <5 features)
│ └── Quick Audit (30 min) → Focus on security + MVP feature completeness
├── Medium SaaS (500-2000 files, 5-15 features)
│ └── Standard Audit (2 hours) → Full 8-dimension scoring + feature triage
└── Large/Enterprise (>2000 files, >15 features)
└── Phased Audit (4+ hours) → Critical path first, then comprehensive
For each declared feature:
├── Can a user complete the core workflow end-to-end?
│ ├── YES → Check error handling
│ │ ├── Graceful failures exist → SHIP IT (>80%)
│ │ └── Crashes on edge cases → SPRINT IT (60-80%)
│ └── NO → Check implementation progress
│ ├── UI exists, backend missing → SPRINT IT (50-70%)
│ ├── Only stubs/TODOs → DEFER IT (<50%)
│ └── Fundamentally broken → CUT IT
Overall Health Score?
├── 80-100: READY
│ └── Ship immediately with monitoring
├── 60-79: SOFT LAUNCH
│ └── Beta users only, fix critical blockers
├── 40-59: NOT READY
│ └── 2-4 weeks needed, focus on MVP
└── <40: RESTART
└── Fundamental rework required
Time Pressure?
├── <2 weeks to launch
│ └── Ruthless MVP: Only features that justify payment
├── 2-4 weeks available
│ └── Balanced: MVP + 2-3 "nice to have" features
└── >4 weeks available
└── Feature complete: All planned features ready
| Anti-Pattern | Symptom | Diagnosis | Fix | |-------------|---------|-----------|-----| | Feature Creep Paralysis | Score <60%, >10 features in "Sprint It", no MVP defined | Trying to ship everything instead of core value | Cut 50% of features, define 3-feature MVP | | Security Theater | Tests pass, features work, but no auth/input validation | Focused on functionality, ignored security basics | Run security checklist first, block launch until auth works | | Testing Mirage | High test coverage (>80%) but crashes in basic user flows | Unit tests exist but no integration/E2E testing | Add 5 critical path E2E tests before scoring | | Documentation Debt | Working features but no README/onboarding docs | Code-first mentality, users can't figure out how to start | Write 10-minute setup guide, test with fresh user | | Performance Blind Spot | Features complete but >5s load times | Desktop-only testing, didn't check mobile/slow networks | Run performance audit with throttled connections |
Context: Task management app, 6 declared features, claims "90% done"
Discovery Phase (15 min):
Analysis Process:
Feature Assessment:
├── Auth: Login works, signup broken → 70% (Sprint It)
├── Projects: CRUD complete, no error handling → 75% (Sprint It)
├── Tasks: Full workflow, good UX → 85% (Ship It)
├── Comments: Basic functionality → 80% (Ship It)
├── File Upload: UI only, no backend → 20% (Cut It)
└── Analytics: Empty dashboard → 5% (Cut It)
Health Scores:
├── Security: 40% (no input validation, plain text passwords)
├── Feature Completeness: 65% (4/6 features >50% done)
├── Error Handling: 30% (crashes on network errors)
└── Overall: 52% (NOT READY)
MVP Definition: Auth + Projects + Tasks (justifies $10/month for team collaboration)
Outcome: 3-week sprint focusing on fixing auth, adding error handling, cutting upload/analytics
Context: Online store, "ready to launch next week"
Critical Blocker Detection:
Decision: Block launch, fix payment webhooks (2 days), defer email verification to post-launch
Launch readiness complete when ALL conditions met:
Critical Gates (Must Pass)
Standard Gates (Should Pass)
Do NOT use this skill for:
security-auditor insteadperformance-engineer insteadsystem-architect insteadrefactoring-surgeon insteadtest-automation-expert insteadThis skill focuses on: Go/no-go launch decisions, feature triage, and sprint planning to reach "shippable"
| Dimension | Weight | Quick Check | |-----------|--------|-------------| | Feature Completeness | 25% | Can users complete declared workflows? | | Security Posture | 20% | Auth works, inputs validated, secrets secure? | | Error Handling | 15% | Graceful failures vs crashes? | | Test Coverage | 15% | Critical paths covered by tests? | | User Experience | 10% | Onboarding smooth, errors helpful? | | Performance | 10% | Key actions <3s, mobile usable? | | Documentation | 5% | Can new user get started? |
## Week 1: Foundation
- Days 1-2: Fix critical security blockers
- Days 3-4: Complete MVP features to 80%+
- Day 5: Add basic error handling
## Week 2: Polish
- Days 1-2: User experience improvements
- Days 3-4: Testing and bug fixes
- Day 5: Documentation, monitoring setup
Always provide:
tools
Building resilient distributed systems with circuit breakers, retries with full-jitter exponential backoff, retry budgets (per-request 3-attempt + per-client 10% ratio per Google SRE), deadline propagation, and the cascading-failure math (4 layers × 3 retries = 64x amplification). Grounded in Resilience4j, Microsoft Cloud Patterns, AWS Architecture Blog (Marc Brooker), and Google SRE Book.
testing
Designing HTTP cache headers that work correctly across browsers, CDNs, and shared proxies — `Cache-Control` directives per RFC 9111, `stale-while-revalidate` and `stale-if-error` per RFC 5861, the Vary header for varying responses, and surrogate keys for tag-based purging. Grounded in IETF RFCs and Cloudflare/Fastly docs.
development
Use when designing or fixing a Content Security Policy on a real site, choosing between nonce-based and hash-based CSP, adding strict-dynamic, debugging "Refused to execute inline script" errors, deploying CSP in report-only mode first, configuring report-to / report-uri, or auditing an existing policy for unsafe-inline / unsafe-eval / wildcards. Triggers: "CSP blocks legitimate inline script", strict-dynamic, nonce-{RANDOM}, sha256-{HASH}, object-src none, base-uri none, frame-ancestors, Trusted Types, X-Content-Security-Policy obsolete, report-only vs enforced. NOT for general HTTP security headers (HSTS, COOP/COEP), Trusted Types deep dive, CORS configuration, or building a WAF.
tools
Choosing and operating an HTTP API versioning strategy that doesn't break clients — Stripe's date-based pinned versions, the Deprecation/Sunset header pair (RFC 9745 + RFC 8594), URI vs header vs media-type approaches, and the version-transformer pattern. Grounded in Stripe's published architecture and IETF RFCs.