49 lines
1.4 KiB
Markdown
49 lines
1.4 KiB
Markdown
---
|
||
name: verification-before-completion
|
||
description: "Evidence-based verification before claiming completion. Triggers: verify, verification, run tests, prove, 验证, 跑一下, 确认一下, 自证."
|
||
---
|
||
|
||
# Verification Before Completion（先验证再宣称完成）
|
||
|
||
## When to Use
|
||
|
||
- Any task where correctness matters (bug fixes, refactors, releases)
|
||
- When the environment is complex or assumptions are likely
|
||
|
||
## Inputs（required）
|
||
|
||
- What “done” means (acceptance criteria)
|
||
- The smallest verification command(s) that prove it
|
||
- Constraints: cannot run tests? no access? limited environment?
|
||
|
||
## Procedure（default）
|
||
|
||
1. **Define Success Signals**
|
||
|
||
- Tests passing, build artifacts produced, commands return 0
|
||
- Specific output text or file diffs
|
||
|
||
2. **Run the Smallest Check**
|
||
|
||
- Start narrow (changed module tests) then broaden if needed
|
||
|
||
3. **Record Evidence**
|
||
|
||
- Capture key output lines, exit codes, and relevant file paths
|
||
|
||
4. **Handle Gaps**
|
||
- If verification can’t be run, say why and offer alternatives (manual checklist, static reasoning, targeted logs)
|
||
|
||
## Output Contract（stable）
|
||
|
||
- What changed
|
||
- What was verified (exact commands)
|
||
- Evidence (exit codes / key outputs)
|
||
- What was not verified (and why)
|
||
- Next steps (if any)
|
||
|
||
## Guardrails
|
||
|
||
- Don’t claim “fixed” without a verification signal
|
||
- Prefer repeatable commands over subjective inspection
|