SDLAIC

Use after the design phase is approved (proposal → spec → design complete). Translates the approved design into granular, ordered TDD task pairs — each behavioral task must have a failing test written before implementation. Each task must be completable in a single focused session.

Use when the agent starts a new turn or receives any request. This is the global methodology router — it MUST run before any other skill to determine the correct phase and enforce workflow discipline.

Parameterized Socratic challenge engine. Runs BEFORE drafting an artifact (proposal | spec | design | tasks), loading the matching references/grills/<phase>-grill.md and challenging one question at a time. Records agreed resolutions in the target artifact's Challenge & Resolution Log. Toggled by workflow level (strict = on).

DEPRECATED — do not use. The monolithic design phase has been split into three phase-gated 1:1 skills. Use `proposal` (scope), then `spec` (behavior), then `design` (architecture), each behind its own grill/review gate.

Use when starting new work, a user provides a Jira key, or the enforcer routes to the initialization phase. Creates an SDLAIC change with full context from Jira and codebase research.

Parameterized auditor & gatekeeper engine. Runs AFTER an artifact is drafted (proposal | spec | design | tasks | code), loading the matching references/reviews/<phase>-audit.md in a clean subagent and issuing an APPROVE / REQUEST_CHANGES / REJECT verdict. Verdicts are persisted via `sdlaic gate set` — never inside the repo. For `code`, runs the two-pass compliance + quality review.

Use to author design.md for a change — the Technical Architecture phase (Phase 2). Runs after an approved spec and an optional design grill, producing the architecture that satisfies the proposal and spec, then hands off to the review gate.

Use to author specs/<capability>/spec.md for a change — the Behavioral Requirements phase (Phase 1B). Runs after an approved proposal and an optional spec grill, producing formal GIVEN/WHEN/THEN scenarios, then hands off to the review gate.

Use to author proposal.md for a change — the Scope Proposal (Phase 1A). Runs after an optional scope grill and produces a single artifact defining business rationale and an explicit IN-SCOPE vs OUT-OF-SCOPE contract, then hands off to the review gate.

Use when tasks.md exists and is approved. Executes the task list one task at a time — each task is verified before moving to the next. No scope expansion allowed.