ha-verify

Maps requirements to direct evidence and selects minimal sufficient verification checks.

1.6k|149|Updated Mar 13, 2026
One-click install
npx skills add https://github.com/shiwenwen/hope-agent --skill ha-verify
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: ha-verify
Source: https://github.com/shiwenwen/hope-agent/tree/main/skills/ha-verify
Command: npx skills add https://github.com/shiwenwen/hope-agent --skill ha-verify

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Engineers often claim work is complete based on weak or stale evidence, such as a passing compile check or a green exit code that never exercised the intended behavior. This Skill enforces a verification discipline that ties every requirement to current, direct proof before anything is declared done.

Core Features & Use Cases

  • Evidence Matrix: Records each requirement alongside its direct evidence, status (proven, failed, blocked, or unverified), and the next useful check.
  • Smallest Sufficient Check Selection: Orders verification from diff inspection through focused tests, integration checks, and manual smoke evidence, avoiding unnecessary full-gate runs.
  • Completion Audit: Re-reads the original request, enumerates required artifacts and gates, and inspects authoritative state before closing a phase or task.
  • Use Case: After fixing a Rust bug, use this Skill to confirm the focused test actually exercised the changed path, separate product failures from environment failures, and state exactly what was proven versus what remains unverified.

Quick Start

Ask the agent to prove whether this phase is actually complete by auditing the implementation against every requirement.

Frequently Asked Questions about ha-verify

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

FAQPage Schema
How do I verify that a code change actually works?

Map each requirement to direct evidence such as a focused test, runtime observation, diff inspection, or read-back of the changed state. Confirm the check exercised the intended case rather than merely exiting with code 0.

What is the smallest sufficient test for a bug fix?

Start by inspecting the final diff and state transition, then run the focused unit test or reproduction for the changed path. Add integration or E2E tests only when the contract crosses that boundary, and reserve full gates for broad closeouts.

Why is a passing compile check not enough proof of completion?

A compile check only proves the code builds, not that the behavior works. A compile check cannot prove a UI interaction, and a generated artifact cannot prove delivery without read-back of the actual result.

How do I distinguish product failures from environment failures?

Record failures and skipped checks explicitly, then separate product failure from fixture, environment, credential, and external service failure. Treat deterministic substitutes as substitutes rather than real external proof.

When should I run full test gates instead of focused tests?

Run full gates only when explicitly requested, required by the repository, or justified by a broad closeout. For routine changes, rely on focused tests and the repository pre-push gate instead of duplicating it manually.