| name | sdlc-checkpoint |
| description | Validates phase outputs before advancing the SDLC. Defines expected artifacts per phase (intake, scout, plan, critic, build, test, review, document, close) and produces a clear PASS / CONDITIONAL / BLOCK verdict with gaps. Use at orchestrator or command phase boundaries, before expensive work, or when the user asks to verify a gate or "are we ready to proceed". |
On-demand loading: Read this skill only when the task clearly matches the description above. Do not load for unrelated work.
SDLC checkpoint (phase gates)
Purpose
Run a structured gate between SDLC phases so the next phase does not start on missing or weak inputs. This skill produces an explicit verdict and a gap list—not a full re-plan unless the gate fails badly.
When to use
- Orchestration: after each named phase completes (intake → scout → plan → critic → build → test → review → document → close).
- Before expensive work: merging, deploying, running long test suites, broad refactors.
- User asks: "gate check", "phase complete?", "ready for build?", "what's missing before we continue?"
- Recovery: after an interrupt or handoff; re-validate the last completed phase.
When to skip or lighten
- Trivial or single-file fixes with clear repo evidence and no contract or security impact: use a lite checkpoint (see below) or skip if user and context already satisfy done-when.
- Read-only reconnaissance: scout-only flows may only need intake + scout gates.
- Do not block on nice-to-have docs or polish unless the workflow type requires them.
Inputs to collect first
- Workflow type (feature, bugfix, refactor, security, migration, docs, performance, infrastructure, research, or ad hoc).
- Phase just completed and next phase intended.
- Artifacts actually produced in this session (messages, files, plans, test output)—cite evidence; do not assume.
- Risk tier (low / medium / high): auth, payments, schema, infra, and user-visible behavior raise the bar.
Gate catalog
See references/phase-gates.md for the full per-phase artifact tables (intake, scout, plan, critic, build, test, review, document, close).
Lite checkpoint (low-risk / small scope)
For low-risk, localized work, only verify:
- Scope match — changes align with the ask.
- Evidence — commands claimed run did run (or stated as not run).
- Obvious footguns — secrets, auth bypass, broken imports—none present.
If all three hold → PASS (lite).
Verdict rules
- PASS: All required artifacts for this phase Met at the current risk tier; proceed.
- CONDITIONAL: One or more Partial items; proceed only with documented mitigations (follow-up task, owner, or explicit user acceptance).
- BLOCK: Any Missing item that is required for this workflow type and risk tier; do not start the next phase until resolved or scope is formally reduced.
Escalate PARTIAL on security, auth, schema, or payment surfaces to BLOCK unless the user explicitly accepts risk in writing.
Output template (use verbatim headings)
Checkpoint
- Workflow:
- Completed phase:
- Next phase:
- Risk tier:
Artifact table
Short table or bullet list: artifact → Met | Partial | Missing | N/A (reason).
Verdict
PASS | CONDITIONAL | BLOCK — one line rationale.
Gaps (if any)
Numbered list of what is missing or weak; each gap has owner (agent / user) and remedy.
Proceed?
Yes / Yes with conditions / No — one sentence.
Integration notes
- Pair with
requirements-gathering after intake when specs are still fuzzy.
- Pair with
requirements-quality-checklist after PRD/intake on STANDARD/COMPLEX work.
- Pair with
artifact-consistency-check after /plan before CRITIC or BUILD.
- Pair with
tech-lead-review during or after Critic for consolidated engineering judgment.
- Do not claim validation passed without evidence (test output, file paths, or explicit user confirmation).
