caveman--verify-and-stop

Validates existing work against acceptance conditions without expanding scope.

Updated Dec 3, 2025
One-click install
npx skills add https://github.com/hhenrichsen/dots --skill caveman-verify-and-stop-hhenrichsen
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: caveman--verify-and-stop
Source: https://github.com/hhenrichsen/dots/tree/main/dot_skills/caveman/verify-and-stop
Command: npx skills add https://github.com/hhenrichsen/dots --skill caveman-verify-and-stop-hhenrichsen

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Engineers often over-verify or accidentally expand scope when checking whether work is done, wasting effort on unrelated tests, polish, and cleanup. This Skill enforces a validation-only discipline: prove the acceptance conditions, then stop. ## Core Features & Use Cases - Smallest Sufficient Proof Set: Translates acceptance conditions into the minimal set of checks needed to prove completion. - Result Reuse: Reuses still-current verification results when the repository state matches, avoiding redundant gate runs. - Precise Outcome Reporting: Distinguishes pass, fail, unavailable, and blocked states exactly, reporting only commands, results, and unresolved risk. - Use Case: After a bug fix, you need to confirm the fix meets the ticket's acceptance criteria. Use this Skill to run only the focused checks required, confirm the pass, and stop without touching unrelated code. ## Quick Start Use verify-and-stop to confirm the current changes meet the acceptance criteria for this task and report the results.

Frequently Asked Questions about caveman--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 check that proves it, run focused checks before wider gates, and stop once proof is complete. Do not add polish, cleanup, or unrelated tests after the criteria pass.

How to run focused checks before full test gates?▼

Run the narrowest checks that directly exercise the acceptance conditions first, then escalate to wider gates only if needed. Reuse still-current results when the repository state has not changed to avoid redundant runs.

When should verification results be reused?▼

Reuse results only when they are still current and the repository state matches the state they were produced against. If code or environment changed since the run, re-execute the relevant checks.

Can verification include fixing failing code?▼

No, product code should not be edited during validation unless the verification request explicitly includes fixes. The goal is to prove or disprove acceptance, not to modify the implementation.

What should a verification report include?▼

Report the commands run, their exact results, and any unresolved risk. Distinguish pass, fail, unavailable, and blocked states precisely rather than collapsing them into a single outcome.