SuperAPI AI Directory

safe-ai-dlc

Agents & models

View repository

Updated 10-15 20:09

About this skill

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:

  1. Initiative = the program. One per program.
  2. Projects = Units of Work. One coherent outcome each.
  3. Milestones = the three AI-DLC phases (Inception, Construction, Operations). Create all three per project.
  4. Issues = Stories. Each carries the issue template below. Label with bolt:N and agent:* (lead role).
  5. Sub-issues = Mob Elaboration tasks. Create during Inception, not before.
  6. 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

  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 the tracker (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

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