‹ 首页

proof-of-work

@darkroomengineering · 收录于 昨天 · 上游提交 昨天

Run the machine-verifiable gate (typecheck/test/lint, plus a screenshot for UI) so an agent's diff is "review-ready" before it reaches a human. Triggers "proof of work", "is this review-ready", "verify before review", "prove it is green", or after an agent finishes a diff-producing task.

适合你,如果你想让agent的代码在提交审查前自动通过质量门控。

/ 通过 npx 安装 校验哈希
npx oh-my-skill add darkroomengineering/cc-settings/proof-of-work
/ 通过 bash 安装
curl -fsSL https://oh-my-skill.com/install.sh | bash -s -- darkroomengineering/cc-settings/proof-of-work
/ 已经装过?验证本机副本,不用重装
npx oh-my-skill verify darkroomengineering/cc-settings/proof-of-work
安装目标可用 --agent / --scope 或 --to 明确指定;省略时只会在唯一已存在的 agent 目录上自动选择,零命中或多命中会停止并提示。content_hash 缺失或不一致均拒装。
40GitHub stars
~825上下文体积 · 单文件
索引托管

怎么用

商店整理自技能原文 · 版本 fa04efc · 表述以原文为准
它做什么

装上后,Claude 在完成代码改动后会自动运行类型检查、测试和代码检查,并生成一份“可审查”或“不可审查”的报告,UI 改动还会附带截图。

什么时候触发

当你说出“proof of work”、“is this review-ready”等触发词,或 Claude 完成一个产生代码改动的任务后自动触发。

装好后可以这样说
Claude 会运行自动化检查并报告结果。
Claude 会执行类型检查、测试和 lint。
Claude 会运行检查并返回“可审查”或“不可审查”。
技能原文 SKILL.md作者撰写 · MIT · fa04efc

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:

bun "$HOME/.claude/src/scripts/proof.ts"

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 (/qa or the chrome-devtools MCP) as the visual half of the proof — tests can't prove "looks right".

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 bun run proof itself. That gate is cheapest-first and runs constantly; a remote model call would make every proof slow. Run this probe by default on every diff-producing task when the bridge is available — skip it only for a trivial one-line/typo diff, which also keeps it cheap regardless of how roomy the Codex window is.

The contract
  • A diff-producing agent (implementer, scaffolder, 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, oracle) has no diff to prove — proof-of-work is for changes, not findings.

按 MIT 许可原样转载,未经改动 · 在 GitHub 查看 →

评论

登录即可评论;带「已验证安装」的,是发布者名下有本店的安装或持有记录。