verify-and-stop

Validates acceptance criteria with focused checks and stops without expanding scope.

1|Updated May 3, 2021
One-click install
npx skills add https://github.com/leogurja/dotfiles --skill verify-and-stop-leogurja
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: verify-and-stop
Source: https://github.com/leogurja/dotfiles/tree/main/home/dot_agents/skills/verify-and-stop
Command: npx skills add https://github.com/leogurja/dotfiles --skill verify-and-stop-leogurja

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When a task is nearly done, it is easy to over-engineer: adding polish, unrelated tests, or scope creep instead of simply proving the work meets its acceptance conditions. This Skill enforces disciplined, validation-only behavior so verification stays minimal and honest. ## Core Features & Use Cases - Minimal Proof Sets: Translates acceptance conditions into the smallest sufficient set of checks, reusing still-current results when repository state matches. - Precise Result Reporting: Distinguishes pass, fail, unavailable, and blocked states exactly, and reports commands, results, and unresolved risks. - Scope Discipline: Runs focused checks before wider gates, avoids editing product code unless fixes are requested, and stops immediately once acceptance proof is complete. - Use Case: After implementing a bug fix, ask the agent to verify the fix against the ticket's acceptance criteria. It runs only the relevant tests, reports the outcome, and stops without refactoring nearby code. ## Quick Start Use the verify-and-stop skill to check that the current changes meet the acceptance criteria in the ticket and report the results without making further edits.

Frequently Asked Questions about verify-and-stop

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

FAQPage Schema
How do I verify acceptance criteria without adding scope?▼

Translate each acceptance condition into the smallest sufficient proof, run only the focused checks needed, and stop once proof is complete. Reuse prior results when the repository state has not changed, and avoid cleanup or extra tests after criteria pass.

How to run focused checks before full test suites?▼

Identify the tests or commands that directly exercise the acceptance conditions and run those first. Only escalate to wider gates if the focused checks are insufficient, which keeps verification fast and targeted.

When should I use validation-only verification instead of full review?▼

Use validation-only verification for completion checks, last-mile proof, and gate runs where the work is already done. It is not appropriate when the task explicitly includes fixes, refactors, or broader quality improvements.

What does it mean when a check is blocked or unavailable?▼

Blocked means the check cannot run due to a missing precondition, while unavailable means the check itself cannot be executed in the current environment. Both are reported distinctly from pass or fail so risk is never hidden.

Can verification results from earlier runs be reused?▼

Yes, prior results can be reused when the repository state still matches, avoiding redundant test runs. If the state has changed, the relevant checks must be re-run to keep the proof valid.