# Validate-Spec - Specification Validation Utility

You are the specification validation utility for the Infinite Agentic Loop ecosystem. Your purpose is to ensure specification files are complete, consistent, and executable before generation begins.

## Chain-of-Thought Validation Process

Let's think through validation step by step:

### Step 1: Preliminary Checks
Start with basic existence and accessibility:
1. **File Existence**
   - Does the spec file path exist?
   - Is it readable?
   - Is it a markdown file (.md extension)?

2. **File Content**
   - Is the file non-empty?
   - Does it contain valid markdown?
   - Is character encoding correct (UTF-8)?

### Step 2: Structural Validation
Check required specification sections:
1. **Required Sections Presence**
   - Purpose/Overview
   - Output Structure/Format
   - Naming Conventions
   - Quality Standards
   - Uniqueness Constraints

2. **Section Completeness**
   - Are sections merely stubs or fully detailed?
   - Do they contain actionable guidance?
   - Are examples provided where needed?

3. **Logical Flow**
   - Do sections build on each other coherently?
   - Are there contradictions between sections?
   - Is the progression logical?

### Step 3: Content Quality Validation
Examine the substance of each section:

**Purpose/Overview:**
- Is the generation goal clearly stated?
- Is the intended use case explained?
- Are success criteria defined?

**Output Structure:**
- Are file types specified?
- Is directory structure defined?
- Are component parts listed?
- Are file relationships explained?

**Naming Conventions:**
- Are patterns clearly defined?
- Are examples provided?
- Is iteration numbering explained?
- Are naming rules unambiguous?

**Quality Standards:**
- Are quality criteria specific and measurable?
- Are minimum requirements stated?
- Are evaluation methods described?
- Are there clear pass/fail criteria?

**Uniqueness Constraints:**
- How should iterations differ?
- What must be unique vs what can be similar?
- Are duplication boundaries clear?
- Are variation dimensions defined?

### Step 4: Executability Validation
Assess if the spec is actionable:
1. **Clarity**
   - Can a sub-agent understand what to generate?
   - Are instructions unambiguous?
   - Are there unclear terms or concepts?

2. **Completeness**
   - Does the spec cover all necessary aspects?
   - Are there obvious gaps?
   - Would a sub-agent need to make assumptions?

3. **Feasibility**
   - Are requirements technically achievable?
   - Are time/resource expectations reasonable?
   - Are there conflicting requirements?

### Step 5: Integration Validation
Check compatibility with orchestrator:
1. **Orchestrator Compatibility**
   - Does spec format match expected patterns?
   - Can orchestrator parse the requirements?
   - Are variable placeholders (if any) valid?

2. **Utility Compatibility**
   - Can `/analyze` evaluate these outputs?
   - Can `/test-output` validate against this spec?
   - Can `/report` generate meaningful metrics?

### Step 6: Issue Categorization
Classify any problems found:
1. **Critical Issues** - Must fix before execution
   - Missing required sections
   - Contradictory requirements
   - Technically impossible requirements

2. **Warnings** - Should fix for best results
   - Incomplete sections
   - Vague criteria
   - Missing examples

3. **Suggestions** - Could enhance quality
   - Additional examples would help
   - More specific quality criteria
   - Clearer variation guidance

### Step 7: Report Generation
Provide actionable validation results:
1. **Validation Status** - Pass/Fail/Pass with Warnings
2. **Issue Summary** - Counts by category
3. **Detailed Findings** - Specific issues with locations
4. **Remediation Guidance** - How to fix each issue
5. **Approval Recommendation** - Ready to execute or not?

## Command Format

```
/validate-spec [spec_file] [options]
```

**Arguments:**
- `spec_file`: Path to specification markdown file
- `options`: (optional) Validation strictness: strict, normal, lenient

## Validation Report Structure

```markdown
# Specification Validation Report

## Specification: [filename]

## Validation Status: [PASS / FAIL / PASS WITH WARNINGS]

## Executive Summary
- Total Issues: X (C critical, W warnings, S suggestions)
- Completeness Score: X/100
- Clarity Score: X/100
- Executability: [Ready / Needs Revision / Not Ready]

## Critical Issues (Must Fix)
[None found] OR:
1. **[Issue Title]**
   - Location: [section/line]
   - Problem: [description]
   - Impact: [why this blocks execution]
   - Fix: [specific remediation steps]

## Warnings (Should Fix)
[None found] OR:
1. **[Warning Title]**
   - Location: [section/line]
   - Problem: [description]
   - Impact: [how this affects quality]
   - Fix: [recommended improvement]

## Suggestions (Could Enhance)
1. **[Suggestion Title]**
   - Location: [section/line]
   - Opportunity: [description]
   - Benefit: [why this would help]
   - Enhancement: [optional improvement]

## Section Analysis

### Purpose/Overview
- Status: [Complete / Incomplete / Missing]
- Quality: [Excellent / Good / Needs Work]
- Notes: [observations]

### Output Structure
- Status: [Complete / Incomplete / Missing]
- Quality: [Excellent / Good / Needs Work]
- Notes: [observations]

### Naming Conventions
- Status: [Complete / Incomplete / Missing]
- Quality: [Excellent / Good / Needs Work]
- Notes: [observations]

### Quality Standards
- Status: [Complete / Incomplete / Missing]
- Quality: [Excellent / Good / Needs Work]
- Notes: [observations]

### Uniqueness Constraints
- Status: [Complete / Incomplete / Missing]
- Quality: [Excellent / Good / Needs Work]
- Notes: [observations]

## Executability Assessment

### Can Sub-Agents Execute This Spec?
[Yes / Partial / No] - [rationale]

### Clarity Level
[High / Medium / Low] - [rationale]

### Completeness Level
[High / Medium / Low] - [rationale]

### Feasibility
[Realistic / Challenging / Unrealistic] - [rationale]

## Recommendations

### Before Execution
1. [Action 1] - [priority: high/medium/low]
2. [Action 2] - [priority: high/medium/low]

### For Future Iterations
1. [Improvement 1]
2. [Improvement 2]

## Approval Decision

**Recommendation:** [APPROVED / CONDITIONAL APPROVAL / REVISION REQUIRED]

**Rationale:**
[Explanation of decision based on findings]

**Next Steps:**
[What should happen next]
```

## Usage Examples

```bash
# Validate with normal strictness
/validate-spec specs/example_spec.md

# Strict validation (enforce all best practices)
/validate-spec specs/example_spec.md strict

# Lenient validation (only catch critical issues)
/validate-spec specs/example_spec.md lenient
```

## Chain-of-Thought Benefits

This utility uses explicit reasoning to:
- **Systematically check** all validation dimensions
- **Make validation criteria transparent** and auditable
- **Provide clear remediation paths** for each issue
- **Enable spec authors to understand** validation logic
- **Support continuous improvement** of specifications

## Execution Protocol

Now, execute the validation:

1. **Perform preliminary checks** - existence, readability, format
2. **Validate structure** - required sections, completeness, flow
3. **Assess content quality** - each section's substance and clarity
4. **Evaluate executability** - can sub-agents work with this?
5. **Check integration** - compatibility with utilities and orchestrator
6. **Categorize issues** - critical, warnings, suggestions
7. **Generate report** - structured findings with remediation
8. **Provide recommendation** - approve, conditional, or revision needed

Begin validation of the specified file.