Prove Work on GitHub

A claim is narrative; a receipt is proof. The remote is the witness, not your intent to push.

A statement about a change ("the fix works", "CI is green", "the screen looks right", "it is ready to merge") is narrative until it is paired with a receipt: verifiable evidence that you observed and that a reader can independently re-check. "I ran the command" is not "the remote advanced." A green checkmark is not "the feature is correct." This skill is the discipline that turns claims into receipts, sizes how much proof a change owes, stores the receipts durably on the pull request, and judges whether they are enough to merge.

Proof is asymptotic

Proof is never perfect; it only approaches the asymptote of perfection. The categories below are open sets, not closed enums: when you find a new signal that makes a change more provable, add it (extend your copy, or propose it upstream). The rubric ships incomplete by design and improves by contribution. A skill that claims a finished, total account of proof is lying.

When proof is owed

Proof is owed when a claim about a change would change what a reviewer or a merge gate does, and the claim is not self-evident from the diff. Match the rigor to the change (see references/physical.md); a typo and a schema migration do not earn the same receipt. Skip when the diff is its own proof, or when the work never reaches GitHub.

The model: three aspects and a judgement

Three measured aspects of a change, and a judgement that interprets them. Judgement is last.

Physical sizes the bar; Correctness names what must be proven; Evidence supplies the receipts; Judgement reads the three and returns an action: merge, gather more, or block.

The lifecycle (what you do)

Cross-cutting non-negotiables

• Pin to an immutable referent. Cite a full commit SHA, a content-addressed artifact, or a permalink with the commit hash; never a moving target. The embedded SHA is what fixes the bytes under the reference; append-only is a convention kept on top of that, not something the branch enforces.
• Never let a receipt leak. A pasted log can dump a token; a screenshot can catch a secret. Redact before you store or present.
• Keep capture read-only. Acquiring proof of a change must not alter the system under proof.
• Make every receipt re-checkable by someone else. If a second reader cannot click it, re-run it, or verify its hash, it is not proof.

Reference index

Extending this skill

A living document; the categories grow as you find new ways to prove. Every new fact has one home:

When the signal is genuinely new, extend the rubric (in your copy, or propose it upstream); see "Proof is asymptotic."

Acceptance: a claim is proven when

• Every load-bearing claim about the change has a receipt; nothing rests on narrative alone.
• Each receipt cites an immutable referent and is re-checkable by a second reader.
• The evidence covers what the change owes (its Correctness claims) at the depth its Physical size demands.
• Judgement returns merge: adequacy clears the bar, and confidence is not undercut by an uncoverable blind spot on a load-bearing claim.
• No receipt leaks a secret, and no capture mutated the system under proof.

If any item fails, you have a story, not proof.