kbwen / production-readiness
Use at review and ship, automatically for feature or architecture changes and on request for error handling, logging, crash reporting, or observability; verify errors reach production monitoring.
Production Readiness
Overview
Code that passes all tests but logs errors only via debug-only APIs (e.g., debugPrint, console.log in debug mode) is functionally silent in production. This skill enforces observability readiness before ship — ensuring the team is not blind during beta testing and production rollout.
When to Use
- Auto-recommended for
featureandarchitecture-changeclassifications. - Activate manually when working on error handling, crash reporting, or logging infrastructure.
- Apply at
/review(semantic error check) and/ship(readiness checklist).
Observability Checklist
1. Error Surface Audit (at /review)
For every catch / error-handling block in changed files:
| Check | Pass | Fail |
|---|---|---|
| Logging call exists | Logger.error(), log.error(), crashReporter.capture() | Empty catch {} |
| Logger is production-observable | Framework logger, crash reporter, structured stdout | debugPrint(), print(), debug-only console.log |
| Error context is actionable | Includes error type, operation, identifiers | "error occurred", raw exception only |
2. Log Sink Documentation (at /ship)
Document in Work Log where production errors go:
## Observability
- Error sink: [e.g., Sentry via Logger.error(), Crashlytics, stdout → CloudWatch]
- Health check: [e.g., /health endpoint, Firebase Vitals, uptime monitor]
- Rollback signal: [e.g., error rate > 2x baseline → revert]If the project has no production logging infrastructure, document as Known Risk:
"No production error reporting configured. Errors in catch blocks will be logged to stdout only. Risk: silent failures in release builds if stdout is not monitored."
3. Rollback Telemetry (at /ship)
The rollback plan (per engineering_guardrails.md §12.5) must answer:
- How will operators know the rollback is needed? (alert, dashboard, manual check)
- How will operators know the rollback succeeded? (error rate drops, health check passes)
Heading-Scoped Read Note
For phase-entry loading, read only:
When to UseObservability Checklist
Load What This Skill Does NOT Cover, Anti-Patterns, and Interaction with Other Skills on full read or cache miss only.
What This Skill Does NOT Cover
- Tool selection: Sentry vs Crashlytics vs Datadog — team/project decides.
- Alert thresholds: When to page on-call — SRE/ops owns this.
- Dashboards: What to visualize — team preference.
- Post-deploy monitoring: This is a pre-ship readiness check, not an ops workflow.
Anti-Patterns
| Anti-Pattern | Why It Fails | Fix |
|---|---|---|
catch (e) { debugPrint(e); } | Tree-shaken in release build | Use production logger |
catch (e) { /* TODO: add logging */ } | Silent catch escapes review | Add logging now, not later |
Logger.error("error") without context | Useless in production triage | Include operation, identifiers, error type |
| Logging to local file only | Not observable in cloud/mobile | Use centralized error reporting |
Interaction with Other Skills
- systematic-debugging: Complements — debugging finds bugs, production-readiness ensures they're visible when they happen again.
- verification-before-completion: Works alongside — verification checks correctness, production-readiness checks observability.
- auth-security: Security errors are especially critical to observe in production. §5.2a applies with elevated priority to auth error paths.