Convince Me

Prove that completed work satisfies its original goal. Produce fresh, observable evidence — not confidence, code inspection alone, or results remembered from earlier in the session. This skill proves; it does not repair. Report failures instead of fixing them.

1. Establish the case

Read the original request, available spec or ticket, acceptance criteria, relevant changes, and existing tests. Translate every expectation into an observable claim. Keep the agreed environment and safety limits attached to those claims; stronger guarantees are scope proposals, not silently added acceptance criteria.

Inspect the available context before asking questions. Ask all questions whose answers would materially change the proof together, in one message.

Complete when: every expectation has an observable claim with agreed limits, and material ambiguities are resolved.

2. Design the proof

For each claim, choose the strongest practical verification boundary. Prefer the real user path and production-like integration over isolated implementation details.

Cover the successful path and any material failure, boundary, or regression paths. Existing tests count as evidence only when run now. Supplement them with a focused test, script, fixture, manual interaction, screenshot, or disposable harness when they do not prove the claim. One executed check may support several claims.

One-off verification may be rough, but it must be safe and scoped. Get approval before destructive actions, external side effects, production access, or spending money. When approval or the required environment is unavailable, mark the affected claim unverified.