Proof of Work 是一个面向开发工作流的技能，核心理念是“展示，而不是声称”（Show, don't tell）。它要求：任何关于代码质量、测试结果、构建状态或验证的断言，都必须由真实的命令输出支撑，而不能用总结或假设代替。
一、实现证据（Implementation Proof） 在实现功能时，必须实际使用 Write/Edit 工具进行变更，而不能只描述应该写什么。具体做法：调用 Write 创建文件、调用 Edit 修改文件；展示工具返回结果，如“Successfully wrote /path/to/file.ex”“Successfully edited /path/to/file.ex”；再用 Bash（如 ls -la /path/to/file.ex）确认文件存在，必要时用 Read 展示内容。原文强调：如果没有使用 Write/Edit 工具，就等于没有发生。
二、代理验证（Agent Verification，关键） 这是零容忍规则：绝不能不加验证就信任子代理的完成报告。代理报告只是“声称”，不是证据。子代理报告“成功创建 X、修改 Y、实现完成”时，必须停下来，不要直接相信，而要执行强制验证：
- git status --short，确认文件确实被修改；
- git diff --name-only，确认实际变更存在；
- ls -la /path/to/file，确认代理声称创建的文件存在；
- cat /path/to/file | head -20，抽查文件内容。 如果 git status 显示工作区干净，那么无论代理报告说什么，都等于什么都没做。原文列出了常见红旗报告及其对应验证方式：声称“成功创建 X”要用 ls 证明文件存在；声称“修改了 A、B、C”要用 git status 证明；声称“对 Y 做了变更”要用 git diff Y 证明；声称“实现完成”要用 git diff --stat 证明；声称“给 Z 加了测试”要用 cat Z 证明；声称“更新了配置”要用 git diff config/ 证明。
三、强制验证工作流 委派任务给代理 → 代理报告完成 → 停止，不要信任报告 → 运行验证命令 → 验证失败则说明代理并未完成 → 验证通过后再带证据向用户汇报。向用户汇报时，必须先展示 git status、ls、head 等实际输出，然后才能说“代理已完成，验证证明修改了 2 个文件（证据如上）”。原文强调：不验证代理工作会破坏用户信任、浪费用户时间、产生虚假结论，是灾难性错误。
四、证据要求 永远不要在没有证据时声称“测试通过”“构建成功”“没有 lint 问题”“类型检查通过”“流水线是绿的”“代码很干净”。必须在运行命令后展示真实输出，例如 mix test 的完整结果（1,247 tests, 0 failures）、lint 输出、yarn ts:check 输出、CI 流水线状态与 URL 等。
五、零容忍假设与部分验证 原文禁止说“测试应该会通过”“这大概能行”“基于我的修改，测试会通过”“我预计构建会成功”，正确做法是承认“我还没运行测试，现在运行”并展示完整输出。同时，部分验证不算验证：只跑了 1,247 个测试中的 50 个就停下并声称“测试通过”是错误的，必须跑到全部完成。
六、输出格式与适用场景 要求展示所运行的命令、结果而非总结、包含计数（测试数、文件数、错误数）、远程资源附 URL。该技能适用于任何可验证的开发断言：测试通过/失败、构建成功/失败、lint 是否干净、类型检查、GraphQL 兼容性验证、CI 流水线状态、代码审查结论、性能指标等。原文还给出了实现、代码审查、调试三类工作流的整合方式：实现时运行验证并展示完整输出后等待批准；代码审查引用行号、引用问题、展示分析器输出；调试时展示完整错误、堆栈与复现步骤及输出。
关于收费、价格、支持平台、安装方式等信息，当前资料暂未提供。