prove-github-issue
Skill8 starsChanged 4 months agoMITView on GitHub
The Proving lane of the fix pipeline: one headless agent turn, on a fresh context, that proves a commit a coder pushed for a GitHub issue and hands it to review as a ready pull request carrying that proof, per `prove-work-on-github`. It changes no code and pushes nothing to the branch; a change it cannot prove goes back to the coder with what is missing. Run by `fix-github-issue` (and so by `burn-down-github-issues`) after every push it announces, after a reviewer asks for more evidence, and after the base moves beneath an existing proof. Skip it for writing the change or for judging someone else's proof.
In this repository23 other files it gives its agents.
- skills/asset-optimization/AGENTS.mdAGENTS.md
- android-emulator-harnessSkill
- android-emulator-mask-testingSkill
- appraise-github-issuesSkill
- asset-optimizationSkill
- burn-down-github-issuesSkill
- carve-github-issueSkill
- code-github-issueSkill
- emoji-readoutSkill
- expo-developer-toolsSkill
- expo-ios-simulatorSkill
- fix-github-issueSkill
- how-to-planSkill
- ios-simulator-flow-evidenceSkill
- ios-simulatorSkill
- ios-simulator-triageSkill
- mobile-accessibilitySkill
- playwright-camera-mask-testingSkill
- playwright-gif-captureSkill
- playwright-harnessSkill
- playwright-storybook-flowsSkill
- prove-work-on-githubSkill
- zone-composerSkill
The file
Files
Prove GitHub Issue
One seat, one lane: Proving (D2). The prover's turn ends at a ready pull request whose head is the proven commit. It starts from durable state alone (the issue, the pushed branch, and the coder's announcement on the thread), so it never inherits a coder's long transcript, and a prover that is killed costs only the proof: the coded commit stands, and the next attempt proves it again rather than coding it again.
This feature is about a proof; its children are receipts: artifacts pinned to commits the remote holds, each covering one thing the change claims.
| Verdict | What it means | What happens next |
proved | a ready pull request, pr, whose head is sha, the lane's head | the card goes to review |
unprovable | the change does not do what the issue asks, or what it claims cannot be shown; brief says what | the driver announces it (<!-- loop-step unproved ... -->), spends an attempt, and a coder fixes it on the same branch |
needs-decision, needs-human | proof needs a ruling, or access an agent lacks | the issue is held with the question stated |
failed | anything else | the attempt is counted; the coded commit stands |
What a prover is told, and what it is not
The prompt is prompts/prove.md. Its brief is the coder's hand-off on a first proof, the
reviewer's points when a review asked for more evidence, or the catch-up that moved the base
beneath an existing proof. It loads prove-work-on-github for the definition of proof.
The prover always runs project.ciCommand when configured. Otherwise it runs checkCommand
when the head differs from the coder's gated commit, or that commit is unknown; at the same gated
head the coder's gate stands and is not rerun. Before an owed run it runs installCommand; on a
changed or unknown gated head it runs checkCommand first, even with ciCommand configured.
It records only the deciding command in gateRun, with the exact command, full SHA, and numeric
exit code. A failing run is unprovable. Focused evidence comes in addition to that run, never
instead of it. Like the coder, it never chases the base itself.
How the driver checks the answer
lib/prove.ts exports runProve(ctx, issue, cwd, coded, brief). It runs the seat and returns its
answer, or failed when the answer cannot be believed: a crash, a kill at the cap, an unknown
verdict, a proved that names no pull request or is pinned to a head other than the lane's, or an
unprovable that tells the coder nothing to fix. The control file is loop-proof.json.
Hard dependencies
- The sibling
fix-github-issueskill, imported for the agent runner, the context, the prompt renderer, and the Work markers. It ships in the same collection and is what runs this seat. - The sibling
prove-work-on-githubskill, which the prover loads. ghauthenticated with pull-request rights, and the CLI theworkerseat names, onPATH.
The ceiling, named
A proof is evidence an independent reviewer can re-check, not a verdict; the reviewer, on another engine, still decides whether it is enough. The prover runs on the same engine as the coder by default: a fresh context stops proof-by-memory, and engine independence is the reviewer's job.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

