From harness-flow
Produces structured probe plans to minimally validate blocking or high-risk assumptions in product discovery or spec phases before advancing.
How this skill is triggered — by the user, by Claude, or both
Slash command
/harness-flow:hf-experimentThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
在进入 `hf-specify` 前(或 `hf-specify` 内部 Blocking 假设未关闭时),为一条或少数几条**关键假设**产出一份结构化 **probe plan**:明确假设是什么、如何最小验证、多长时间、什么结果算通过、证据落在哪、结果如何回流。
在进入 hf-specify 前(或 hf-specify 内部 Blocking 假设未关闭时),为一条或少数几条关键假设产出一份结构化 probe plan:明确假设是什么、如何最小验证、多长时间、什么结果算通过、证据落在哪、结果如何回流。
本 skill 是 Phase 0 引入的轻量节点,不是完整的实验平台,也不替代 A/B testing 基础设施。它的核心价值在于:把 discovery / spec 阶段模糊的"我们假设"变成可证伪的"一次小验证",避免把未经检验的假设硬推给下游设计或实现。
本 skill 融合以下已验证方法:
| 方法 | 核心原则 | 来源 | 落地步骤 |
|---|---|---|---|
| Hypothesis-Driven Development | 把产品决策拆成可证伪假设,而不是先做再看 | Lean Startup, Ries 2011;Intuit Hypothesis-Driven Development | 步骤 2 / 3 |
| Build-Measure-Learn | 最小构建 → 最小测量 → 显式学习回流 | The Lean Startup | 步骤 3–5 |
| Four Types of Assumptions | Desirability / Viability / Feasibility / Usability 分类假设 | Teresa Torres Continuous Discovery Habits | 步骤 2 |
| Smallest Testable Probe | 用最小代价打穿最高风险假设 | Spotify Think It Build It Ship It Tweak It;Design Sprint | 步骤 3 |
| Pre-registered Success Threshold | 事先声明通过阈值,事后不允许移动门柱 | 研究方法学通行做法 | 步骤 3;步骤 5 回流 |
适用:
hf-product-discovery 或 hf-discovery-review 识别出低 confidence / 高风险假设,正式推进前值得先验证hf-specify 中 Key Hypotheses 存在 Blocking? = 是 的假设,规格不能在未验证前通过评审不适用:
hf-specifyhf-product-discoveryhf-test-driven-devhf-workflow-routerDirect invoke 信号:"先不要写 spec,先做一次最小验证"、"这条假设我们得先 probe"、"review 要求先验证 HYP-003"。
hf-product-discovery 或 hf-specifyhf-workflow-router只读完成 probe plan 所需的最少材料:
docs/insights/*-discovery.md)或已在起草的 features/<active>/spec.md归纳:
选择本轮 probe 的假设集合,原则:
在 probe plan 中显式列出"本轮 probe 假设"与"本轮 probe 不覆盖的假设"。
对每条被选中的假设,产出下表最小字段:
| 字段 | 含义 | 要求 |
|---|---|---|
| Assumption ID | 对应 HYP-xxx 或 discovery OST 中的 assumption | 必须可回指上游 |
| Restatement | 重述假设为可证伪的一句话 | 一句话,陈述式 |
| Type | Desirability / Viability / Feasibility / Usability | 强制分类 |
| Method | 采用的验证方式 | 见下方推荐列表 |
| Participants / Sample | 样本 / 参与者 / 数据范围 | 数量 + 来源 |
| Setup | 需要搭建 / 准备什么 | 不允许悄悄写产品代码;若非用不可,显式标"一次性原型" |
| Success Threshold | 事先声明的通过阈值 | 可证伪,不允许"看起来不错" |
| Failure Threshold | 事先声明的失败阈值 | 让结果能落到 Pass / Fail / Inconclusive 三档之一 |
| Timebox | 最大允许投入的时间窗口 | 明确的小时 / 天数;超时 = Inconclusive |
| Evidence Path | 证据归档位置 | 默认 docs/experiments/<date>-<slug>/,见下 |
| Rollback / Cleanup | 一次性原型是否需要清理 | 若有则必须写 |
推荐验证方式(按代价由低到高):
按 references/probe-plan-template.md 写入:
docs/experiments/<YYYY-MM-DD>-<slug>/probe-plan.mdfeatures/<active>/experiments/<slug>/probe-plan.mdplan 文档必须包含:
hf-product-discovery / hf-specify / hf-workflow-router 的哪一个probe 执行完毕后(或触发 Timebox),产出 probe result 文档:
docs/experiments/<YYYY-MM-DD>-<slug>/probe-result.mdPass / Fail / Inconclusive按结果显式回流:
| 结果 | 回流目标 |
|---|---|
| Pass(且对应假设不再 Blocking) | hf-specify(若 spec 已在起草)或 hf-product-discovery(discovery 阶段) |
| Fail(假设被证伪) | 回 hf-product-discovery:修订 OST、重写候选方向;或回 hf-specify 修订对应 FR/NFR;必要时回 hf-workflow-router 重新路由 |
| Inconclusive(超时 / 样本不够 / 方法缺陷) | 决定:(a) 追加一次小 probe;(b) 显式接受风险并写入 Key Hypotheses 的 "accepted-risk" 标记;(c) 回 hf-workflow-router |
回流时必须:
HYP-xxx 的 Confidence 更新写回 spec(若已存在)或 discovery 草稿完成时产出:
docs/experiments/<date>-<slug>/probe-plan.md(必有)docs/experiments/<date>-<slug>/probe-result.md(probe 执行后必有)artifacts/ 下Next Action Or Recommended Skill 暂指向 hf-experiment,probe 回流后改回 hf-discovery-review 或 hf-specifyprogress.md 的 Next Action Or Recommended Skill 暂指向 hf-experiment,probe 回流后改回 hf-specify 或 hf-spec-review若 probe 结果尚未生成,不伪造回流;明确写出当前停在哪一步。
按需加载详细参考内容。任一 reference 未命中其"加载时机"时,不需要提前读取。
| 主题 | Reference | 加载时机 | 最小 profile |
|---|---|---|---|
| probe plan / result 模板 | references/probe-plan-template.md | 起草 plan 或记录 result 时;每次 probe 至少读一次 | 全档必读 |
加载策略:
full profile 下激活(standard / lightweight 不激活 hf-experiment)| 借口 | 反驳 / Hard rule |
|---|---|
| "假设很明显,跳过 probe 直接进 spec。" | Workflow stop rule: 高风险 / 阻塞性假设未验证时 hf-specify 不应启动;hf-experiment 是其前置条件。 |
| "用过去的数据当 probe 结果。" | Verification: probe evidence 必须是当前会话内的 fresh evidence,不能用过期数据。 |
| "probe 只跑一次就足够。" | Hard Gates: probe 设计必须包含 success / failure threshold;不达 threshold 必须重设或 escalate,不允许"差不多"通过。 |
Next Action Or Recommended Skill 在 probe 结束后已切回正确节点npx claudepluginhub hujianbest/harness-flow --plugin harness-flowGuides product managers in selecting the right Proof of Life probe to validate hypotheses by matching methods to learning goals, not tooling comfort.
Designs low-cost experiments—prototypes, A/B tests, spikes, Wizard of Oz—to validate assumptions in existing products. Use for cheap feature idea testing before full implementation.
Designs smallest viable tests to validate or invalidate critical assumptions using Torres framework and Gilad's AFTER model (Assessment to Release Results).