ai-sdlc-claude

Service owner / on-call engineer

Read time: 8 minutes.

What this is

Maintenance stops being reactive. A deterministic script (no model) watches metrics you choose against control bands. At 1σ it logs; at 2σ Claude diagnoses read-only; at 3σ Claude may act, but only by opening a pull request into the normal review gate or by triggering a runbook approved in advance (e.g. rollback). Every finding arrives as an incident intent.md, which re-enters the loop like any change. You triage; you no longer have to notice, start, or write up.

Your commands

/sdlc:status                            incidents section: metric, tier, triage decision
/sdlc:incident <metric | ticket | thread>   diagnose from a human report; writes the incident intent
/sdlc:eval-add <incident id>            after the fix ships: make the incident a permanent eval
/sdlc:rollback <env> --reason "..."     if you also hold release-manager rights

/sdlc:rollback is enforced, not just advisory: the role-gate hook only allows it if your email is also listed under roles.releaseManagers in sdlc.config.json. Holding only serviceOwners blocks it.

How work arrives

Automatically: the CI job sdlc-control-band runs every 30 minutes (monitoring/bands.yaml). On 2σ/3σ a PR **Incident: ** is opened under `sdlc/incidents/`, assigned to you, with the evidence JSON and Claude's diagnosis. At 3σ with a deploy in the window for `post_deploy_5xx_rate`, the rollback runbook is triggered too (production environment approval still applies).
From a ticket or chat: /sdlc:incident YT-812 or /sdlc:incident <RingCentral thread link>. Claude reads sdlc/lessons.md first (repeat incidents are common), investigates with Sentry/Grafana/CI logs, and writes the same intent.

What you will see

# Intent (incident): CI test failure rate breached 3σ
## Anomaly and evidence
ci_test_failure_rate latest=0.31 mean=0.08 sigma=0.04 z=5.7 · WE1: point beyond 3 sigma · runs #4411-#4419
## Diagnosis
test_status.py::test_paid_state flaky since #4410 (shared fixture mutates clock). Confidence: high.
## Proposed outcome
Quarantine the test and fix the fixture; PR #520 opened into review.
## Triage decision
(blank — yours)

You triage: fix now, schedule, or dismiss

Fix now: the intent goes through /sdlc:spec (or straight to /sdlc:plan for a small bounded fix; the skipped stage is noted). Normal review and code owner approval apply.
Schedule: leave the PR open with a date; /sdlc:status shows it.
Dismiss: merge the bands.yaml tuning PR Claude proposes. Dismissals are how noise falls over time.

Closing the loop

When the fix ships: /sdlc:eval-add <incident id> so Claude’s configuration can never regress on it, and the post-mortem paragraph goes into sdlc/lessons.md (Claude drafts it; you approve the PR).

Boundaries

Claude has no production access. It reads metrics and logs, opens PRs, and triggers only pre-approved runbooks. Detection never involves a model, so bands are predictable and testable (monitoring/test_detect.py).

What only you can do

Triage. Approve band tuning. Decide what “back to baseline” means for your service.

What you never have to do

Watch dashboards at 3 a.m., write the incident up from scratch, or remember to add the regression test.

This site is open source. Improve this page.