---
name: production-readiness
description: 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 `feature` and `architecture-change` classifications.
- 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 Use`
- `Observability 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.