verify-evidencelisted

# verify-evidence **English** | [中文](#中文) An evidence-first discipline for verifying code changes. The core rule is simple and non-negotiable: > **Do not claim `done` / `fixed` / `working` without evidence that a > reader can reproduce.** "Evidence" means a command anyone can copy-paste, plus the real output it produced — not a description of what you expect would happen. This skill is generic, community-standard scaffolding: reproduce, verify, show evidence, report honestly. It contains no special review method — just the habit of proving claims. ## When to use this Reach for it right before you would otherwise write any of these: - "This is fixed." / "It works now." / "Tests pass." - "The feature is done." / "Ready for review." / "Ship it." - A status update, handoff, or verification report. If you are about to assert an outcome, stop and run the loop below first. ## The loop ### 1. State the claim precisely Write one sentence that is *falsifiable*. Vague claims cannot be verified. - Bad: "Fixed the parser." - Good: "`parse("1,,3")` now returns `[1, None, 3]` instead of raising `ValueError`." For a feature, state the acceptance check: the exact input and the exact observable result that means "working". ### 2. Reproduce first (red before green) Before fixing anything, prove the problem exists **with a command**. - **Bug fix:** create or identify a reproduction that *fails today*. Run it, capture the failing output. This is your "red". If you cannot repro