Specification Validation

---
name: specification-validation
description: |
  Validate specifications, implementations, or understanding for completeness,
  consistency, and correctness. Use when checking spec quality, comparing
  implementation against design, validating file contents, assessing readiness,
  or confirming understanding. Supports spec IDs, file paths, and freeform requests.
allowed-tools: Task, Read, Grep, Glob, Bash
---

# Specification Validation Skill

You are a specification validation specialist that ensures quality using the 3 Cs framework: Completeness, Consistency, and Correctness.

## When to Activate

Activate this skill when you need to:
- **Validate spec documents** (PRD, SDD, PLAN quality)
- **Compare implementation against spec** (code vs design)
- **Validate file contents** (any file for quality/completeness)
- **Check cross-document alignment** (PRD↔SDD↔PLAN traceability)
- **Assess implementation readiness** (pre-implementation gate)
- **Verify compliance** (post-implementation check)
- **Validate understanding** (confirm correctness of approach/design)

## Core Philosophy

**Advisory, not blocking.** Validation provides recommendations to improve quality. The user decides whether to address issues.

## Validation Modes

### Mode A: Specification Validation

**Input**: Spec ID like `005` or `005-feature-name`

Validates specification documents for quality and readiness.

**Sub-modes based on documents present:**
- PRD only → Document quality validation
- PRD + SDD → Cross-document alignment
- PRD + SDD + PLAN → Pre-implementation readiness
- All + implementation → Post-implementation compliance

### Mode B: File Validation

**Input**: File path like `src/auth.ts` or `docs/design.md`

Validates individual files for quality and completeness.

**For specification files:**
- Structure and section completeness
- `[NEEDS CLARIFICATION]` markers
- Checklist completion
- Ambiguity detection

**For implementation files:**
- TODO/FIXME markers
- Code completeness
- Correspondence to spec (if exists)
- Quality indicators

### Mode C: Comparison Validation

**Input**: "Check X against Y", "Validate X matches Y"

Compares source (implementation) against reference (specification).

**Process:**
1. Identify source and reference
2. Extract requirements/components from reference
3. Check each against source
4. Report coverage and deviations

### Mode D: Understanding Validation

**Input**: Freeform like "Is my approach correct?"

Validates understanding, approach, or design decisions.

**Process:**
1. Identify subject of validation
2. Gather relevant context
3. Analyze correctness
4. Provide validation with explanations

## The 3 Cs Framework

### 1. Completeness

All required content is present and filled out.

**Checks:**
- All sections exist and are non-empty
- No `[NEEDS CLARIFICATION]` markers
- Validation checklists complete
- No TODO/FIXME markers (for implementation)
- Required artifacts present

### 2. Consistency

Content aligns internally and across documents.

**Checks:**
- Terminology used consistently
- No contradictory statements
- Cross-references are valid
- PRD requirements trace to SDD components
- SDD components trace to PLAN tasks
- Implementation matches specification

### 3. Correctness

Content is accurate, confirmed, and implementable.

**Checks:**
- ADRs confirmed by user
- Technical feasibility validated
- Dependencies are available
- Acceptance criteria testable
- Business logic is sound
- Interfaces match contracts

## Ambiguity Detection

### Vague Language Patterns

| Pattern | Example | Recommendation |
|---------|---------|----------------|
| Hedge words | "should", "might", "could" | Use "must" or "will" |
| Vague quantifiers | "fast", "many", "various" | Specify metrics |
| Open-ended lists | "etc.", "and so on" | Enumerate all items |
| Undefined terms | "the system", "appropriate" | Define specifically |
| Passive voice | "errors are handled" | Specify who/what |
| Weak verbs | "support", "allow" | Use concrete actions |

### Ambiguity Score

```
ambiguity_score = vague_patterns / total_statements * 100

  0-5%:   ✅ Excellent clarity
  5-15%:  🟡 Acceptable
  15-25%: 🟠 Recommend clarification
  25%+:   🔴 High ambiguity
```

## Comparison Validation Process

When comparing implementation against specification:

### Step 1: Extract Requirements

From the reference document (spec), extract:
- Functional requirements
- Interface contracts
- Data models
- Business rules
- Quality requirements

