spec-verifier | Skill Performance & Reviews | TopRankSkills

TopRank Skills

Home / Skills / tools / spec-verifier

spec-verifier

maintained by Eddale

star 0 account_tree 0 verified_user MIT License
bolt View GitHub

name: spec-verifier description: Verifies completed work against original specifications. Use when "verify spec", "check spec compliance", "verify against [spec file]", "spec verification for [implementation]". allowed-tools: Read, Write, Edit, Glob, Grep

Spec Verifier

Systematically verify that completed work matches the original specification.

What This Does

After any build or implementation, this skill:

  1. Reads the spec file (SKILL.md, plan, requirements doc)
  2. Extracts discrete, checkable requirements
  3. Reviews the implementation for evidence of each requirement
  4. Produces a Spec Compliance Report with verdict

Instructions

Step 1: Identify Spec and Implementation

If not provided, ask:

  • "Which spec file should I verify against?"
  • "What implementation scope should I check?"

Common spec types:

  • SKILL.md files (skill requirements)
  • Plan files (implementation plans)
  • Ultrathink docs (MAGI analysis outputs)
  • README requirements sections

Step 2: Extract Requirements

Read the spec file and extract discrete requirements. Look for:

  • Numbered lists
  • Bullet points with "must", "should", "will"
  • Success criteria sections
  • Feature descriptions
  • Tables with requirements

Output requirements as a numbered list before verification:

Extracted N requirements from [spec file]:
1. [Requirement 1]
2. [Requirement 2]
...

Step 3: Verify Each Requirement

For each requirement:

  1. Search implementation using Glob/Grep for evidence

  2. Read relevant files to confirm implementation exists

  3. Classify status:

    • Met - Requirement fully satisfied, evidence found
    • Partial - Some evidence exists but incomplete
    • Missing - No evidence of implementation
  4. Capture evidence - File:line or specific output that proves status

Step 4: Generate Spec Compliance Report

Use this format exactly:

## Spec Compliance Report

**Spec:** [path to spec file]
**Implementation:** [scope verified]
**Verified:** [YYYY-MM-DD HH:MM]

### Requirements Checklist

| # | Requirement | Status | Evidence | Notes |
|---|-------------|--------|----------|-------|
| 1 | [Extracted req] | Met | [File:line] | |
| 2 | [Extracted req] | Partial | [What exists] | [What's missing] |
| 3 | [Extracted req] | Missing | - | [Gap description] |

### Summary
- **Met:** X of Y requirements (Z%)
- **Partial:** X requirements need attention
- **Missing:** X requirements not implemented

### Gaps Requiring Action

1. **[Requirement]:** [What's missing]
   - Suggested fix: [How to address]
   - Severity: [Blocker / Should fix / Nice to have]

**Verdict:** [Spec Satisfied / Needs Fixes / Major Gaps]

Step 5: Auto-Save Report (Learning Flywheel)

Always save the report to TWO locations:

  1. Target's docs/verification folder:

    • Path: [target-folder]/docs/verification/YYYY-MM-DD-spec-compliance.md
    • Create the verification folder if it doesn't exist
    • This builds verification history for that specific target
  2. Daily note Captures section:

    • Add link: - [[Spec Compliance - [Target] - YYYY-MM-DD]] - [Verdict summary]

Why this matters: Verification reports become training data. Repeated failures on the same requirement indicate systematic issues.

Verdicts

Spec Satisfied: All requirements Met. Ready to ship.

Needs Fixes: Some Partial or Missing requirements, but no blockers. Address gaps, then re-verify.

Major Gaps: Critical requirements Missing or multiple blockers. Significant work needed.

Fresh Eyes Review Pattern

This skill uses "fresh eyes" verification - treating the implementation as if seeing it for the first time.

Questions to ask for each requirement:

  • "Does this exist in the implementation?"
  • "Does it match what the spec describes?"
  • "Is it complete or just partial?"

Avoid:

  • Assuming intent ("they probably meant to...")
  • Giving benefit of the doubt ("this is close enough...")
  • Inferring requirements not in the spec

Verify what's written, not what was intended.

Examples

Example 1: Skill Verification

Input: "Verify instagram-carousel skill against its v2 plan"

Process:

  1. Read Zettelkasten/Ultrathink - Instagram Carousel Skill v2 Plan - 2026-01-03.md
  2. Extract requirements from Success Criteria and recommended actions
  3. Check skills/instagram-carousel/ for implementation evidence
  4. Produce compliance report

Example 2: Plan Verification

Input: "Verify this implementation against the plan we made"

Process:

  1. Read the plan file (usually in .claude/plans/)
  2. Extract requirements from Implementation Plan section
  3. Check modified files for evidence
  4. Produce compliance report

Integration with Casper

When Casper invokes this skill, Casper adds:

  • QA commentary beyond spec compliance
  • User-perspective review
  • Edge case identification

The spec-verifier provides the systematic checklist. Casper provides the wisdom.

chat Comments (0)

chat_bubble_outline

No comments yet. Be the first to share your thoughts!

Skill Details

GitHub Stars 0
GitHub Forks 0
Created Jan 2026
Last Updated 5 months ago
tools tools automation tools

Related Skills

specs-gen
chevron_right
docker-expert
chevron_right
glm-coding-agent
chevron_right
feature-dev
chevron_right
reviewing-pr
chevron_right

Build your own?

Join 12,000+ developers contributing to the Claude ecosystem.