Validate

/validate — ADLC Phase Validation

You are validating ADLC artifacts to ensure quality before advancing to the next phase.

Ethos

!test -s .adlc/ETHOS.md && cat .adlc/ETHOS.md || echo No ethos found — run /init to vendor .adlc/ETHOS.md

Context

• Active specs: !grep -rl -e status:.draft -e status:.approved -e status:.in-progress --include requirement.md .adlc/specs || echo No active specs

Input

Target: $ARGUMENTS

Prerequisites

Before proceeding, verify that .adlc/specs/ exists. If it doesn't, stop and tell the user: "The .adlc/ structure hasn't been initialized. Run /init first."

Instructions

Step 1: Identify What to Validate

1. If given a REQ ID, locate all artifacts under .adlc/specs/REQ-xxx-*/
2. If given a phase name, validate the most recently modified artifacts for that phase
3. Determine the current phase based on what artifacts exist:
   • Spec phase: Only requirement.md exists
   • Architecture phase: architecture.md exists alongside requirement
   • Task phase: tasks/ directory with task files exists
   • Implementation phase: Tasks have status complete or code changes exist

Step 2: Validate Based on Phase

Validating a Requirement Spec

• Frontmatter has valid id, title, status, created, updated fields
• Description clearly explains what AND why
• Acceptance criteria are specific, testable, and use checkbox format
• No implementation details in the requirement (belongs in architecture)
• Assumptions are explicitly stated
• Out of scope items are defined to prevent scope creep
• External dependencies are identified
• No duplicate or overlapping requirements with existing specs

Validating Architecture

• Architecture follows existing patterns from .adlc/context/architecture.md
• New ADRs include rationale (not just decisions)
• Data model changes are compatible with existing Firestore schema
• API endpoint design follows REST conventions from .adlc/context/conventions.md
• Service layer follows the layered pattern (routes → services → repositories)
• No architectural conflicts with other in-progress requirements

Validating Tasks

• Every task has valid frontmatter (id, title, status, parent, created, updated, dependencies)
• Tasks form a valid DAG — no circular dependencies (including cross-repo dependencies)
• Every acceptance criterion from the requirement is covered by at least one task
• Each task lists specific files to create/modify
• Tasks are appropriately scoped (not too large, not too granular)
• Test requirements are included in task acceptance criteria
• Dependencies reference valid task IDs

Verification obligations (REQ-595) — three checks over the task set's ## Verification blocks (shape defined in .adlc/templates/task-template.md). Read the REQ's rules at run time; never carry a copy of them here, because an enumeration in a skill rots the moment a spec changes.

A task file with no ## Verification section is valid. Its absence is reported by the coverage check below, not treated as a malformed task.

• Obligation coverage — every numbered BR and AC in the REQ is cited by at least one task's ## Verification block. Report the unmapped ids by name. Severity: Warning (advisory, non-blocking) in epoch 1. - ACs are addressed by 1-based ordinal within the REQ's ## Acceptance Criteria list — the requirement template does not print AC numbers, so position is the addressing. - BR and AC coverage are gated on the same footing. Acceptance criteria do not reduce to business rules — a REQ can carry ACs with no one-to-one BR — so reporting BRs alone would leave half the omission class open. - A REQ with zero numbered BRs passes trivially: emit a notice and move on. Do not invent rules to check. An unnumbered legacy prose spec is not gate-able, and fabricating ids to gate it would report failures against rules nobody wrote.
• Benign-path coverage — every BR describing detection, refusal, or a halt carries at least one obligation with benign_path: yes (a case asserting the detector does not fire on the legitimate actor). A detector validated only against adversarial inputs ships broken and passes its own suite. Severity: Warning (advisory, non-blocking) in epoch 1. - Match the rule text on case-insensitive stems — detect, refus, halt, reject, block, flag — so refusal/refuses and blocking/blocked both hit. Do not use \b word anchors: BSD grep -E on macOS does not honor them, and the check would silently never fire on the dominant developer platform.
• Vacuous verification run — a verification run that exits 0 having done no work is a failure, not a pass. Severity: Blocker. - Work is defined per kind, because the kinds are not commensurable: a test-case obligation reports executed cases; a structural-check obligation reports files scanned by the lint invocation (many obligations legitimately share one invocation, so per-obligation case counts do not exist for that kind). - Read the count from whichever runner the obligation's artifact names, and treat a status that runner reserves for "collected/scanned nothing" as a zero count. Do not assume a runner here — which one a project uses is the project's choice, read from its stack:, and a runner named in this skill would be the wrong one for the next project. - Most runners already signal an empty run, so this needs no new tooling. In this repo the two surfaces are concrete: tools/lint-skills prints scanned <N> SKILL.md file(s) to stderr and exits 255 when N is zero, and the tools/ test runner exits 5 on zero collected. Consult the consumer project's own runner for the equivalent signal rather than porting these. - Either count reaching zero fails the gate. - This one blocks from epoch 1 while the two above do not, and the asymmetry is deliberate: the checks above are coverage judgments about obligation shape, whereas a zero-work run is evidence the verification did not run at all. A green suite that executed nothing proves nothing.