Verification Before Completion

Verification Before Completion

Overview

Use this skill to enforce an evidence threshold before claiming "done", "fixed", or "ready to commit". Whenever you are about to express a success state, you must first run the validation corresponding to that conclusion.

Core Principle: No fresh evidence, no claiming success.

Use This Skill

• You are about to say "done", "fixed", or "tests passed".
• You are preparing to commit, create a PR, merge a branch, or finish a task.
• A subagent, script, or automated process claims it has succeeded.
• You need to convert "looks fine" into a verifiable conclusion.

Do Not Use

• You are still in the middle of troubleshooting or implementation, with no conclusion to claim yet.
• The user is only asking for ideas, approaches, or risks, rather than requesting confirmation of results.
• You currently cannot run any validation, and you are just explaining risks or blockers upfront.

Execution Protocol

1. Define What to Prove First

Before expressing a conclusion, ask yourself:

• Am I trying to prove "tests passed" or "build succeeded"?
• To prove "bug is fixed", what is the minimal validation path?
• To prove "requirement met", is there an item-by-item checklist?

2. Run the Corresponding Validation

Validation must map 1:1 to the conclusion:

• "Tests passed" -> Re-run the relevant tests.
• "Build succeeded" -> Re-run the build.
• "Bug fixed" -> Re-run the original reproduction path.
• "Requirement met" -> Verify against the checklist item by item.
• "Subagent is done" -> Check the changes yourself and re-verify the results.

3. Read the Full Results

Do not just look at the last line or the exit code. Confirm at least:

• Did the command execute completely?
• Is the exit code correct?
• Do the failure, error, and skip counts match expectations?
• Are there hidden exceptions, warnings, or environment issues in the output?

4. Write Conclusion Based on Evidence

• If the evidence supports the conclusion, explicitly state the scope of success.
• If the evidence does not support it, honestly report failure, partial pass, or unverified.
• If you can only verify a part, do not write partial success as overall success.

Common Mappings

Trae / Windows Conventions

• In Trae, use RunCommand, GetDiagnostics, Read, and necessary testing tools to collect evidence.
• Use PowerShell-compatible syntax for Windows host commands; do not execute Unix examples directly as host commands.
• If validation relies on subagents, browsers, external services, or local tools, explicitly state which evidence was actually run and which are just static checks.
• If validation is not complete, do not use vague wording to package it as a success.

Red Lines

• "It should be fine now."
• "Probably no issues."
• "I am very confident."
• Saying "It's done" before validating.
• Announcing overall completion after only partial checks.
• Trusting subagents, scripts, or historical results without re-verifying.

Failure Handling

• Validation failed: Report the real failure information; do not downplay it as "mostly done". If the failure reveals a non-obvious root cause, environment quirk, or configuration issue that future agents may encounter again, invoke self-improvement to log it as an Experience before moving on.
• Unable to run validation: Explicitly state the blocker, missing dependencies, and the currently unverified scope.
• Only partially verified: Restrict the conclusion to the verified scope.
• External dependency unavailable: Distinguish between "local static checks passed" and "end-to-end unverified".

Output Contract

When wrapping up with this skill, the output must contain at least:

• What was verified.
• What commands or checks were used.
• What the key results were.
• What the boundaries of the conclusion are.

Example:

Re-ran relevant tests and confirmed they passed:
- `npm test -- src/auth/auth.test.ts`
- Result: 12 passing, 0 failing

Therefore, I can only confirm the auth module changes passed this test scope; the full test suite was not re-run.

Integration

• test-driven-development: Upstream — handles the red-green loop; this skill handles the evidence check before the final claim.
• systematic-debugging: Upstream — handles finding the root cause; this skill confirms the result after fixing.
• receiving-code-review: Upstream — re-verify after review fixes are applied.
• git-commit: Downstream — finish the validations here before committing; do not reverse the order.
• finishing-a-development-branch: Downstream — after verification passes, route to finishing-a-development-branch for wrap-up (merge, PR, keep, or discard). For S (Small) Fast-Path per review-and-completion-gates.md, append wrap-up guidance directly instead of routing to this skill.
• requesting-code-review: Downstream — after verification, opt into code review before merging.
• usage-log（可选）: 当验证结果明显优于"无系统"时的典型表现（如发现了手动验证不会发现的 bug），在 docs/usage-log/USAGE-LOG.md 中追加一条记录以供将来参考。

Bottom Line

Validation is not a rhetorical action; it is an evidence-gathering action. Run first. Read second. Conclude last.