agentleFS
simiancraftsimiancraft/simiancraft-skills/skills/prove-github-issue/SKILL.md

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.

The file

Files
SKILL.md

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.

VerdictWhat it meansWhat happens next
proveda ready pull request, pr, whose head is sha, the lane's headthe card goes to review
unprovablethe change does not do what the issue asks, or what it claims cannot be shown; brief says whatthe driver announces it (<!-- loop-step unproved ... -->), spends an attempt, and a coder fixes it on the same branch
needs-decision, needs-humanproof needs a ruling, or access an agent lacksthe issue is held with the question stated
failedanything elsethe 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-issue skill, 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-github skill, which the prover loads.
  • gh authenticated with pull-request rights, and the CLI the worker seat names, on PATH.

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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.