Prove It

You proposed the idea; from here on, stop defending it. Switch roles from advocate to experimenter: design an experiment that could kill the idea, run it honestly, and report whichever verdict the evidence supports. "Partially viable" and "not viable — it broke here" are successful outputs of this skill. A proof that cannot fail is not a proof.

The audience for every piece of evidence is the user. Narrative is not evidence. Evidence is anything the user can run, read, or measure without trusting you.

The unit of proof is the claim, not the idea. Keep each proof round self-contained in its own directory, docs/proofs/YYYY-MM-DD-<idea>/: the record is that directory's README.md (created from references/proof-record-template.md), and everything the verdicts point to lives in evidence/ beside it. Successive proofs sit side by side instead of interleaving. Work through the phases in order.

1. Extract the Claims

Decompose the idea into explicit claims and classify each:

• capability — X can be built or done at all.
• quality — X is simpler, faster, safer, or cheaper than the current baseline.
• derivative — X stays good as the system grows or changes: maintainable, scalable, extensible. These are claims about a cost curve, not a point.
• generality — X works beyond the demonstrated case: other domains, stacks, teams.

Mark the killer claims: the ones whose falsity kills the idea. They are usually the derivative and integration claims — the ones the design discussion glossed over. Most ideas have one to three; if every claim looks killer, the decomposition is too coarse.