proof-of-work
Skill52 starsChanged 50 days agoMITView on GitHub
Run the machine-verifiable gate (typecheck, test, lint, plus a screenshot for UI) so a diff is review-ready. Triggers "proof of work", "is this review-ready", "prove it is green".
In this repository27 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .claude/AGENTS.mdAGENTS.md
- auditSkill
- autoresearchSkill
- buildSkill
- case-studySkill
- ccSkill
- codexSkill
- componentSkill
- context-docSkill
- dr-initSkill
- dr-reviewSkill
- fixSkill
- freezeSkill
- handoffSkill
- harvestSkill
- hookSkill
- orchestrateSkill
- poke-holesSkill
- refactorSkill
- retroSkill
- review-batchSkill
- share-learningSkill
- shipSkill
- storiesSkill
- triageSkill
- zero-tech-debtSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 1 is distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 12
Run the battery on the current working tree:
- Very specific: line 31
Use spawn_agent to create a fresh read-only reviewer, send_message to deliver context while it runs, followup_task to trigger another turn …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Proof of Work
The Amdahl-shrink move from the Orchestration Tax: human review is the serial bottleneck, so don't spend it confirming what a machine can verify. An agent's diff is review-ready only when the machine-verifiable battery is green — types, tests, lint (and a screenshot for UI). What a machine can prove shouldn't cost a human's attention.
The gate
Run the battery on the current working tree:
PROOF_RUNNER="${CODEX_HOME:-$HOME/.codex}/darkroom/source/src/scripts/proof.ts"
[ -f "$PROOF_RUNNER" ] || PROOF_RUNNER="$HOME/.claude/src/scripts/proof.ts"
bun "$PROOF_RUNNER"This is the portable installed runner — it works in any repo. (bun run proof is a shortcut that only exists inside the cc-settings repo itself; don't reach for it in a consumer project.) It detects typecheck / test / lint from the project's package.json, runs them cheapest-first, and prints one verdict:
- exit 0 →
review-ready ✓ - exit 1 →
NOT review-ready ✗— fix the failing gate before a human looks
Projects can opt into advisory probes by depending on the tool — the gate then runs the project's pinned binary: react-doctor (React render/quality score, telemetry off) and/or deslop (framework-agnostic cross-file dead-code count). Advisory results are reported but never flip the verdict — deterministic signals alongside the hard gates, not blockers. Silent for projects that don't depend on them.
For UI changes, attach a screenshot (via the tester agent, which starts the chrome-devtools MCP for the run) as the visual half of the proof — tests can't prove "looks right".
Standalone Codex semantic probe
Use spawn_agent to create a fresh read-only reviewer, send_message to
deliver context while it runs, followup_task to trigger another turn once it
is idle, wait_agent to wait, and interrupt_agent only to stop its current
turn. Treat findings as advisory beside
the mechanical verdict. Never spawn codex-verifier and never run codex-run.ts from inside Codex.
Skip the Claude bridge branch below.
Writers share the working tree unless the live host explicitly offers isolation. Only read-only reviewers may overlap; serialize any implementer and test-writer remediation with non-overlapping ownership. For UI proof, use the Chrome MCP only when the user configured it. Otherwise use native/manual screenshot tooling and state what could not be visually verified. This package does not auto-run unpinned registry MCP packages.
Advisory: cross-model semantic probe (when the Codex bridge is available)
The mechanical battery proves the diff is self-consistent — it compiles, tests pass, lint is clean. It cannot prove the diff is correct: a bug that typechecks and passes the tests you wrote sails straight through. When the Codex bridge is available, add a semantic probe from a different model family on top of the mechanical gate:
bun "$HOME/.claude/src/scripts/codex-run.ts" reviewTreat it exactly like react-doctor and deslop: advisory — reported alongside the verdict, never flips it. A green mechanical gate stays review-ready even if Codex raises a finding; surface the finding for the human to weigh, don't block on it. The bridge is gated and fails open — silent when Codex isn't installed, authed, or has quota.
Keep it out of the proof runner itself. That gate is cheapest-first and runs constantly; a remote model call would make every proof slow. Run it as the one cross-model review per PR, /ship, or direct push to the default branch (see CLAUDE-FULL.md "Claude and Codex routing"), or when the user asks. Do not repeat it on each diff-producing task, and skip it if a Codex review already covered this diff.
The contract
- A diff-producing agent (implementer, maestro, deslopper) attaches a proof report before handing back. "Done" without green proof is not done.
- The human/reviewer spends the lock on judgment — architecture, intent, edge cases — not on re-running what the gate already proved.
- Pairs with the review-queue: backpressure (
the review-queue branch of tool-cadence.ts) limits how many unproven diffs pile up; this gate makes each one cheaper to close.
When NOT to gate
Pure-research or read-only agent output (explore) has no diff to prove — proof-of-work is for changes, not findings.
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.

