| name | safe-ai-dlc |
| description | Plan and run programs using the SAFe x AI-DLC fusion. Use when turning an audit, epic, or initiative into tracker structure (initiative, projects, milestones, issues, sub-issues), organizing work as Units of Work and Bolts, wiring a dependency DAG, or running a Bolt swarm with a human-in-the-loop gate. Applies when work spans multiple issues and needs cadence.
|
SAFe x AI-DLC Skill
TEMPLATE: This skill uses {{PLACEHOLDER}} tokens. Replace with your project values before use.
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 the tracker 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.
| SAFe | AI-DLC | Tracker object |
|---|
| Portfolio Epic | The Program | Initiative |
| Epic/value stream | Program stream | Sub-initiative, or project priority |
| Feature | Unit of Work | Project |
| PI increment | Bolt | bolt:N label + target date |
| Phase gate | Inception / Construction / Operations | Project Milestone (3 per project) |
| Story/Enabler | Story | Issue |
| Task | Mob task | Sub-issue |
| WSJF/Role/DoD | prioritization / mob role / gate | description + agent:* labels + AC/DoD |
The loop: AI plans, AI asks clarifying questions, the HUMAN validates business context, then
AI executes. Never skip the human validation step.
How to Structure the Program
Build top-down:
- Initiative = the program. One per program.
- Projects = Units of Work. One coherent outcome each.
- Milestones = the three AI-DLC phases (Inception, Construction, Operations). Create all three
per project.
- Issues = Stories. Each carries the issue template below. Label with
bolt:N and agent:*
(lead role).
- Sub-issues = Mob Elaboration tasks. Create during Inception, not before.
- Dependencies =
blocks / blockedBy edges forming the dependency DAG.
Program streams map to sub-initiatives where the tracker plan supports them; where it does not,
encode the stream as project priority instead (highest-risk stream = Urgent/High).
Use linear-sop for tracker operations, label prerequisites, 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 tracker;
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
- Open and elaborate every issue in the Bolt (Mob Elaboration: sub-issues, unknowns, questions).
- Validate with the human on all business, security, and policy decisions before Construction.
- Construct in dependency order on
{{TICKET_PREFIX}}- branches with SAFe commits, rebase-first.
- Verify gates are real — a green check that still masks a failure is not an exit.
- Post evidence to the tracker (dev/staging/done) per
linear-sop.
- 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
Routes To
linear-sop — tracker 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