The course’s example, as it would actually happen with this plugin. Times are typical, not promises.
“Customers keep phoning to ask where their claim is. About a third of call time is just status questions. Can we write this up as an intent?”
Claude (the intent skill) asks: who is affected, what would better look like, which systems, any constraints,
what is out of scope. Ten minutes later it shows the draft; the lead corrects one line and says “commit it”.
Through the GitHub connector a pull request appears: Intent: claims status self-service, assigned to the
product owner, file sdlc/changes/2026-06-02-claims-status-self-service/intent.md:
---
change: 2026-06-02-claims-status-self-service
status: draft
owner: M. Chen (product, claims portal)
author: J. Ortiz (claims operations)
risk: routine
---
# Intent: claims status self-service
## Problem
Customers phone the contact center to ask where their claim is.
Handlers spend roughly a third of call time on status-only queries.
## Proposed outcome
Customers see claim status, next step and expected date in the portal.
...
## Open questions
Do third-party loss adjusters need access too?
M. Chen reads the PR (three minutes), changes status: draft to status: accepted in the web editor, merges.
That merge triggers the CI job sdlc-spec-on-intent.
Claude read the intent, the codebase, and the organisation’s policy skills, and opened Spec: claims status
self-service with spec.md. The top of the file:
## Flagged concerns
| # | Concern | Policy / skill | Owner | Decision |
| 1 | Loss adjusters are third parties; showing them status exposes customer PII. | security-policy | Security lead | |
| 2 | claims-core rate limit is 50 rps; a panel polling per page view could exhaust it. | secure-api-review | Platform | |
An independent adversarial reviewer agent judged the spec fit to continue (Gate verdict: CONTINUE), so the
PR carries no needs-human label. M. Chen takes concern 1 to the security lead (adjusters: out of scope, new
intent later) and concern 2 to platform (cache 60 s), writes both decisions into the table, sets
status: accepted, merges. Total product-owner effort: about 40 minutes across the day. No requirements
workshop.
/sdlc:plan 2026-06-02-claims-status-self-service
Claude enters plan mode, reads spec.md and the code, and interviews A. Novak: reuse the existing auth
middleware? (yes) endpoint first or UI first? (endpoint). It drafts plan.md, then answers the mandatory
questions: what could break (auth middleware), riskiest step (1), options not taken (SSR, websockets). Novak
accepts. plan.md is committed; .sdlc/current now names the change.
/sdlc:build
Claude implements step 1, runs make test, step 2, make test, step 3. While wiring the panel it needs a
change the plan did not list (a shared date formatter). It appends to Departures from plan in the same
commit. It tries to edit src/gen/ClaimsClient.ts; the protected-paths hook blocks it:
Blocked: 'src/gen/ClaimsClient.ts' is protected (src/gen/**). Generated code. Change the generator or
schema instead. Route to approval: platform team. ...
Claude regenerates from the schema instead. At the end it runs the verifier subagent (fresh context), which
starts the app, exercises the panel and the two neighbouring flows, and reports pass. Claude opens the PR with
Change: sdlc/changes/2026-06-02-claims-status-self-service, the test output, and the departure.
CI runs sdlc-review within two minutes: three passes per REVIEW.md. One Important finding (the 403 path
lacked a test), two nits, and the tally SDLC-REVIEW: important=1 nits=2 passes=bugs,security,compliance.
Novak runs /sdlc:babysit 412; Claude adds the test, pushes, replies on the thread. The code owner reads the
verdict paragraph, checks the plan matched the intent, approves. Merge.
The release manager runs /sdlc:release prepare (changelog from the intents, checks, eval pass rate), then
/sdlc:release staging (deploy, rollback rehearsal, redeploy, all recorded in the release PR), then
approves the production environment in CI. That approval is the release authorization; the production job
runs. In a terminal, the same gate looks like this without approval:
Production deploys need a named release authorization. Route to approval: the release manager runs
'/sdlc:release approve <change-id>' ...
The scheduled sdlc-control-band job sees post_deploy_5xx_rate breach 3σ with a deploy in the window. With no
person in the path it triggers the pre-approved rollback runbook (environment approval still applies), runs
/sdlc:incident read-only with the evidence, and opens Incident: post-deploy 5xx spike with a new
intent.md under sdlc/incidents/, assigned to the service owner. She triages fix now; the fix goes through
/sdlc:plan → /sdlc:build → review like any change, and /sdlc:eval-add turns the incident into a permanent
eval. sdlc/lessons.md gets a paragraph. Nobody started this; everybody who needed to decide, decided.
For this one change, in git and PR history: who wrote the intent and when; who accepted it; the spec, the
skills applied, the flagged concerns and who decided them; the plan and who accepted it; every code commit
with SDLC-Change:; the review findings and the code owner’s approval; the staging rehearsal; the release
manager’s authorization; the incident, its evidence, and the eval that guards against it.