oc-monitoring-ops

# Monitoring Ops

**On first invocation, read `references/orchestrator.md` and follow its welcome protocol.**

Post-deployment observability skill. Deploy-ops ships the code; oc-monitoring-ops
watches it run. Covers five domains: uptime monitoring, error tracking, structured
logging, alerting pipelines, and incident response.

This skill does NOT build features or deploy code — it instruments what's already
deployed and establishes the feedback loop that catches problems before users report them.

## /oc-monitor — Command Reference

```
MONITORING OPS COMMANDS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  SETUP
  /oc-monitor setup         Guided observability stack setup for a project
  /oc-monitor stack         Recommend monitoring tools for the stack
  /oc-monitor instrument    Add structured logging + error capture to codebase

  OBSERVE
  /oc-monitor health        Live health check — hit endpoints, report status
  /oc-monitor errors        Check error tracking service for recent issues
  /oc-monitor uptime        Show uptime status and recent incidents
  /oc-monitor metrics       Key metrics snapshot (latency, error rate, throughput)
  /oc-monitor status        Current monitoring state from checkpoint

  ALERT
  /oc-monitor alerts        Design or audit alerting rules
  /oc-monitor oncall        Set up on-call rotation and escalation
  /oc-monitor slo           Define or review SLOs/SLIs/error budgets

  RESPOND
  /oc-monitor incident      Start or review an incident response
  /oc-monitor runbook       Generate or update operational runbooks
  /oc-monitor postmortem    Structured post-incident review

  REPORT
  /oc-monitor dashboard     Design an ops monitoring dashboard (routes to oc-dash-forge)
  /oc-monitor report        Generate weekly/monthly ops report
  /oc-monitor audit         Full observability maturity assessment
  /oc-monitor compare       Compare two monitoring snapshots (drift detection)

  SESSION
  /checkpoint            Show checkpoint status
  /checkpoint show       Display full checkpoint JSON
  /checkpoint reset      Archive and restart

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  Type any command to begin. /oc-monitor to see this again.
```

---

## Session Persistence (Checkpoint Protocol)

Checkpoint: `{project-dir}/.checkpoints/oc-monitoring-ops.checkpoint.json`

### Resume on Start

When any `/oc-monitor` command is invoked:
1. Check for checkpoint
2. If exists: show tier, tools, SLO status, active incidents, maturity grade, next action
3. Ask: "Continue, restart, or show full checkpoint?"
4. On continue: load context, resume from `next_actions[0]`

### What's Tracked

Monitoring-ops uniquely stores **runtime state** alongside pipeline progress — the last
health check result, active incident count, and SLO budget consumption. This means the
checkpoint serves double duty: session persistence AND operational snapshot.

---

## How This Skill Fits the Pipeline

```
oc-reverse-spec → oc-app-architect → oc-git-ops → oc-deploy-ops → MONITORING-OPS
                                                            │
                                              ┌─────────────┤
                                              │             │
                                         oc-security-auditor   oc-scale-ops
                                         (detection/        (perf
                                          response input)    budgets)
```

**oc-deploy-ops ships it, oc-monitoring-ops watches it.** The handoff:

1. oc-deploy-ops completes production promotion
2. oc-deploy-ops runs health check (basic HTTP 200 verification)
3. If oc-monitoring-ops checkpoint exists: oc-monitoring-ops takes over ongoing observation
4. If not: oc-deploy-ops suggests `/oc-monitor setup` for the project

oc-deploy-ops's health check is a one-shot verification. oc-monitoring-ops provides
continuous observation, error aggregation, alerting, and incident coordination.

### Cross-Skill Connections

| Skill | Relationship |
|---|---|
| **oc-deploy-ops** | Upstream. oc-deploy-ops ships → oc-monitoring-ops watches. Shares health check URLs, environment config. |
| **oc-security-auditor** | Peer. oc-security-auditor's Pillar 3 (detection/response) maps directly to oc-monitoring-ops's alerting + incident response. oc-security-auditor defines WHAT to detect; oc-monitoring-ops implements HOW to detect it. |
| **oc-scale-ops** | Peer. oc-scale-ops sets performance budgets; oc-monitoring-ops enforces them via alerting. Latency SLOs from oc-scale-ops become oc-monitoring-ops alert thresholds. |
| **oc-code-auditor** | Upstream consumer. oc-code-auditor's `/oc-audit pre-deploy` findings can include "missing error handling" — oc-monitoring-ops's `/oc-monitor instrument` addresses the gap at the observability layer. |
| **oc-app-architect** | Upstream. Reads spec for expected behaviors, user flows, and error handling strategy to inform what to monitor. |
| **oc-dash-forge** | Downstream for visualization. `/oc-monitor dashboard` routes to oc-dash-forge with an ops archetype context for monitoring UI design. |

---

## Observability Maturity Model

Every project maps to a maturity tier. The setup wizard determines the tier from
the project's scale, sensitivity, and infrastructure.

| Tier | Name | Who | What's Covered | Example |
|---|---|---|---|---|
| **T0** | Bare Minimum | Solo dev, personal app | Health endpoint + basic logging + crash alerts | aidops apps on free tier |
| **T1** | Foundations | Small team, internal tool | T0 + error tracking + uptime monitoring + structured logs | PenThreshold |
| **T2** | Production | Multi-user product, SLA exists | T1 + SLOs + alerting pipeline + runbooks + dashboards | SaaS MVP |
| **T3** | Operational | Revenue-bearing, on-call required | T2 + incident response + post-mortems + distributed tracing | Scaled product |

**Default for aidops-scale apps: T0 or T1.** Don't overengineer monitoring for a
2-user app. The setup wizard auto-detects the appropriate tie