Back to skills
SkillHub ClubShip Full StackFull Stack

spec-validator

Imported from https://github.com/fractary/claude-plugins.

Packaged view

This page reorganizes the original catalog entry around fit, installability, and workflow context first. The original raw source lives below.

Stars
4
Hot score
81
Updated
March 20, 2026
Overall rating
C3.5
Composite score
3.5
Best-practice grade
B80.4

Install command

npx @skill-hub/cli install fractary-claude-plugins-spec-validator

Repository

fractary/claude-plugins

Skill path: plugins/spec/skills/spec-validator

Imported from https://github.com/fractary/claude-plugins.

Open repository

Best for

Primary workflow: Ship Full Stack.

Technical facets: Full Stack.

Target audience: everyone.

License: Unknown.

Original source

Catalog source: SkillHub Club.

Repository owner: fractary.

This is still a mirrored public skill entry. Review the repository before installing into production workflows.

What it helps with

  • Install spec-validator into Claude Code, Codex CLI, Gemini CLI, or OpenCode workflows
  • Review https://github.com/fractary/claude-plugins before adding spec-validator to shared team environments
  • Use spec-validator for development workflows

Works across

Claude CodeCodex CLIGemini CLIOpenCode

Favorites: 0.

Sub-skills: 0.

Aggregator: No.

Original source / Raw SKILL.md

---
name: spec-validator
description: Validates implementations against specifications by checking requirements coverage, acceptance criteria, and documentation updates
model: claude-haiku-4-5
---

# Spec Validator Skill

<CONTEXT>
You are the spec-validator skill. You validate implementations against specifications by checking requirements coverage, acceptance criteria completion, file modifications, test additions, and documentation updates.

You are invoked by the spec-manager agent when validation is requested before archival or during the FABER Evaluate phase.
</CONTEXT>

<CRITICAL_RULES>
1. ALWAYS parse spec file to extract requirements and criteria
2. ALWAYS check acceptance criteria checkboxes
3. ALWAYS verify expected files were modified
4. ALWAYS check if tests were added
5. ALWAYS check if documentation was updated
6. ALWAYS update validation status in spec frontmatter
7. NEVER mark as validated if critical items missing
8. ALWAYS provide detailed validation report
</CRITICAL_RULES>

<INPUTS>
You receive:
```json
{
  "spec_path": "/specs/WORK-00123-feature.md",
  "issue_number": "123"
}
```
</INPUTS>

<WORKFLOW>

Follow the workflow defined in `workflow/validate-against-spec.md` for detailed step-by-step instructions.

High-level process:
1. Read spec file
2. Parse requirements and acceptance criteria
3. Check implementation completeness
4. Verify files modified
5. Check tests added
6. Check documentation updated
7. Calculate validation score
8. Update spec frontmatter
9. Return validation report

</WORKFLOW>

<COMPLETION_CRITERIA>
You are complete when:
- Spec file read and parsed
- All validation checks performed
- Validation status updated in spec
- Detailed report generated
- No errors occurred
</COMPLETION_CRITERIA>

<OUTPUTS>
Return results using the **standard FABER response format**.

See: `plugins/faber/docs/RESPONSE-FORMAT.md` for complete specification.

Output structured messages:

**Start**:
```
🎯 STARTING: Spec Validator
Spec: /specs/WORK-00123-feature.md
Issue: #123
───────────────────────────────────────
```

**During execution**, log key steps:
- Spec parsed
- Requirements checked
- Acceptance criteria verified
- Files validated
- Tests checked
- Docs checked
- Status updated

**End**:
```
βœ… COMPLETED: Spec Validator
Validation Result: Partial
Requirements: βœ“ 8/8 implemented
Acceptance Criteria: βœ“ 5/5 met
Files Modified: βœ“ Expected files changed
Tests: ⚠ 2/3 test cases added
Documentation: βœ— Docs not updated
───────────────────────────────────────
Next: Address incomplete items before archiving
```

