Use when performing production readiness review — production readiness checklist covering scalability, reliability, observability, security, operational maturity, and documentation. Use before promoting a service to production or during periodic production-readiness audits.
Scanned 9/8/2026
Install to Claude Code
npx -y skills add cloudthinker-ai/CloudSkills --skill production-readiness-review --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Production Readiness Review?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/cloudthinker-ai-production-readiness-review)More formats (shields.io, HTML) on the badges page.
---
name: production-readiness-review
enabled: true
description: |
Use when performing production readiness review — production readiness
checklist covering scalability, reliability, observability, security,
operational maturity, and documentation. Use before promoting a service to
production or during periodic production-readiness audits.
required_connections:
- prefix: github
label: "GitHub (for repo review)"
config_fields:
- key: service_name
label: "Service Name"
required: true
placeholder: "e.g., order-service"
- key: team
label: "Owning Team"
required: true
placeholder: "e.g., platform-team"
- key: target_date
label: "Target Production Date"
required: false
placeholder: "e.g., 2026-04-01"
features:
- DEPLOYMENT
- SRE
---
# Production Readiness Review Skill
Evaluate production readiness for **{{ service_name }}** owned by **{{ team }}**.
## Workflow
### Step 1 — Service Overview
Gather service context:
1. **Service**: {{ service_name }}
2. **Team**: {{ team }}
3. **Target date**: {{ target_date | "TBD" }}
4. **Architecture**: [microservice / monolith / serverless / hybrid]
5. **Dependencies**: [upstream and downstream services]
6. **Expected traffic**: [requests/sec, peak patterns]
### Step 2 — Reliability & Availability
```
RELIABILITY
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] SLO defined (availability, latency, error rate)
[ ] Error budget policy documented
[ ] Multi-AZ or multi-region deployment
[ ] Health check endpoints implemented (liveness + readiness)
[ ] Graceful shutdown handles in-flight requests
[ ] Circuit breakers on all downstream dependencies
[ ] Retry logic with exponential backoff and jitter
[ ] Timeout configured on all outbound calls
[ ] Rate limiting on inbound requests
[ ] Load tested at 2x expected peak traffic
```
### Step 3 — Scalability
```
SCALABILITY
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Horizontal autoscaling configured (HPA / ASG)
[ ] Resource requests and limits set (CPU, memory)
[ ] Database connection pooling configured
[ ] Caching strategy defined and implemented
[ ] Stateless design (no local session state)
[ ] Async processing for long-running operations
[ ] Database queries optimized (no N+1, proper indexes)
[ ] CDN configured for static assets (if applicable)
```
### Step 4 — Observability
```
OBSERVABILITY
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Structured logging with correlation IDs
[ ] Metrics emitted: request rate, error rate, latency (RED)
[ ] Metrics emitted: utilization, saturation, errors (USE) for resources
[ ] Distributed tracing instrumented
[ ] Dashboard exists with key service metrics
[ ] Alerts configured for SLO violations
[ ] Alerts configured for resource exhaustion
[ ] Log aggregation and retention configured
[ ] On-call runbook linked in alerting tool
[ ] Dependency health visible in dashboard
```
### Step 5 — Security
```
SECURITY
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Authentication required on all endpoints (or explicitly public)
[ ] Authorization checks enforce least privilege
[ ] Input validation on all user-facing inputs
[ ] No secrets in code, environment variables use secrets manager
[ ] Container image scanned for vulnerabilities
[ ] Dependencies scanned for known CVEs
[ ] Network policies restrict pod-to-pod communication
[ ] TLS on all internal and external communication
[ ] Security review completed by security team
```
### Step 6 — Operational Maturity
```
OPERATIONS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] CI/CD pipeline with automated tests
[ ] Deployment rollback procedure tested
[ ] On-call rotation assigned and staffed
[ ] Incident response runbook documented
[ ] Disaster recovery plan with tested RTO/RPO
[ ] Backup and restore procedure tested
[ ] Capacity planning reviewed for next 6 months
[ ] Feature flags for risky functionality
[ ] Canary or blue-green deployment strategy
[ ] Chaos testing performed (at least failure injection)
```
### Step 7 — Documentation
```
DOCUMENTATION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Architecture diagram current
[ ] API documentation (OpenAPI / gRPC proto)
[ ] Data model and schema documentation
[ ] Runbook for common operational tasks
[ ] On-call escalation path documented
[ ] Dependency map with SLAs
[ ] Change log maintained
```
### Step 8 — Readiness Verdict
| Category | Score | Status |
|----------|-------|--------|
| Reliability | X/10 | READY / NOT READY |
| Scalability | X/8 | READY / NOT READY |
| Observability | X/10 | READY / NOT READY |
| Security | X/9 | READY / NOT READY |
| Operations | X/10 | READY / NOT READY |
| Documentation | X/7 | READY / NOT READY |
**Verdict**: APPROVED / CONDITIONAL / BLOCKED
- **APPROVED**: All categories READY (≥80% items passed)
- **CONDITIONAL**: Minor gaps with documented risk acceptance and remediation plan
- **BLOCKED**: Critical gaps that must be resolved before production
## Counter-Rationalizations
| Shortcut | Counter | Why |
|----------|---------|-----|
| "We can skip some steps for this case" | Adapt the workflow steps, don't skip them | Skipped steps are where incidents and oversights originate |
| "The user seems to already know what to do" | Complete all workflow phases with the user | The workflow catches blind spots that experience alone misses |
| "This is a minor case, full process is overkill" | Scale the process down, don't turn it off | Minor cases become major when unstructured; the process scales, not disappears |
| "I'll fill in the details later" | Complete each section before moving on | Deferred details are forgotten; real-time capture is more accurate |
| "The template output isn't necessary" | Always produce the structured output format | Structured output enables comparison, audit trails, and handoff to other teams |
## Output Format
Produce a production readiness report with:
1. **Service overview** (name, team, architecture, dependencies)
2. **Category checklists** with PASS/FAIL per item
3. **Readiness matrix** with per-category scores
4. **Verdict** with justification
5. **Action items** for any gaps, with owner and due date
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!