| name | hf-discovery-review |
| description | 适用于 discovery 草稿已完成需要正式 review verdict、或被指定为 reviewer subagent 执行 discovery 评审的场景。不适用于需继续写 discovery 正文（→ hf-product-discovery）、已明确进入 formal spec（→ hf-specify）、或阶段不清 / 证据冲突（→ hf-workflow-router）。 |
HF 产品发现评审
评审 discovery 草稿，判断问题定义、用户聚焦、wedge 收敛、假设显式化和 bridge-to-spec 准备度是否足够稳定，能够作为 hf-specify 的上游输入。本 skill 是 discovery 冻结门禁，不替代 hf-product-discovery（起草 discovery）或 hf-specify（写正式规格）。
Methodology
本 skill 融合以下已验证方法：
- Structured Walkthrough: 通过固定 rubric 评审问题定义、假设和 bridge 质量，而不是自由发挥式评论。
- Checklist-Based Review: 用结构化检查清单覆盖 discovery 的关键维度，防止 reviewer 只看“想法是否有趣”。
- Separation of Author/Reviewer Roles: discovery author 与 reviewer 必须分离，避免“自己写自己过”。
- Evidence-Based Verdict: 结论必须锚定到 discovery 文档中的具体缺口，不接受泛泛的“还不够清楚”。
When to Use
适用：
hf-product-discovery 已完成 discovery 草稿，需正式 review verdict- 用户明确要求“review 这份 discovery / insight 草稿”
- reviewer subagent 被派发执行 discovery 评审
不适用：
- 需要继续写或修 discovery 正文 →
hf-product-discovery
- 已明确进入 formal spec 起草 →
hf-specify
- 阶段不清或证据冲突 →
hf-workflow-router
前提确认：存在稳定 discovery 草稿，能读取 项目约定和少量上游输入，请求确实是评审。若 route/stage/profile/证据冲突 → 优先回 router。
Hard Gates
- discovery 通过评审前，不得把其结论直接当作正式规格输入
- reviewer 不代替父会话继续写 discovery 正文，不顺手开始 spec
- reviewer 不得为让 discovery “更像完成了”而发明用户、问题或价值判断事实
Workflow
1. 建立证据基线
读取并固定：当前 discovery 草稿、项目约定、必要的 notes / insight 输入、discovery 阶段 progress 记录（若存在；discovery 在 feature 创建之前发生，因此 progress 通常仍以 discovery 草稿同目录为准）。不只依据聊天记忆判断“这个方向已经清楚”。
1.5 Precheck：能否合法进入 review
检查：是否存在稳定可定位的 discovery 草稿、请求是否真的是 review、route/stage/证据是否一致。
- route/stage/证据冲突 → 写最小 blocked precheck record，
reroute_via_router=true
- route 明确但缺稳定 discovery 草稿 → 写最小 blocked record，下一步
hf-product-discovery
- precheck 通过 → 继续正式 rubric
2. 用 rubric 做正式审查
详细规则：references/review-checklist.md
默认审查以下维度：
- 问题与用户聚焦度
- why-now 与 wedge 收敛度
- facts / assumptions / later ideas 的分离程度
- probe / 验证方向是否合理
- bridge-to-spec 准备度
每条 finding 必须带：
severity（critical / important / minor）classification（USER-INPUT / LLM-FIXABLE）rule_id（如 P1、W2、B1）
分类：缺外部事实、用户价值判断、关键业务裁决 → USER-INPUT；缺结构、假设显式化、bridge 语义、later idea 整理 → LLM-FIXABLE。
3. 形成 verdict 与下一步
| 条件 | verdict | 下一步 |
|---|
| 问题清楚、wedge 收敛、假设显式、bridge 足以进入 formal spec | 通过 | hf-specify |
| discovery 有价值但仍需一轮定向回修 | 需修改 | hf-product-discovery |
| discovery 过于模糊、核心问题/用户/bridge 未定 | 阻塞(内容) | hf-product-discovery |
| route/stage/证据冲突 | 阻塞(workflow) | hf-workflow-router |
4. 写 review 记录
按 references/review-record-template.md 写记录并回传父会话。
交互约束：
- 父会话先展示 1-2 句 plain-language 结论，再只提 USER-INPUT 问题
- LLM-FIXABLE 问题不转嫁给用户
通过 时只表示 discovery 已足够进入 hf-specify，不代表 formal spec 已完成
Red Flags
- 把 discovery 评审变成补写 spec
- 因“方向看起来不错”就直接通过，没有 bridge 语义
- 忽略 facts / assumptions / later ideas 混写问题
- findings 没有 USER-INPUT / LLM-FIXABLE 分类
通过 后直接声称“可以实现”而不是进入 hf-specify- interactive 模式下把全量 rubric 原样贴给用户
Reference Guide
| 文件 | 用途 |
|---|
references/review-checklist.md | discovery 正式审查 rubric |
references/review-record-template.md | 记录结构、JSON 返回和下一步映射 |
Common Rationalizations
| 借口 | 反驳 / Hard rule |
|---|
| "discovery 是上游 author 写的，但我顺手帮他改两段。" | Hard Gates (soul.md): 评审者不能编辑被审对象；只能产出 finding，由作者回修。 |
| "JTBD / OST 看着 OK 就 pass。" | Hard Gates: 必须按 Fagan rubric 逐项打分；缺 evidence 时不出 verdict。 |
| "fresh evidence 不存在但我相信他做了。" | Verification: discovery record / hypothesis 必须可回读，缺位即判 fail。 |
Verification
