validate

name	validate
description	Validate any ADLC phase output before advancing
argument-hint	REQ-xxx ID or phase name (spec, architecture, tasks, implementation)

/validate — ADLC Phase Validation

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

Ethos

!sh .adlc/partials/ethos-include.sh 2>/dev/null || sh ~/.claude/skills/partials/ethos-include.sh

Context

• Active specs: !grep -rl 'status: draft\|status: approved\|status: in-progress' .adlc/specs/*/requirement.md 2>/dev/null | head -20 || 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

Cross-repo tasks — only applies if .adlc/config.yml in the primary repo declares more than one entry under repos:. Skip these checks in single-repo mode.

• Every task has a repo: field in its frontmatter
• Every repo: value matches an id declared in .adlc/config.yml under repos:
• No task modifies files outside its declared repo: — all paths under "Files to Create/Modify" live in that repo
• At least one task targets the primary repo (even if just spec/doc updates) OR a follow-up confirms the primary needs no code changes
• Cross-repo dependencies make sense (e.g., a frontend task depending on a backend task, not the reverse)

Validating Implementation

• All task acceptance criteria are met
• Tests pass (npm test or equivalent)
• Code follows conventions from .adlc/context/conventions.md
• No new lint warnings or errors
• All requirement acceptance criteria are satisfied
• ADLC artifacts are updated (task statuses set to complete)

Step 3: Report Results

1. Display validation results as a checklist with pass/fail for each item
2. Categorize issues by severity:
   • Blocker: Must fix before advancing (e.g., missing acceptance criteria, circular deps)
   • Warning: Should fix but won't block (e.g., vague wording, missing edge case)
   • Info: Suggestions for improvement
3. If all checks pass, confirm the artifact is ready to advance
4. If blockers exist, list specific fixes needed

Step 4: Recommend Next Action

• Spec validated → "Ready for /architect"
• Architecture validated → "Ready for implementation"
• Tasks validated → "Ready for implementation"
• Implementation validated → "Ready for /review"