br4zz4:verify

Enforces running fresh verification commands before claiming work is complete or passing.

Updated May 25, 2025
One-click install
npx skills add https://github.com/oporpino/commons --skill br4zz4-verify-oporpino
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: br4zz4:verify
Source: https://github.com/oporpino/commons/tree/main/ai/shared/skills/br4zz4%3Averify
Command: npx skills add https://github.com/oporpino/commons --skill br4zz4-verify-oporpino

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? AI assistants and developers often claim work is done, fixed, or passing based on assumptions, stale test runs, or partial checks. This Skill eliminates unverified completion claims by requiring fresh command output as evidence before any status assertion, commit, or pull request. ## Core Features & Use Cases - Evidence-First Gate: Enforces a five-step gate (identify, run, read, verify, claim) before any completion statement. - Context-Specific Checklists: Defines required verifications after implementing a task, before opening a PR, and after a bugfix, including full test suite, linter, and build runs. - Rationalization Blocking: Lists red flags and common excuses ("should work", "linter passed") with their counterarguments to prevent premature claims. - Use Case: Before opening a PR, the assistant runs the full test suite, linter, and build, then reports results with concrete evidence such as "Tests: 47/47 pass, Linter: clean, Build: exit 0" instead of saying "done". ## Quick Start Ask the assistant to verify the fix with fresh test output before claiming the bug is resolved.

Frequently Asked Questions about br4zz4:verify

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

FAQPage Schema
How do I verify code changes before opening a pull request?▼

Run the full test suite, the linter or type check, and the build command, then confirm all exit with zero failures. If any step fails, fix the issue and re-run everything before opening the PR.

How to confirm a bugfix actually fixed the bug?▼

Re-run the test that reproduces the original symptom and confirm it passes, then run the full test suite to check for regressions. A code change alone is not evidence the bug is fixed.

Why is a passing linter not enough to claim tests pass?▼

A linter only checks style and static issues; it does not execute the test suite. Claiming tests pass requires actual test command output showing zero failures, since partial checks prove nothing about overall status.

When should verification commands be re-run instead of trusting previous results?▼

Verification must be re-run fresh in the current message before any claim, because previous runs may be stale after code changes. Trusting an old run is treated as making a claim without evidence.

What are the limitations of a verification checklist approach?▼

The checklist only works if the correct verification commands exist and are actually executed; it cannot invent missing tests or detect claims about behavior no command covers. Teams still need adequate test coverage for the gate to be meaningful.