verification-before-completion

Enforces fresh, evidence-backed verification before allowing completion claims.

2|1|Updated Feb 26, 2026
One-click install
npx skills add https://github.com/passionseed/ps_app --skill verification-before-completion-passionseed
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: verification-before-completion
Source: https://github.com/passionseed/ps_app/tree/main/.agent/skills/verification-before-completion
Command: npx skills add https://github.com/passionseed/ps_app --skill verification-before-completion-passionseed

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Claiming work is complete without verification is dishonesty, not efficiency.

Core principle: Evidence before claims, always.

Violating the letter of this rule is violating the spirit of this rule.

Core Features & Use Cases

  • Gate-driven verification: Mandates identifying the proving command, running afresh, reading results, and verifying outcomes before any success claim.
  • Evidence-based claims: Ensures all claims are backed by verifiable outputs, exit codes, and logs.
  • Red-flag awareness: Highlights common failure modes like asserting success after partial checks or relying on past runs.

The Iron Law

NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE

If you haven't run the verification command in this message, you cannot claim it passes.

The Gate Function

  1. IDENTIFY: What command proves this claim?
  2. RUN: Execute the FULL command (fresh, complete)
  3. READ: Full output, check exit code, count failures
  4. VERIFY: Does output confirm the claim?
    • If NO: State actual status with evidence
    • If YES: State claim WITH evidence
  5. ONLY THEN: Make the claim

Skip any step = lying, not verifying

Common Failures

  • Claim: Tests pass -> Requires: Test command output with zero failures
  • Claim: Linter clean -> Requires: Linter output with zero errors
  • Claim: Build succeeds -> Requires: Build command exit code 0

Red Flags - STOP

  • Expressions like "great" or "done" before verification
  • TRUSTING agent success reports
  • Partial verification
  • Rushing to commit or PR without fresh verification
  • Anything implying success without running verification

Rationalization Prevention

  • Avoid excuses like "should work now" or "I'm confident"
  • No shortcuts: verify, verify, verify

Key Patterns

  • ✅ Run test command and verify
  • ✅ End-to-end verification with fresh outputs

The Bottom Line

No shortcuts for verification. Run the command, read output, then claim the result.

Frequently Asked Questions about verification-before-completion

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

FAQPage Schema
How do I verify software builds and tests before claiming completion?

To verify software builds before claiming completion, you must execute the proving command afresh, read the full output, check the exit code, and confirm zero failures. Evidence must back every success claim.

Why does partial verification cause false success claims in quality assurance?

Partial verification causes false success claims because it skips reading full command outputs or checking exit codes. Claiming completion without fresh evidence from a complete test run is dishonesty, not efficiency.

What is the best way to enforce evidence-based validation in a development workflow?

The best way to enforce evidence-based validation is applying a gate function that mandates identifying, running, reading, and verifying fresh command outputs before making any success claims during the workflow process.

Can I trust agent success reports for issue resolution without fresh verification?

You cannot trust agent success reports without fresh verification. You must run the verification command in the current message and check the actual output and exit code before claiming issues are resolved.

When do I need fresh command output for gating a pull request?

You need fresh command output for gating a pull request whenever claiming tests pass, linters are clean, or builds succeed. Rushing to commit without running verification commands and reading results is a critical red flag.

What are common failure modes when validating software quality before completion?

Common failure modes when validating software quality include asserting success after partial checks, trusting past runs, and rationalizing with expressions like "should work now" instead of verifying fresh command outputs and exit codes.