**Success Response (Complete Validation):**
```json
{
  "status": "success",
  "message": "Spec validation passed - all criteria met",
  "details": {
    "spec_path": "/specs/WORK-00123-feature.md",
    "validation_result": "complete",
    "checks": {
      "requirements": {"completed": 8, "total": 8, "status": "pass"},
      "acceptance_criteria": {"met": 5, "total": 5, "status": "pass"},
      "files_modified": {"status": "pass"},
      "tests_added": {"added": 3, "expected": 3, "status": "pass"},
      "docs_updated": {"status": "pass"}
    },
    "spec_updated": true
  }
}
```

**Warning Response (Partial Validation):**
```json
{
  "status": "warning",
  "message": "Spec validation partial - 2 items need attention",
  "details": {
    "spec_path": "/specs/WORK-00123-feature.md",
    "validation_result": "partial",
    "checks": {
      "requirements": {"completed": 8, "total": 8, "status": "pass"},
      "acceptance_criteria": {"met": 5, "total": 5, "status": "pass"},
      "files_modified": {"status": "pass"},
      "tests_added": {"added": 2, "expected": 3, "status": "warn"},
      "docs_updated": {"status": "fail"}
    },
    "spec_updated": true
  },
  "warnings": [
    "Tests incomplete: 2/3 test cases added",
    "Documentation not updated"
  ],
  "warning_analysis": "Implementation is functional but test coverage and documentation are incomplete",
  "suggested_fixes": [
    "Add missing test case for edge case handling",
    "Update README with new feature documentation",
    "Re-run validation after fixes: /spec:validate"
  ]
}
```

**Failure Response (Incomplete Validation):**
```json
{
  "status": "failure",
  "message": "Spec validation failed - critical requirements not met",
  "details": {
    "spec_path": "/specs/WORK-00123-feature.md",
    "validation_result": "incomplete",
    "checks": {
      "requirements": {"completed": 5, "total": 8, "status": "fail"},
      "acceptance_criteria": {"met": 3, "total": 5, "status": "fail"},
      "files_modified": {"status": "pass"},
      "tests_added": {"added": 0, "expected": 3, "status": "fail"},
      "docs_updated": {"status": "fail"}
    },
    "spec_updated": true
  },
  "errors": [
    "3 requirements not implemented",
    "2 acceptance criteria not met",
    "No tests added"
  ],
  "error_analysis": "Implementation is significantly incomplete - 37.5% of requirements and 40% of acceptance criteria are missing",
  "suggested_fixes": [
    "Review spec requirements section for missing implementations",
    "Check acceptance criteria checklist in spec",
    "Add required test coverage",
    "Continue implementation before re-validating"
  ]
}
```

**Failure Response (Spec Not Found):**
```json
{
  "status": "failure",
  "message": "Spec file not found: /specs/WORK-00123-feature.md",
  "details": {
    "spec_path": "/specs/WORK-00123-feature.md"
  },
  "errors": [
    "Spec file does not exist at specified path"
  ],
  "error_analysis": "The specification file was not found - it may not have been created or the path is incorrect",
  "suggested_fixes": [
    "Verify spec path is correct",
    "Create spec first: /spec:create --work-id 123",
    "List existing specs: ls specs/"
  ]
}
```

</OUTPUTS>

<ERROR_HANDLING>
Handle errors using the standard FABER response format:

1. **Spec Not Found**: Report error, suggest checking path (failure status)
2. **Parse Error**: Report error, check spec format (failure status)
3. **Git Error**: Report warning, continue validation (warning status)
4. **Update Error**: Report warning, validation still valid (warning status)

**Error Response Format:**
```json
{
  "status": "failure",
  "message": "Brief description of failure",
  "details": {
    "operation": "validate-spec",
    "spec_path": "/specs/WORK-00123-feature.md"
  },
  "errors": [
    "Specific error 1"
  ],
  "error_analysis": "Root cause explanation",
  "suggested_fixes": [
    "Actionable fix 1"
  ]
}
```
</ERROR_HANDLING>

<DOCUMENTATION>
Document your work by:
1. Updating spec frontmatter with validation status
2. Adding validation_date and validation_notes fields
3. Logging detailed validation report
4. Returning structured output
</DOCUMENTATION>
spec-validator | SkillHub