mcpField
V
verification

verification

github.com/fusengineTesting & quality3440 installsUpdated 2w ago
Repository

About verification

verification is a skill for checking whether a task fulfills its original request, intended for functional and regression checks before completion. It reviews acceptance criteria and evidence, runs the full test suite, inspects changed files, and requires a persisted verification record.

Key features

  1. 01Re-read request and list criteria
  2. 02Collect evidence for each criterion
  3. 03Run full tests for regressions
  4. 04Review modified files for side effects
  5. 05Save a report and challenge the claim

Use cases

  1. 01Check requirements before declaring a task complete
  2. 02Look for regressions or unrelated changes in a fix
  3. 03Preserve verification evidence for later workflow stages

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/fusengine/agents --skill verification

After installing, type/verificationin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

references/
checklist.md
common-misses.md
verify-template.md

Details

From the project README
Verification confirms the original request is actually fulfilled -- distinct from sniper, which only confirms the code is clean. It runs a 6-step process: re-read the original request word for word, list every acceptance criterion (explicit and implicit), verify each with concrete evidence (test output, logs, screenshots, diffs), run the full test suite to check for regressions, review every modified file for accidental side effects, then route the "functionally resolved" claim through the `challenger` agent before writing it down.

Step 6 always persists .claude/apex/docs/verify-{task-slug}.md -- an in-context "it works" declaration doesn't survive a session boundary, and this artifact is what later gates (sniper, elicitation) actually check. It sits between eLicit and eXamine in APEX: a task is only complete when both verification and sniper pass.

Verification Before Completion

Overview

Sniper validates CODE QUALITY. Verification validates FUNCTIONAL RESOLUTION. Both are needed before closing any task.

Sniper catches linter errors, SOLID violations, and code style issues. Verification ensures the original request is actually fulfilled -- the right behavior, the right output, the right fix. A task can pass sniper with zero errors and still be functionally wrong.

AspectSniperVerification
FocusCode qualityFunctional correctness
ChecksLinting, SOLID, styleAcceptance criteria, regressions, side effects
RunsAfter any code changeBefore marking task as complete
ResultClean codeSolved problem

Agent Workflow

When invoked, follow the 6-step verification process below before marking any task as completed.

6-Step Verification Process

Step 1: Re-read the original request Go back to the original issue, task description, or user message. Read it word by word. Do not rely on memory or assumptions.

Step 2: List ALL acceptance criteria Extract every explicit and implicit requirement from the original request. Number them. If the request is vague, list what a reasonable user would expect.

Step 3: Verify each criterion with evidence For each criterion, provide concrete evidence of resolution:

  • Test output showing the expected behavior
  • Log output confirming the fix
  • Screenshot of the UI change
  • Code diff showing the implementation

Step 4: Check for regressions Run the full test suite. Compare results before and after. No new failures, no new warnings.

Step 5: Check for side effects Review every modified file. Confirm no accidental changes to unrelated code. Verify dependencies and configuration are unchanged unless required.

Step 6: Confirm functional resolution -- challenge, then write the artifact Before writing "Original problem is FUNCTIONALLY resolved," ALWAYS route the claim through the challenger agent (or challenge skill), fresh-context: claim = "functionally resolved" + evidence from Steps 3-5, NEVER the investigation reasoning. This is systematic -- every Verify gate, no exception, exactly like sniper runs at every eXamine. Only write the "FUNCTIONALLY resolved" verdict after a CONFIRMED result (or an UNCERTAIN explicitly accepted by the owner). A REFUTED verdict must be resolved (fix and re-verify) before the claim reaches the owner -- soft-gate, not a hard veto.

Write .claude/apex/docs/verify-{task-slug}.md (template: references/verify-template.md): every verification step checked, one evidence item per criterion (command output, log excerpt, screenshot path, or diff), plus the challenge verdict from this step. A context-only "it works" declaration does not survive a session boundary; the written artifact is the guardrail gates (sniper, later elicitation passes) actually check. Then state explicitly in your response: "Original problem is FUNCTIONALLY resolved" with a summary of evidence, or list what remains unresolved.

{task-slug}: derive per apex-methodology/references/init-tracking.md (git branch slug or active TaskCreate id) -- same pattern used by the elicitation skill's artifact.


Reference Guide

ResourcePathContent
Checklistreferences/checklist.mdFull verification checklist with all categories
Common Missesreferences/common-misses.mdFrequently forgotten verification items
Artifact Templatereferences/verify-template.mdverify-{task-slug}.md template + task-slug derivation

Integration with APEX

Verification runs between eLicit and eXamine in the APEX workflow:

Analyze -> Plan -> Execute -> eLicit -> [VERIFICATION] -> eXamine (sniper)

This ensures functional correctness is confirmed before code quality validation. A task is only complete when both verification and sniper pass.


Critical Rules

RuleReason
Never skip re-reading the original requestPrevents solving the wrong problem
Evidence required for every criterion"It works" is not evidence
Full test suite, not just new testsCatches regressions
Review ALL modified filesCatches accidental side effects
Both verification AND sniper must passQuality without correctness is useless
Step 6 writes verify-{task-slug}.md to diskIn-context self-review without persisted state regresses across sessions

Comments

Markdown supported