jeffemmett
/
infinite-agents-public
mirror of https://github.com/Jeff-Emmett/infinite-agents-public.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
infinite-agents-public/infinite_variants/infinite_variant_2/.claude/commands/validate-spec.md

7.5 KiB
Raw Blame History

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

# 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

# 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.