SDLAIC

SDLC + AI — a play on Software Development Life Cycle, with AI in the name and in the workflow. A CLI tool and AI skill framework that enforces a phase-gated development process for AI coding agents. AI coding agents tend to jump straight to writing code, skip design, skip testing, and drift from requirements. SDLAIC forces every change through a fixed pipeline where each phase produces a verifiable artifact before the next phase can begin.

SDLAIC consists of two parts:

1. sdlaic CLI (Go) — manages change artifacts: initialization, templating, validation, status tracking, and AI plugin installation.
2. AI Skill definitions (Markdown) — loaded by AI agents (Claude Code, Codex, Gemini CLI) to enforce workflow discipline.

Install sdlaic using the single-line installation script:

curl -fsSL https://raw.githubusercontent.com/bienwithcode/SDLAIC/main/install.sh | sh

Install sdlaic natively using the PowerShell installer:

irm https://raw.githubusercontent.com/bienwithcode/SDLAIC/main/install.ps1 | iex

If you have the Go compiler installed:

go install github.com/bienwithcode/SDLAIC@latest

You can automatically configure and launch Claude Code with the SDLAIC plugin using a single command:

sdlaic open claude

(This command automatically initializes the workspace if needed, registers the bienwithcode marketplace, installs the sdlaic plugin, and starts a Claude Code shell session).

If you do not wish to use the Go CLI, you can register and install the plugin directly within a Claude Code session:

/plugin marketplace add bienwithcode/SDLAIC
/plugin install sdlaic@bienwithcode

You can automatically configure and launch the Pi coding agent with the SDLAIC skills using a single command:

sdlaic open pi

(This command automatically initializes the workspace if needed, injects an idempotent SDLAIC workflow block into the project's AGENTS.md, installs the sdlaic pi package project-locally (.pi/settings.json — scoped to this repo and shared with the team, so it never pollutes unrelated pi sessions), and starts a Pi session). Skills are then available as /skill:enforcer, /skill:grillme <phase>, /skill:review <phase>, etc.

pi install -l git:github.com/bienwithcode/SDLAIC

(-l writes the package to project-local .pi/settings.json instead of user-global ~/.pi/agent/settings.json; drop it if you want the skills available in every project on the machine.)

Support for Codex is coming in a later release.

The development lifecycle is a series of phase-gated micro-loops. Each phase produces exactly one artifact, and progression is allowed only when that artifact exists and its gate has passed. This prevents an agent from designing against unverified requirements or writing code from an unapproved plan.

Each phase runs the same loop — grill → draft → review → gate:

new ─► context.md
        │  ┌─────────────── one micro-loop per phase ───────────────┐
        ▼  │ grill (challenge) → draft (write) → review (audit) → gate │
  proposal │ ── proposal.md ───────────────────────────► gate:proposal ✓
  spec     │ ── specs/<capability>/spec.md ──────► gate:spec:<capability> ✓ (per cap)
  design   │ ── design.md ─────────────────────────────► gate:design ✓
  tasks    │ ── tasks.md ──────────────────────────────► gate:tasks ✓
        ▼  └───────────────────────────────────────────────────────┘
  apply ─► code ─► review code ─► review.md

Gate verdicts are stored outside your repo (see Gate State), so approvals never clutter your project.

grillme and review are optional and toggled by workflow level: strict runs both; light/free skip them (draft-only fast path). The draft skill is always mandatory.

Each phase writes one artifact under the project's changes directory. Ask the CLI where that is — sdlaic path changes — rather than assuming a location:

$(sdlaic path change --change <change-name>)/
├── context.md           # Candidate scopes (+ recommendation), research summary, actors & use cases
├── proposal.md          # Scope contract: why, IN/OUT-OF-SCOPE, impact
├── specs/               # Behavioral requirements (if user-facing)
│   └── <capability>/
│       └── spec.md      # Formal GIVEN/WHEN/THEN scenarios
├── design.md            # Technical design: architecture, boundaries, decisions
└── tasks.md             # Ordered TDD tasks by subsystem milestone (checkbox syntax)

Socratic-challenge resolutions are applied directly into each artifact's content (scope rows, requirements/scenarios, ## Decisions) — there is no separate log section.

Gate verdicts are never written into your project repo. They live in a global state store, keyed by project + change:

~/.sdlaic/state/<project_hash>/<change-name>/
├── meta.json       # machine-readable gate state — source of truth for "approved?"
├── review.md       # human-readable mirror of the latest verdict + findings
└── history.jsonl   # append-only re-entry / follow-up events

A phase is unblocked only when its artifact exists and its gate is approved (or skipped in light/free). When a ticket changes mid-flight, sdlaic gate reentry re-enters the earliest affected artifact and supersedes everything downstream.

sdlaic init                           # Initialize workspace (if not using auto-init)
sdlaic open claude                    # Install plugin and spawn Claude Code
sdlaic new change "<name>"            # Create a new change
sdlaic status                         # Show current phase and artifact status
sdlaic status --json                  # Machine-readable status
sdlaic instructions <artifact> -c <name>  # Get template (proposal | spec | design | tasks)
sdlaic validate <name>                # Validate artifact format
sdlaic validate <name> --strict       # Strict: all artifacts must exist

# Gate state (verdicts stored in ~/.sdlaic/state/, never in your repo)
sdlaic gate status -c <name>          # Show gate state for each phase
sdlaic gate status -c <name> --json   # Machine-readable gate state
sdlaic gate set -c <name> --phase <proposal|spec:<capability>|design|tasks> \
    --status <approved|failed|skipped> [--verdict <APPROVE|REQUEST_CHANGES|REJECT>] [--attempt]
sdlaic gate reentry -c <name> --from <phase> --reason "<why>"   # Mid-flight change

sdlaic list                           # List active changes
sdlaic show <name>                    # Show change details
sdlaic switch <name>                  # Set active change
sdlaic archive <name>                 # Archive a completed change

Each project's changes directory is recorded in ~/.sdlaic/config.json. It defaults to <project>/.sdlaic/changes/, and --changes-dir puts it anywhere you like:

sdlaic init                                        # <project>/.sdlaic/changes/
sdlaic init --changes-dir ~/work/openspec/changes  # outside the project entirely
sdlaic config set changes-dir <path>               # change it later
sdlaic path changes                                # print the resolved location

When the directory sits outside the project, SDLAIC creates nothing inside it — no config file, no .sdlaic/ directory. One directory belongs to exactly one project; pointing a second project at the same one is rejected.

SDLAIC never writes to your .gitignore. If you want artifacts kept out of the repo, either add the entry yourself or put the directory outside the repo.

storage_mode in sdlaic status --json is replaced by changes_dir, an absolute path — a breaking change for anything parsing that output.

The local, ignored, and global storage modes are gone, along with the project-local .sdlaicrc. Existing files are left on disk and ignored; run sdlaic init once per project to register it. An old ~/.sdlaic/config.json still loads — its obsolete fields are dropped, and each project is treated as needing a changes directory. Artifacts previously kept in ~/.sdlaic/stores/<hash>/changes/ are not migrated or deleted; point a project at them with sdlaic config set changes-dir ~/.sdlaic/stores/<hash>/changes if you want them back.

The workflow level controls whether the grill and review gates run around each draft:

In every level the draft skill is mandatory and artifacts are still produced in order; only the grill/review gates are toggled.

MIT