awslabs/aidlc-workflows — Summary

AI-DLC (AI-Driven Development Life Cycle) is AWS's official multi-platform workflow steering rule set for AI coding agents — a cross-IDE methodology that installs into Kiro, Amazon Q Developer, Cursor, Cline, Claude Code, and GitHub Copilot and enforces a structured three-phase software development lifecycle: INCEPTION → CONSTRUCTION → OPERATIONS.

Problem it solves: AI coding agents lack consistent process discipline across different IDEs and projects; developers get variable quality outputs and no audit trail. AI-DLC imposes Inception (planning), Construction (design/build/test), and Operations phases with mandatory phase-gate documentation, adaptive depth based on task complexity, and optional security/testing extensions.

Distinctive trait: The only framework in the corpus with a three-phase lifecycle enforcement that explicitly runs on 6 different IDEs (not just one). It uses a hierarchical rule-loading strategy: a single core-workflow.md steering rule bootstraps context, then loads detailed rule files on demand from aws-aidlc-rule-details/ — preventing context bloat while ensuring completeness. Extensions (security baseline, testing strategies) use an opt-in/opt-out prompt mechanism at Requirements Analysis.

Target audience: Enterprise development teams using AI coding agents who need consistent, auditable, compliance-aware development workflows across diverse IDE choices.

