verify

Verify software changes through tests, builds, and direct behavioral checks.

Updated May 5, 2026
One-click install
npx skills add https://github.com/HyperionBurn/searchv1beta --skill verify-hyperionburn
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: verify
Source: https://github.com/HyperionBurn/searchv1beta/tree/main/.github/skills/verify
Command: npx skills add https://github.com/HyperionBurn/searchv1beta --skill verify-hyperionburn

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It prevents you from claiming completion based on vague assumptions by turning “it should work” into clear, evidence-based verification.

Core Features & Use Cases

  • Evidence-first validation: Forces you to identify the exact behavior that must be proven before declaring success.
  • Verification escalation: Starts with existing tests, then moves to typecheck/build, then to narrow direct checks, and finally manual or interactive validation when automation isn’t sufficient.
  • Transparent reporting: Summarizes only what was verified, including what failed and what remains unverified.

Quick Start

Ask the Skill to verify a specific change by running the best available tests and checks, then report what passed, what failed, and what could not be verified.

Frequently Asked Questions about verify

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

FAQPage Schema
How do I verify code changes work before release without guessing?

To verify code changes before release, use an evidence-first workflow that prioritizes existing tests, then typecheck and build checks, then narrow command checks, and finally manual validation when automation is insufficient.

What is evidence-first verification for software release readiness?

Evidence-first verification forces you to identify the exact behavior that must be proven before declaring success, turning vague assumptions into clear test, build, and direct behavioral checks.

How do I run command checks to prove a code change produces intended behavior?

Run command checks by escalating from existing tests to typecheck and build, then apply narrow direct command checks to prove the software change produces the intended behavior before manual validation.

Can I use automated testing for release readiness when manual validation is insufficient?

Automated testing supports release readiness by prioritizing existing tests, typecheck, and build first, but when automation is insufficient, manual or interactive validation is required to verify intended behavior.

What's the best way to report what passed, failed, and remains unverified during code review?

The best way to report verification results during code review is to summarize only what was verified through transparent reporting, explicitly listing what passed, what failed, and what could not be verified.

Why does my software verification workflow miss bugs even when tests pass?

Software verification workflows miss bugs when claiming completion based on vague assumptions, but applying an evidence-first escalation from existing tests to direct command checks proves the exact intended behavior.