agentleFS
darkroomengineeringdarkroomengineering/cc-settings/skills/proof-of-work/SKILL.md

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".

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
  1. Distinctive:

    Run the battery on the current working tree:

    line 12
  2. Very specific:

    Use spawn_agent to create a fresh read-only reviewer, send_message to deliver context while it runs, followup_task to trigger another turn …

    line 31

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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" review

Treat 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.

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.