Scope: 2,443 GitHub stars, MIT-0 license (AWS's no-attribution MIT variant), v0.1.8 release (April 2026), 24 contributors, active since 2025.

Differs from seeds: Most similar to kiro (Archetype 5 — structured lifecycle with steering files and phases) but cross-IDE rather than IDE-locked. Unlike superpowers (Archetype 1 — behavioral enforcement via skills), AI-DLC is a rule/steering-file system that imposes multi-phase process with mandatory artifacts, approval gates, and an audit log (audit.md).

awslabs/aidlc-workflows — Overview

Origin

Published by AWS Labs (awslabs GitHub organization) as the official AWS AI-driven development methodology. Released with a blog post: "AI-Driven Development Life Cycle" on the AWS DevOps blog. A formal Method Definition Paper exists (referenced in the README).

Philosophy

"AI-DLC is an intelligent software development workflow that adapts to your needs, maintains quality standards, and keeps you in control of the process."

Three core tenets:

1. Adaptive workflow: The AI assesses complexity, workspace state, and intent — then determines which stages are needed. Not all stages run for all tasks.
2. User control: Approval gates at each phase ensure humans remain in control of architectural decisions
3. Quality standards: Mandatory content validation (Mermaid diagrams, ASCII art, special character escaping), mandatory audit log

Design Manifesto

The core-workflow.md opens with:

"# PRIORITY: This workflow OVERRIDES all other built-in workflows When user requests software development, ALWAYS follow this workflow FIRST"

This is a hard override — AI-DLC explicitly claims precedence over the AI agent's built-in behaviors.

The Three-Phase Lifecycle

INCEPTION PHASE
└── Workspace Detection (ALWAYS)
    Reverse Engineering (brownfield only)
    Requirements Analysis (ALWAYS, adaptive depth)
    User Stories (conditional)
    Workflow Planning (ALWAYS)
    Application Design (conditional)
    Units Generation (conditional)

CONSTRUCTION PHASE
└── Functional Design (per unit)
    NFR Requirements (per unit)
    Infrastructure Design (conditional)
    Code Generation (ALWAYS, per unit)
    Build and Test (ALWAYS)

OPERATIONS PHASE (placeholder)
└── Future deployment/monitoring workflows

Tenets

From the README, AI-DLC embraces:

• Quality-first development
• Human-AI collaboration (not autonomous AI)
• Compliance-awareness (via extension system)
• Auditability (mandatory audit.md)

awslabs/aidlc-workflows — Architecture

Distribution

• Type: methodology-doc + steering-file bundle
• Install: Download latest release zip → extract → copy to IDE-specific location
• License: MIT-0 (AWS's no-attribution variant)
• Version: v0.1.8 (latest release as of 2026-05-26)

Platform-Specific Install Paths

Repository Structure

awslabs/aidlc-workflows/
├── .bandit, .checkov.yaml, .gitleaks.toml, .grype.yaml  # Security scanning
├── .semgrepignore, .pre-commit-config.yaml              # Pre-commit hooks
├── .kiro/steering/                                       # Kiro-ready steering
├── .claude/settings.json                                 # Claude Code settings (attribution only)
├── aidlc-rules/
│   ├── aws-aidlc-rules/
│   │   └── core-workflow.md          # MAIN: the single orchestrating rule
│   └── aws-aidlc-rule-details/
│       ├── common/                   # 10 common detail files
│       │   ├── process-overview.md
│       │   ├── session-continuity.md
│       │   ├── content-validation.md
│       │   ├── question-format-guide.md
│       │   └── welcome-message.md
│       ├── inception/               # 6 inception phase detail files
│       ├── construction/            # 7 construction phase detail files
│       ├── extensions/
│       │   ├── security/            # security-baseline files
│       │   └── testing/             # testing-strategy files
│       └── operations/
├── scripts/                         # 3 analysis/evaluation scripts
│   ├── aidlc-designreview
│   ├── aidlc-evaluator
│   └── aidlc-traceability
├── AGENTS.md
├── CHANGELOG.md
└── README.md

Rule-Loading Architecture

The hierarchical loading strategy is a key design:

1. Agent installs core-workflow.md (single small steering file)
2. core-workflow.md instructs agent to load common/ rules at workflow start
3. Phase-specific detail files are loaded on-demand during each phase
4. Extension *.opt-in.md files presented to user → user opts in/out → full extension loaded or skipped

Security Infrastructure

The repo ships enterprise-grade security scanning:

• .bandit — Python security linter
• .checkov.yaml — Infrastructure-as-code security scanner
• .gitleaks.toml — Secret leakage detection
• .grype.yaml — Vulnerability scanner
• .pre-commit-config.yaml — Pre-commit hooks running all above

Required Runtime

• No runtime for rule file consumption
• Scripts in scripts/ require bash
• Pre-commit hooks require Python tools (bandit, semgrep, gitleaks, grype)

awslabs/aidlc-workflows — Components

Core Rule Files

Primary Steering Rule (1)

Common Detail Files (10)

Inception Phase Detail Files (6)

Construction Phase Detail Files (7)

Extension Files (4)

Scripts (3)

Output Artifacts (Generated by Agent During Workflow)

awslabs/aidlc-workflows — Uniqueness & Positioning

Differs from Seeds

Most similar to kiro (Archetype 5) — both enforce a structured lifecycle with steering files and phase-gated development. However, AI-DLC is cross-IDE (6 IDEs) while kiro is IDE-locked. Also similar to spec-driver and superpowers (Archetype 1) in enforcing phases, but AI-DLC uses rule/steering files rather than skills, and adds a mandatory audit log.

Key differentiators from all seeds:

1. Six-IDE support: Only framework with explicit, tested support for Kiro, Amazon Q, Cursor, Cline, Claude Code, and GitHub Copilot simultaneously
2. Adaptive depth calibration: The depth-levels.md mechanism adjusts stage selection to task complexity — not a fixed pipeline
3. Extension opt-in/opt-out: Security and testing extensions are user-activatable at Requirements Analysis, not always-on — balancing overhead and compliance
4. Mandatory audit log: audit.md is required output, not optional — creates an auditable record of all agent decisions
5. Human question file format: Structured A-E multiple-choice Q&A in files — offline/async collaboration pattern vs interactive chat

Distinctive Properties

1. Rule hierarchy with lazy loading: core-workflow.md → phase detail files → extension files — each layer loaded on-demand, minimizing context cost
2. Hard override declaration: "OVERRIDES all other built-in workflows" — more assertive than any seed's enforcement model
3. Blocking gates on extension violations: Non-compliance is explicitly a "blocking finding" — completion halted until resolved
4. Brownfield vs greenfield adaptation: Reverse Engineering is a first-class stage for brownfield projects

Observable Failure Modes

• Context fragmentation: Loading 20+ detail files across a long workflow can hit context limits — the lazy loading mitigates but doesn't eliminate this
• Cross-IDE drift: IDE-specific path resolution adds complexity; if an IDE changes its directory convention, the fallback chain may miss
• Question file latency: Async Q&A in files is slower than interactive chat; in fast-moving contexts, human response lag becomes the bottleneck
• Extension enforcement without tooling: The security/testing extensions are enforced via AI judgment, not automated scanners — false negatives are possible

AWS Governance Context

As an awslabs repo with MIT-0 license (no attribution required), AI-DLC is positioned for enterprise adoption without legal friction. The security scanning infrastructure (bandit, checkov, gitleaks) signals enterprise-grade security posture.