nextclaw: Skill for Claude Code

Development Validation

目标

用充分证据覆盖风险，避免重复验证。

AI 验收（mode=acceptance）

实现稳定后按原始需求及已确认变更逐项核对“用户结果 → 产物/真实入口 → 当前证据”，标记 passed/failed/unverified，同步已有验收账本及 stable IDs。沿约定角色、触发到最终结果验证，区分真实运行与演练；复用有效证据，测试数量或局部记录不能证明完整覆盖。

跨架构交付按合同的双向对账，从可执行产物和环境复核旧→新变化及目标→新缺口；条件能力须实际进入相应分支。缺入口或只验证常规分支不能 passed。验证者可以仍是实现者，但证据必须来自产物与运行结果，不能由设计说明和验收表互相背书。

性能或成本为 Required 项时，按冻结的任务、负载、环境和口径测量用户可感知延迟及实际资源用量，并核对计费依据；同条件比较报告样本量、分位数或区间、冷/热与条件分支、固定/边际成本。估算与线上实测分开，说明外部模型、网络和缓存等变量。不能用启动时间代替端到端等待、一次最佳值代替尾延迟，或空闲单用户成本代替约定使用量。未达门槛或关键分支无证据则保持 failed/not-run 并返工，不以功能测试通过宣布交付。

有原型/附件等输入基准时，从日志或任务已有输入定位适用版本，按约定用途直接对比实现：功能形态、用户链路、交互/状态及要求保持的外观。设计自身的测试不能替代来源核对；只作参考的维度不强加一致性。记录对应证据与差异；原件不可访问或未核对则相关项不能 passed，不以截图相似证明功能一致。

缺实现/证据返回对应阶段继续循环；标准漏项返回设计，不按已实现部分缩减需求。仅缺授权/外部依赖时完成可做准备并报告阻塞。阶段验收须用户明确约定。

必需项全部有效通过才输出 acceptance-ready，附范围、证据与主观确认项；总流程结合 Review 进入 Delivery。Delivery只消费结论和交接，不重做需求验收；不宣称用户验收通过。

风险分级

L0：文档与元信息

• 普通文档只做链接、格式、结构或 diff 检查。流程/授权等规则语义变更按实际影响验证路由、反例与合同，不因 Markdown 归为低风险；纯规则不运行产品 build/tsc/冒烟。

L1：局部低风险

• TypeScript/TSX 触达时运行最窄可覆盖改动的 tsc。
• 源码触达时运行一次 targeted ESLint；不先跑会被无关债务阻塞的全 package lint。
• 纯视觉修改证明目标页面能加载、目标样式已生效；审美偏好交给用户确认。未改变交互或数据语义时，不增加全链路冒烟或多张截图。

L2：局部行为与 bugfix

• 选择一份最贴近风险的定向测试。
• 从真实用户路径、最近链路冒烟、assembled boundary test 中选择优先级最高且成本合理的一条功能证据；定向测试已组装真实边界并证明同一合同可兼任，不机械追加第二份。
• Task Understanding 选择 reproduce 时，保留修前失败证据，并用同一入口和观察指标证明修后通过；昂贵端到端复现可以降到命中同一违约点的边界回放或定向失败测试。
• Task Understanding 选择 skip-reproduction 时，核对其直接根因证据和预先声明的替代验证；只有替代证据能确定证明原合同恢复时才可通过，并披露没有修前失败基线。
• 验证中发现根因、失败边界或判定条件仍不确定时，原跳过决定失效，返回 Task Understanding 补复现，不在 Validation 内猜测成功。

L3：跨边界与高影响

• 纯规则用治理检查与场景审查；以下运行链路要求不适用。源码/类型/运行链路须 tsc、targeted lint 与定向测试。
• 增加 assembled boundary test 或真实链路冒烟；两者都跑时分别证明不同风险。公开闭集 variant 同时读取合同变体传播验证。
• 第三方框架/Factor/协议须用真实标准接口和上游执行形态命中触达合同；兼容接口、mock 或相邻能力不能替代，偏离另测。
• 只有影响面确实扩大时才增加 package/full regression。
• HTTP/API/transport 变更应在组装后的真实边界断言精确 contract，不只检查状态码或方法被调用。

L4：发布与不可逆变更

按目标项目的发布、迁移和恢复合同验证真实目标环境、产物身份、回退入口及已授权范围；项目没有可靠执行入口时不能宣称发布验证通过。