verification

name	verification
description	Trigger only after an implementation exists and must be validated against an explicit plan, acceptance criteria, or expected behavior by running relevant checks and reporting evidence-backed pass/fail results.
requires	[]

verification — Evidence-Backed Acceptance Skill

1. Trigger Boundary

Use this skill only after implementation exists and must be checked against:

• Approved plan criteria.
• Acceptance criteria.
• Expected behavior.
• Regression test requirements.
• Wave-level or final execution verification.

Do not use this skill to implement fixes, perform root-cause debugging, review style, or create a plan.

2. Non-Negotiable Constraints

• Verify only. Do not modify implementation files.
• Criteria-by-criteria judgment. Every acceptance criterion must be marked passed, failed, skipped, or blocked.
• Evidence required. Each pass/fail decision must cite command output, file inspection, runtime observation, or explicit reasoning.
• Failed required check means not verified. verified: true is valid only when all required criteria pass.
• Skipped checks must be explicit. Record reason, risk, and whether user approval is needed.

3. Verification State Machine

State A — Load Requirements

Identify plan, implementation summary, expected behavior, and acceptance criteria. If criteria are absent, derive minimal criteria from the user request and label them as derived.

State B — Select Checks

Choose the smallest sufficient check set:

• Automated tests.
• Build/typecheck/lint commands.
• Targeted runtime checks.
• Static inspection for non-executable criteria.

State C — Execute Checks

Run checks and capture exact results. If a command cannot run, mark the corresponding criterion blocked or skipped, not passed.

State D — Decide Verification

Return verified: true only when every required criterion passes and no required command failed.

4. Negative Prompts

• Never change code while verifying.
• Never return verified: true after failed tests.
• Never omit failed command output from the report.
• Never collapse multiple criteria into a vague “looks good”.
• Never silently skip checks.
• Never treat unavailable evidence as success.

5. Final Output Format

status: verified | failed | blocked
verified: boolean
criteria:
  - id: string
    description: string
    result: passed | failed | skipped | blocked
    evidence: string
commands:
  - command: string
    result: passed | failed | skipped
    summary: string
passed: string[]
failed: string[]
skipped: string[]
blockedReason: string | null
nextAction: none | fix | debug | provide-environment | accept-risk