القائمة
验证证据优先级体系——L1-L5 五级证据、Done 判定门槛矩阵、完成前四问、无法验证处理规范、运行态验证方法指引。触发场景：(1) 标记 InReview 或 Done，(2) 选择证据等级，(3) 判断是否验证充分，(4) 处理无法验证的项，(5) 用户说"验证"、"证据"、"Done"、"验收"
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
归档管理——Task 归档与 Recording 物理归档的双轨机制、触发条件、手动步骤、验证清单。触发场景：(1) 终态任务数超阈值，(2) session 文件数超阈值，(3) 用户说"归档"、"archive"、"清理"
纠偏与误判排查方法论——退化信号检测、四行重写模板、止损序列、六类泛化误判排查表、与 BLOCKED 的边界判定。触发场景：(1) 出现退化信号（反复纠偏/目标漂移/证据缺失等），(2) 需要纠偏恢复，(3) 排查误判，(4) 判断是 correction 还是 BLOCKED，(5) 用户说"纠偏"、"偏了"、"不对"、"重写"、"止损"、"误判"
积木式能力验证方法论——判断「直接做 vs 先验证」、将不确定性分层隔离、沉淀可复用能力资产。触发场景：(1) 讨论技术可行性或方案选型，(2) 评估某个实现的不确定性，(3) 决定直接集成 vs 先做 Demo 验证，(4) 分析能力复用或知识沉淀策略，(5) 用户说"积木"、"Demo"、"能力验证"、"不确定性"
产品文档工具——正向（需求→文档）或逆向（代码→文档）两种模式。触发场景：(1) 为已有产品还原/补全文档，(2) 为新功能/模块编写产品文档，(3) 用户说"写文档"、"还原文档"、"doc"、"产品文档"
阶段边界决策锚点——四段式判断（启动/实施/验收/纠偏），含正例/反例/边界例。覆盖：基线失败处理、不确定性决策、入口门控、大幅度判定、执行偏差分级、并行串行选择、超前实施、Done 人工确认、blocked_by 判定、循环依赖、continuous_mode 续跑、recording 写入时机、decisions.md 写入时机。触发场景：(1) 需要做阶段边界决策，(2) 判断幅度大小，(3) 选择并行还是串行，(4) 判断是否需人工确认，(5) 用户说"判断"、"决策"、"幅度"、"并行"、"确认"
产品需求分析方法论——竞品分析、用户画像、需求优先级排序、迭代层次设计、方案对比、非功能性需求分类。触发场景：(1) 讨论产品规划或功能设计，(2) 进行需求分析或竞品调研，(3) 设计迭代路径或优先级排序，(4) 用户说"PRD"、"需求文档"、"竞品分析"、"产品规划"、"需求优先级"、"迭代规划"、"方案对比"
| name | dvfy |
| description | 验证证据优先级体系——L1-L5 五级证据、Done 判定门槛矩阵、完成前四问、无法验证处理规范、运行态验证方法指引。触发场景：(1) 标记 InReview 或 Done，(2) 选择证据等级，(3) 判断是否验证充分，(4) 处理无法验证的项，(5) 用户说"验证"、"证据"、"Done"、"验收" |
| argument-hint | [任务ID] [证据等级] |
| context | fork |
| agent | Explore |
| model | haiku |
| allowed-tools | ["Bash","Read"] |
| effort | low |
| hooks | {"TaskCompleted":[{"hooks":[{"type":"command","command":"python3 ${CLAUDE_SKILL_DIR}/../hooks/scripts/task_completed.py 2>/dev/null || true"}]}]} |
证据优先级体系：验证的核心规则。未验证 = 未完成。
| 等级 | 名称 | 说明 | 示例 |
|---|---|---|---|
| L1 | 运行态证据 | 真实输出已发生可识别变化 | 发起请求后返回值变了、页面渲染结果变了、文件产物生成了 |
| L2 | 调用链证据 | 底层状态切换已被观测到 | 日志显示命中新代码路径、数据库记录已写入、状态机已转移 |
| L3 | 自动化断言 | 测试/脚本/断言自动判定 | 单元测试全绿、verify.sh exit 0、assert 通过 |
| L4 | 表面观察 | 日志/截图/页面现象（需人工解读） | 截图看起来正确、日志无报错、页面能打开 |
| L5 | 间接推断 | 代码 diff / 口头说明 | "我改了这段代码"、"理论上应该没问题" |
默认优先级：L1-3 主判 → L4-5 辅助说明。只有 L5 时不得宣称完成。
| 证据等级组合 | 判定动作 | 标注要求 |
|---|---|---|
| 全部 L1-3 通过 | Agent 自审后 Done | session 文件逐条标注 PASS + 验证方法 |
| L1-3 部分 + L4 补充 | Agent 自审后 Done | L4 项标注「待人工确认」+ 后续验证方式 |
| 仅 L4 或 L4-5 | 不允许 Done | 标注 InReview + 「待验证」+ 原因 + 后续方式 |
| 仅 L5 | 禁止宣称完成 | 保持 InProgress，补充真实验证 |
| 证据等级 | 验证方式 | 使用场景 |
|---|---|---|
| L1 运行态 | 运行态验证 | 关键链路是否真的经过新代码 |
| L2 调用链 | 运行态验证 | 底层状态是否真正切换 |
| L3 自动化断言 | 自动化验证 | task_verify.sh、单元测试 |
| L4 表面观察 | 手动验证 | UI 交互、实机测试 |
| L5 间接推断 | — | 不作为独立验收依据 |
标记 InReview 前必须回答：
| # | 问题 | 回答格式 |
|---|---|---|
| 1 | 验证的是哪一层？ | 文档 / 代码 / 配置 / 调用链 / 运行态 / 输出 |
| 2 | 是否真的走到了新链路？ | 是/否 + 证据（日志/断点/请求追踪） |
| 3 | 结果是否出现可识别变化？ | 变化描述 + 变化前后对比 |
| 4 | 哪些部分已验证，哪些未验证？ | 已验证清单 + 未验证清单 |
暂时无法验证时，必须使用三段式模板明确写出：
未验证项: [具体条目]
原因: [为什么现在无法验证：环境/凭据/依赖/时间窗口等]
后续验证方式: [具体步骤或条件，不是"以后再测"这种空话]
禁止行为：
代码层验证（lint/build/测试）通过后，还需确认运行时真的走到新链路：
| 方法 | 适用场景 | 操作 |
|---|---|---|
| 关键点加日志/断言 | 有源码访问权限 | 在加载点插入，确认执行路径经过新代码 |
| 发起真实请求 | API / CLI / Web 服务 | 确认输出因改动而变化 |
| 检查产物生成 | 构建任务 / 插件项目 | 验证 hooks 是否触发、产物是否存在且正确 |
| 端到端走查 | UI / 多模块集成 | 从用户操作入口走到最终输出，全程有据 |
对于插件类项目（如 diwu-workflow 本身）：验证 hooks 是否被触发、产物是否被生成、JSON 是否合法。