Safe AI Dlc

SAFe x AI-DLC Skill

📋 TEMPLATE: This skill uses {{TICKET_PREFIX}} and {{MAIN_BRANCH}} as placeholders. Replace with your project's ticket prefix (e.g., WOR, PROJ) and base branch (e.g., dev, main).

Purpose

Encode the SAFe x AI-DLC fusion so agents structure multi-issue programs consistently: SAFe supplies the hierarchy and guardrails, AI-DLC supplies the cadence and the human checkpoint. Inside a program that adopts this fusion, sprints give way to Bolts, because agent teams elaborate, build, and verify in hours rather than weeks. Adopting the fusion is a per-program choice; the standard sprint path stays valid, and single isolated tickets route to safe-workflow instead.

When This Skill Applies

• Turning an audit, epic, or initiative into an executable program
• Structuring work in Linear as initiative, projects, milestones, issues, and sub-issues
• Breaking an initiative into Units of Work and sequencing them into Bolts
• Wiring dependencies so gates land before the fixes they verify
• Running a Bolt: elaborate, validate with the human, construct, verify gates are real, evidence, merge

Do NOT use it for a single isolated ticket with no program context — use safe-workflow for that.

The Fusion Model

SAFe gives hierarchy, WSJF, roles, DoD, and dependencies. AI-DLC gives cadence (Bolts) and the human-in-the-loop. See docs/guides/SAFE-AI-DLC-METHODOLOGY.md for the full rationale.

The loop: AI plans → AI asks clarifying questions → HUMAN validates business context → AI executes. Never skip the human validation step.

Building the Program (Manual Process)

Since Gemini CLI does not have native Linear integration, build the program through the Linear web UI (or the Linear CLI if installed). Build top-down:

1. Initiative = the program. One per program. Linear web UI → Initiatives → New initiative
2. Projects = Units of Work. One coherent outcome each. Initiative → Add project
3. Milestones = the three AI-DLC phases (Inception, Construction, Operations). Create all three per project. Project → Milestones → New milestone
4. Issues = Stories. Each carries the issue template below. Label with bolt:N and agent:* (lead role). Labels must already exist in the workspace.
5. Sub-issues = Mob Elaboration tasks. Create during Inception, not before. Issue → Add sub-issue
6. Dependencies = blocks / blockedBy edges forming the dependency DAG. Issue → Add relation → Blocks / Blocked by

Program streams map to sub-initiatives where the Linear plan supports them; where it does not, encode the stream as project priority instead (highest-risk stream = Urgent/High).

Use linear-sop for ticket operations and evidence templates.

Issue Template

Every issue description block contains:

Header:      <ID> — <title>  [{{TICKET_PREFIX}}-XXX]
WSJF:        <score>   MoSCoW: <Must|Should|Could|Won't>
Finding:     <source refs, e.g. audit finding IDs>
Phase:       <Inception | Construction | Operations>
Bolt:        <bolt:N>
Role:        <agent:* lead>
AC:          - acceptance criterion (testable)
DoD:         - merged to {{MAIN_BRANCH}}; relevant gate REAL and green; evidence in Linear;
               no silent suppression
Deps:        blocks: [...]   blockedBy: [...]
Sub-issues:  (Mob Elaboration tasks, added during Inception)

Dependency-Wiring Rules

Wire blocks / blockedBy so the enforcement lands before the thing it enforces:

• Fix the gate before the fix it verifies. Harden CI or un-mask a check before landing the fix that check is supposed to catch.
• Rotate before scrub. Rotate a leaked credential before scrubbing it from history.
• Capture before alert. Error capture or health check blocks the alerter and the poller built on top of it.
• Upgrades before re-baseline. Framework and SDK upgrades block audit re-baselining, which blocks the scheduled recurring audit.

Dependency chains are usually rooted at CI hardening — one keystone issue tends to unblock a whole stream. Identify it and sequence its Bolt first.

Running a Bolt

1. Open and elaborate every issue in the Bolt (Mob Elaboration: sub-issues, unknowns, questions).
2. Validate with the human on all business, security, and policy decisions before Construction.
3. Construct in dependency order on {{TICKET_PREFIX}}- branches with SAFe commits, rebase-first.
4. Verify gates are real — a green check that still masks a failure is not an exit.
5. Post evidence to Linear (dev/staging/done) per linear-sop.
6. Merge — RTE prepares the PR; the human (HITL) merges. Exit = merged + real gates green + evidence posted.

Human-Gate Checklist

Route to the human, with options and a recommendation, whenever a decision is:

• A secret or credential action (what to rotate, when, blast radius)
• A security policy: CSP allow-list, auth behavior, headers
• A CI or branch-protection decision: which checks become required
• A severity or risk policy: dependency-audit thresholds, fix-vs-suppress budget
• An SOP exception (e.g. a migration deviating from the documented process)
• Signing the Definition of Done

If a decision changes business, security, or risk posture, it is the human's — surface, recommend, stop.

Anti-Patterns (Do NOT use)

Forcing an ambiguous epic into one Bolt    (run a spike instead — elaboration is the hard part)
Creating sub-issues before Inception       (Mob Elaboration produces them, not the other way round)
Bolts as calendar sprints                  (a Bolt exits on evidence, not on a date)
Skipping human validation to move faster   (the loop is the method; without it this is just SAFe)
Treating a green check as an exit          (verify the gate enforces, not that it merely passed)

Reference

• docs/guides/SAFE-AI-DLC-METHODOLOGY.md -- Methodology guide (rationale, worked example)
• specs_templates/program_template.md -- Program document scaffolding
• AI-DLC source: https://aws.amazon.com/blogs/devops/ai-driven-development-life-cycle/
• Linear Documentation: https://linear.app/docs

Routes To

• linear-sop — Linear operations, program structure, evidence templates
• safe-workflow — branch, commit, and PR conventions; HITL merge
• orchestration-patterns — multi-agent swarm coordination for a Bolt
• pattern-discovery — find existing code and doc patterns before constructing