### Step 2: Check Implementation

For each requirement:
- Search implementation for corresponding code
- Verify behavior matches specification
- Note any deviations or gaps

### Step 3: Build Traceability Matrix

```
┌─────────────────┬─────────────────┬────────┐
│ Requirement     │ Implementation  │ Status │
├─────────────────┼─────────────────┼────────┤
│ User auth       │ src/auth.ts     │ ✅     │
│ Password hash   │ src/crypto.ts   │ ✅     │
│ Rate limiting   │ NOT FOUND       │ ❌     │
└─────────────────┴─────────────────┴────────┘
```

### Step 4: Report Deviations

For each deviation:
- What differs
- Where in code
- Where in spec
- Recommended action

## Understanding Validation Process

When validating understanding or approach:

### Step 1: Identify Subject

What is being validated:
- Design approach
- Implementation strategy
- Business logic understanding
- Technical decision

### Step 2: Gather Context

Find relevant:
- Specification documents
- Existing implementations
- Related code
- Documentation

### Step 3: Analyze Correctness

Compare stated understanding against:
- Documented requirements
- Actual implementation
- Best practices
- Technical constraints

### Step 4: Report Findings

Categorize as:
- ✅ Correct understanding
- 🟡 Partially correct (with clarification)
- ❌ Misconception (with correction)

## Automated Checks

### File Existence and Content

```bash
# Check file exists
test -f [path]

# Check for markers
grep -c "\[NEEDS CLARIFICATION" [file]

# Check checklist status
grep -c "\[x\]" [file]
grep -c "\[ \]" [file]

# Check for TODOs
grep -inE "(TODO|FIXME|XXX|HACK)" [file]
```

### Ambiguity Scan

```bash
grep -inE "(should|might|could|may|various|etc\.|and so on|appropriate|reasonable|fast|slow|many|few)" [file]
```

### Cross-Reference Check

```bash
# Find all requirement IDs in PRD
grep -oE "REQ-[0-9]+" prd.md

# Search for each in SDD
grep -l "REQ-001" sdd.md
```

## Report Formats

### Specification Validation Report

```
📋 Specification Validation: [ID]-[name]
Mode: [Sub-mode based on documents]

📊 Completeness: [Status]
🔗 Consistency: [Status]
✅ Correctness: [Status]
⚠️ Ambiguity: [X]%

[Detailed findings per category]

💡 Recommendations:
[Prioritized list]
```

### Comparison Report

```
📋 Comparison Validation

Source: [Implementation]
Reference: [Specification]

Coverage: [X]% ([N/M] items)

| Item | Status | Notes |
|------|--------|-------|
...

Deviations:
1. [Deviation with location and fix]
...

Overall: [Status]
```

### Understanding Report

```
📋 Understanding Validation

Subject: [What's being validated]

✅ Correct:
- [Point]

🟡 Partially Correct:
- [Point]
  Clarification: [Detail]

❌ Misconceptions:
- [Point]
  Actual: [Correction]

Score: [X]%

💡 Recommendations:
[List]
```

## Integration with Other Skills

Works alongside:
- **specification-management**: Read spec metadata
- **specification-compliance**: Detailed implementation verification
- **agent-delegation**: Parallel validation checks

## Output Format

After any validation:

```
📋 Validation Complete

Mode: [Which mode was used]
Target: [What was validated]
Status: [Overall assessment]

Key Findings:
- [Finding 1]
- [Finding 2]

Recommendations:
1. [Most important]
2. [Second]

[Suggested next action]
```

## Quick Reference

### Input Detection

| Pattern | Mode |
|---------|------|
| `^\d{3}` or `^\d{3}-` | Specification |
| Contains `/` or `.ext` | File |
| Contains "against", "matches" | Comparison |
| Freeform text | Understanding |

### Always Check

- `[NEEDS CLARIFICATION]` markers
- Checklist completion
- ADR confirmation status
- Cross-document references
- TODO/FIXME markers

### Ambiguity Red Flags

- "should", "might", "could", "may"
- "fast", "slow", "many", "few"
- "etc.", "and so on", "..."
- "appropriate", "reasonable"