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.
| Aspect |
Question |
| Physical |
what is the change, and how much does it therefore owe (surface area, complexity, and reversibility)? |
| Correctness |
is the change sound (alignment, verifiability, durability, and security)? |
| Evidence |
what receipts does that change require, by type, and at what fidelity? |
| Judgement |
is the evidence adequate, and how confident are you to merge? |
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)
| # |
Step |
| 1 |
Size the change (Physical) and name what it must prove (Correctness) |
| 2 |
Acquire the evidence the change owes, by type |
| 3 |
Store it in the evidence branch and render it inline |
| 4 |
Judge adequacy and confidence, and act |
| 5 |
Re-judge when the repo moves and the proof goes stale |
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
| Need |
Read |
| Size the change: surface area, complexity, reversibility, and the metrics behind them |
references/physical.md |
| Is the change sound: alignment, verifiability, durability, and security |
references/correctness.md |
| Judge adequacy versus confidence and map the score to an action |
references/judgement.md |
| Capture the evidence a change type owes |
references/acquire.md |
| The evidence branch: storage, protection, naming, and fidelity |
references/evidence-locker.md |
| Prepare an artifact for GitHub: format, compression, and sizing |
references/optimize-assets.md |
| Compose and render proof inline in the comment |
references/render.md |
| The per-artifact metadata that ties it together |
references/artifact-manifest.md |
| When proof has gone stale and what to reacquire |
references/freshness-and-reproof.md |
| Worked examples of strong and fake proof |
references/catalog.md |
Extending this skill
A living document; the categories grow as you find new ways to prove. Every new fact has one home:
| A new fact is... |
Home |
| a sizing signal for the change |
references/physical.md |
| a soundness signal (alignment, verifiability, durability, or security) |
references/correctness.md |
| a judgement element or a scoring rule |
references/judgement.md |
| a capture method for a change type |
references/acquire.md |
| a storage, protection, or naming rule for the evidence branch |
references/evidence-locker.md |
| an artifact format or optimization |
references/optimize-assets.md |
| a rule for rendering proof inline |
references/render.md |
| an attribute of an artifact |
references/artifact-manifest.md |
| a staleness or reproof rule |
references/freshness-and-reproof.md |
| a cross-cutting non-negotiable |
this SKILL.md |
| a worked example of strong or fake proof |
references/catalog.md |
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.
1---2name: prove-work-on-github3description: Prove that work claimed on a pull request or issue actually landed and is sound, with verifiable evidence a reader can independently re-check. A claim is narrative; a receipt is proof. Use when deciding what evidence a change owes, capturing it (screenshots, GIFs, logs, database shape, over-the-wire results, test and coverage output), storing it in a durable evidence branch, rendering it inline in a PR or issue comment, judging whether the evidence is adequate to merge, or checking whether existing proof has gone stale. Triggers: "prove this works", "what evidence does this PR need", "attach proof to the PR", "is this enough to merge", "evidence locker", "is this proof still valid". Skip for trivial changes whose proof is the diff itself, and for work that never touches GitHub.4---56# Prove Work on GitHub78> A claim is narrative; a receipt is proof. The remote is the witness, not your intent to push.910A statement about a change ("the fix works", "CI is green", "the screen looks right", "it is11ready to merge") is narrative until it is paired with a **receipt**: verifiable evidence that you12observed and that a reader can independently re-check. "I ran the command" is not "the remote13advanced." A green checkmark is not "the feature is correct." This skill is the discipline that14turns claims into receipts, sizes how much proof a change owes, stores the receipts durably on the15pull request, and judges whether they are enough to merge.1617## Proof is asymptotic1819Proof is never perfect; it only approaches the asymptote of perfection. The categories below are20open sets, not closed enums: when you find a new signal that makes a change more provable, add it21(extend your copy, or propose it upstream). The rubric ships incomplete by design and improves by22contribution. A skill that claims a finished, total account of proof is lying.2324## When proof is owed2526Proof is owed when a claim about a change would change what a reviewer or a merge gate does, and27the claim is not self-evident from the diff. Match the rigor to the change (see28`references/physical.md`); a typo and a schema migration do not earn the same receipt. Skip when29the diff is its own proof, or when the work never reaches GitHub.3031## The model: three aspects and a judgement3233Three measured aspects of a change, and a judgement that interprets them. Judgement is last.3435| Aspect | Question |36|--------|----------|37| **Physical** | what is the change, and how much does it therefore owe (surface area, complexity, and reversibility)? |38| **Correctness** | is the change sound (alignment, verifiability, durability, and security)? |39| **Evidence** | what receipts does that change require, by type, and at what fidelity? |40| **Judgement** | is the evidence adequate, and how confident are you to merge? |4142Physical sizes the bar; Correctness names what must be proven; Evidence supplies the receipts;43Judgement reads the three and returns an action: merge, gather more, or block.4445## The lifecycle (what you do)4647| # | Step |48|---|------|49| 1 | Size the change (Physical) and name what it must prove (Correctness) |50| 2 | Acquire the evidence the change owes, by type |51| 3 | Store it in the evidence branch and render it inline |52| 4 | Judge adequacy and confidence, and act |53| 5 | Re-judge when the repo moves and the proof goes stale |5455## Cross-cutting non-negotiables5657- **Pin to an immutable referent.** Cite a full commit SHA, a content-addressed artifact, or a58 permalink with the commit hash; never a moving target. The embedded SHA is what fixes the bytes59 under the reference; append-only is a convention kept on top of that, not something the branch60 enforces.61- **Never let a receipt leak.** A pasted log can dump a token; a screenshot can catch a secret.62 Redact before you store or present.63- **Keep capture read-only.** Acquiring proof of a change must not alter the system under proof.64- **Make every receipt re-checkable by someone else.** If a second reader cannot click it, re-run65 it, or verify its hash, it is not proof.6667## Reference index6869| Need | Read |70|------|------|71| Size the change: surface area, complexity, reversibility, and the metrics behind them | `references/physical.md` |72| Is the change sound: alignment, verifiability, durability, and security | `references/correctness.md` |73| Judge adequacy versus confidence and map the score to an action | `references/judgement.md` |74| Capture the evidence a change type owes | `references/acquire.md` |75| The evidence branch: storage, protection, naming, and fidelity | `references/evidence-locker.md` |76| Prepare an artifact for GitHub: format, compression, and sizing | `references/optimize-assets.md` |77| Compose and render proof inline in the comment | `references/render.md` |78| The per-artifact metadata that ties it together | `references/artifact-manifest.md` |79| When proof has gone stale and what to reacquire | `references/freshness-and-reproof.md` |80| Worked examples of strong and fake proof | `references/catalog.md` |8182## Extending this skill8384A living document; the categories grow as you find new ways to prove. Every new fact has one home:8586| A new fact is... | Home |87|---|---|88| a sizing signal for the change | `references/physical.md` |89| a soundness signal (alignment, verifiability, durability, or security) | `references/correctness.md` |90| a judgement element or a scoring rule | `references/judgement.md` |91| a capture method for a change type | `references/acquire.md` |92| a storage, protection, or naming rule for the evidence branch | `references/evidence-locker.md` |93| an artifact format or optimization | `references/optimize-assets.md` |94| a rule for rendering proof inline | `references/render.md` |95| an attribute of an artifact | `references/artifact-manifest.md` |96| a staleness or reproof rule | `references/freshness-and-reproof.md` |97| a cross-cutting non-negotiable | this `SKILL.md` |98| a worked example of strong or fake proof | `references/catalog.md` |99100When the signal is genuinely new, extend the rubric (in your copy, or propose it upstream); see101"Proof is asymptotic."102103## Acceptance: a claim is proven when104105- Every load-bearing claim about the change has a receipt; nothing rests on narrative alone.106- Each receipt cites an immutable referent and is re-checkable by a second reader.107- The evidence covers what the change owes (its Correctness claims) at the depth its Physical size demands.108- Judgement returns merge: adequacy clears the bar, and confidence is not undercut by an uncoverable blind spot on a load-bearing claim.109- No receipt leaks a secret, and no capture mutated the system under proof.110111If any item fails, you have a story, not proof.
simiancraft