sp-verify

Run verification commands and confirm exit status before asserting completion.

23|2|Updated Mar 1, 2026
One-click install
npx skills add https://github.com/tta-lab/ttal-cli --skill sp-verify
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: sp-verify
Source: https://github.com/tta-lab/ttal-cli/tree/main/skills/sp-verify
Command: npx skills add https://github.com/tta-lab/ttal-cli --skill sp-verify

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It prevents false or premature “done/passing/complete” statements by forcing you to run the exact verification command and use fresh evidence before you assert success.

Core Features & Use Cases

  • Evidence-first completion gate: Requires identifying the specific proof command, running the full verification, and reading the complete output (including exit code and failure counts) before making any positive status claim.
  • Covers common CI and engineering claims: Applies to tests, linting, builds, bug fixes, regression cycles, and requirements checklists where “trusting” reports is risky.
  • Safety against subtle failure modes: Stops rationalizations like “should pass,” “looks correct,” partial checks, or agent-reported success without independent verification.

Quick Start

Use sp-verify before committing, pushing, or opening a PR to ensure your tests, build, or other required checks are freshly run and supported by the latest command output.

Frequently Asked Questions about sp-verify

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I prevent false completion claims in CI and software delivery workflows?

To prevent false completion claims in CI workflows, you must require fresh verification evidence by identifying the proving command, executing the full verification, and confirming exit status and output before asserting success.

What is evidence-based verification for release readiness?

Evidence-based verification for release readiness is the process of running exact proof commands and reading complete output, including exit codes and failure counts, to stop rationalizations like “should pass” or “looks correct” before claiming a task is complete.

How do I verify tests, linting, and builds before opening a pull request?

To verify tests, linting, and builds before opening a pull request, you should run the specific proof command, check the complete output, and only declare passing status after confirming the exit code and failure counts from the latest run.

Does this verification approach work for bug fixes and regression cycles?

Yes, this verification approach works for bug fixes and regression cycles by enforcing an evidence-first completion gate that requires identifying the proof command, running the full check, and confirming exit status before asserting any positive status claim.

Why do I need fresh verification evidence instead of trusting agent-reported success?

You need fresh verification evidence instead of trusting agent-reported success to establish safety guardrails against subtle failure modes, preventing premature or dishonest claims of completion when checks only appear correct without independent verification.

What are the limitations of asserting task completion without checking exit codes?

Asserting task completion without checking exit codes allows partial checks or rationalized success statements to bypass safety guardrails, risking false claims of tests, builds, or bug fixes passing when the actual verification output indicates failures.