Case study · AI governance · Spec-driven development
Jira ticket → governed release, with guardrails at every step.
I spearheaded spec-driven development at a healthcare information company: an AI SDLC of 15 Claude skills, provisioned org-wide, that takes a ticket all the way to release. Every stage leaves an auditable artifact, and nothing ships with a gap.
The problem
AI coding assistants made individual engineers faster, but the organization couldn't trust the output. Requirements lived in people's heads, design decisions weren't recorded, security review happened late (if at all), and nothing proved that a change was actually tested before release. Faster code without governance just meant faster surprises in production.
The approach: spec first, evidence always
One command starts the orchestrator. It pulls the Jira ticket and runs an adaptive clarification engine that asks only what's missing, turning the ticket into a full requirements spec before any code is written. Every later stage is grounded in that spec and in the real codebase, and each one leaves a file that a reviewer or auditor can open.
$ /sdlc-orchestrator PROJ-1284Try it below: click a stage to see what it produces, or run the whole pipeline.
Stages, artifacts and gates
| Stage | Skills | Produces |
|---|---|---|
| 1. Requirements | jira-connector requirement-intelligence effort-estimator | Requirements spec via adaptive clarification, effort estimate |
| 🔒 Gate 1 | Engineer approves the spec before design starts | |
| 2. Design | design-to-code | Figma-to-code UI scaffolding mapped to the real component library |
| 3. Architecture | architecture-planner security-abuse-modeling | Architecture decision records, STRIDE-lite threat model |
| 🔒 Gate 2 | Engineer approves design, ADRs and threat model before code | |
| 4. Build | code-execution e2e-playwright | Secure, fully tested code with Playwright end-to-end coverage |
| 5. Observability | observability-enforcement | Enforced logging, metrics and tracing, plus GrowthBook kill switches |
| 6. QC Lite | qc-lite | Fast, evidence-backed quality report |
| 7. QC Guard | qc-guard | Release verdict: blocked until every required artifact exists |
| 🔒 Gate 3 | Engineer approves the release | |
| 8. Rollout | orchestrator | Flagged, staged rollout with a documented rollback path |
| 9. Monitoring | orchestrator | Post-release report and a complete audit trail on the ticket |
A lite path handles small fixes without the full ceremony. Three
anytime skills (code-auditor, retrospective and
innovation-spike) can run outside the pipeline.
15 skills, provisioned to the organization
Orchestration
- sdlc-orchestrator
- sdlc-jira-connector
Requirements
- sdlc-requirement-intelligence
- sdlc-effort-estimator
Design
- sdlc-design-to-code
- sdlc-architecture-planner
Build
- sdlc-code-execution
- sdlc-e2e-playwright
Security & Ops
- sdlc-security-abuse-modeling
- sdlc-observability-enforcement
Quality
- sdlc-qc-lite
- sdlc-qc-guard
Anytime
- sdlc-code-auditor
- sdlc-retrospective
- sdlc-innovation-spike
Outcome
- Faster delivery: engineers stop re-explaining context, because the spec and ADRs travel with the ticket.
- Fewer production surprises: threat models, E2E tests, observability and kill switches are required, not optional.
- A complete paper trail on every ticket, from the first clarifying question to the post-release report.
- Engineers stay in control: three approval gates mean AI proposes and people decide.
Read the companion post: How to let AI write code without losing control.