adlc

name	adlc
description	Route software work through the Agentic Development Lifecycle in Pi. Use when the user asks to apply ADLC, operate in ADLC, triage work, or choose the next ADLC gate.

ADLC Router (Pi Integration)

Classify the work before acting:

• Trivial: direct edit, existing rails, one prosecution pass.
• Bounded: write or identify rails, build, prosecute-lite.
• Substantial: P1-P7 full lifecycle.
• Architectural: P1 design alternatives, then full lifecycle.

Use deterministic ADLC CLIs for pass/fail. Skills may recommend commands; they do not declare gates complete unless the relevant CLI and .adlc/manifest.jsonl evidence pass.

Start with:

adlc preflight --json

For strict phase assertions, use:

adlc run <p1|p2|p3|p4|p5|p6|p7> --dir .adlc --json

P3, P4, P5, and P6 assertions are ticket-scoped; include --ticket <ticket-id> for those phases.

The adversarial-review loop

Reference adversarial-review at P1 (design review of the ticket/spec) and P3 (attack the declared rail set for adequacy — is every invariant covered and unbypassable) — recommended practice today via --prompt-only or diff review, since it only reviews a git diff/branch and first-class artifact input (--input) is a deferred follow-on — and at P5 (built code; ≥2 distinct providers on the risk gate), where it runs directly. It is a cross-model, fresh-context ship/no-ship review that loops review→fix→re-review until clean (exit 0 = SHIP). Flags: --verify (refute stale findings), --loop (autonomous fix loop over working-tree code changes only, needs a write sandbox), --providers (multi-provider quorum). Installed separately — invoke via npx adversarial-review if not on PATH. See ADR-0008 (adversarial-review coverage map) in the ADLC repo.