菜单
Enforces validation and evidence before claiming work complete. Use before declaring implementation done, creating a PR, or submitting deliverables for review.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/athola/claude-night-market --skill proof-of-work命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Turn hunches into accepted results: worthiness score, evidence bar, research-to-rules. Use when vetting ideas. Not for QA; use night-market-validation-and-qa.
Generates and self-executes a diff-derived test plan for a PR. Use when validating PR changes before merge. Do not use for code review; use sanctum:pr-review.
Curate the web-capture index. Use when the capture backlog grows, captures sit unprocessed at seedling/pending, or to surface stored research during work.
正在显示 SKILL.md
基于 SOC 职业分类
| name | proof-of-work |
| description | Enforces validation and evidence before claiming work complete. Use before declaring implementation done, creating a PR, or submitting deliverables for review. |
| alwaysApply | false |
| category | workflow-methodology |
| tags | ["validation","testing","proof","definition-of-done","acceptance-criteria"] |
| dependencies | [] |
| tools | [] |
| usage_patterns | ["completion-validation","acceptance-testing","proof-generation"] |
| complexity | intermediate |
| model_hint | standard |
| estimated_tokens | 3000 |
| modules | ["modules/acceptance-criteria.md","modules/anti-cargo-cult.md","modules/evidence-logging.md","modules/independent-verification.md","modules/iron-law-enforcement.md","modules/output-contracts.md","modules/red-flags.md","modules/retry-protocol.md","modules/todowrite-patterns.md","modules/validation-protocols.md","modules/verifier-integrity.md"] |
| role | library |
"It looks correct" is not "I verified it works." Proof-of-work is the discipline of closing that gap: reproducible evidence before any claim that a task is done.
imbue:karpathy-principles)imbue:scope-guard)The "Proof of Work" methodology prevents premature completion claims by requiring technical verification before stating that a task is finished. For example, instead of assuming an LSP configuration functions after a restart, we verify that the server starts and that tools respond to queries. This approach confirms the solution works before the user attempts validation.
Before claiming completion, provide reproducible evidence of the solution's performance and address edge cases. All claims must be backed by actual command output captured in the current environment.
NO IMPLEMENTATION WITHOUT A FAILING TEST FIRST NO COMPLETION CLAIM WITHOUT EVIDENCE FIRST NO CODE WITHOUT UNDERSTANDING FIRST
The Iron Law prevents testing from becoming a perfunctory exercise. If an implementation is planned before tests are written, the RED phase fails to drive the design. Understand the technical rationale for an approach and its limitations before declaring it done. Before writing code, document evidence of the failure being addressed and confirm that tests are driving the implementation.
Verify the fundamentals of the implementation and the reasons for choosing it over alternatives. Identify where a solution might fail rather than stating it should always work. The TDD cycle follows these mandatory steps:
| Self-Check Question | If Answer Is Wrong | Action |
|---|---|---|
| Do I have documented evidence of failure/need? | No | STOP, document failure first |
| Am I testing pre-conceived implementation? | Yes | STOP, let test DRIVE design |
| Am I feeling design uncertainty? | No | STOP - uncertainty is GOOD |
| Did test drive implementation? | No | STOP - doing it backwards |
proof:iron-law-red: Failing test written before implementation.proof:iron-law-green: Minimal implementation passes test.proof:iron-law-refactor: Code improved without behavior change.proof:iron-law-coverage: Coverage gates passed (line, branch, and mutation).Confirm that work passes all line, branch, and mutation coverage gates. For detailed enforcement patterns, see iron-law-enforcement.md.
Apply this skill before stating that work is "done," "finished," or "ready." Use it before recommending solutions or stating that a configuration "should work." Stop if you find yourself assuming a configuration is correct without testing it or recommending a fix without first reproducing the problem. Red flags include thinking "this looks correct" without actual verification. If you cannot explain each line of a configuration or why a specific practice applies to the current context, the necessary validation steps have been skipped.
proof:problem-reproduced)Before proposing a solution, verify the current state. Use tools like
ps, echo, and cat to check running processes, environment
variables, and configuration files. Document the failure with command
output and error logs.
proof:solution-tested)Before claiming a solution works, execute it in the current environment. Capture the actual output and confirm that it matches expected behavior. Do not rely on assumed output.
proof:edge-cases-checked)Research known bugs and limitations related to the approach. Check GitHub issues, version compatibility, and official documentation to identify potential blockers or common pitfalls.
proof:evidence-captured)Use imbue:proof-of-work to document the commands executed, their
output, timestamps, and the conclusions drawn from each step.
proof:completion-proven)Define acceptance criteria and validate each item. If a blocker is identified, document the diagnosis with evidence and provide workaround options instead of claiming completion.
Use proof-of-work to validate improvement opportunities identified by
/update-plugins or /fix-workflow. Document the baseline metrics
(step count, failure rate, duration), test the proposed changes, and
capture the improved metrics to demonstrate quantitative impact.
Verify that the problem was reproduced with evidence and the solution was tested in the actual environment. Research known issues and consider edge cases. Capture evidence in a reproducible format and confirm that all acceptance criteria are met. The completion statement must detail the specific tests run and their results, citing evidence for each claim.
Before sending a completion message, confirm that you have run the recommended commands and captured their output. Verify that you have researched known issues and that the validation steps are reproducible by the user. Ensure you are proving rather than assuming.
imbue:karpathy-principles: the "Goal-Driven Execution" principle
wraps the Iron Law in a four-principle synthesis useful as a
pre-flight gatedocs/quality-gates.md#skill-level-quality-gate-composition for
the full gate-skill federation graphproof:iron-law-red, proof:iron-law-green) confirming
test-first execution.[E1]/[E2] evidence reference exists in the
response, backed by a real command invocation and its output.