中级Agent Skill

Product Skills:产品工作路由与持续发现工具

从一个入口组织调研、需求验证、策略和分析等产品管理 Skill。这项 Skill 会根据任务选择对应专项流程,并用 Python 工具检查持续发现节奏与机会解决方案树,帮助团队把宽泛的产品问题转成下一项具体工作,适合为店铺、商家软件或内部工具推进产品改进。

浏览量
0
复制次数
0
收藏
0
编辑评分
82/100
01

这个 Skill 是做什么的

Product Skills 的作用是协调产品工作,而不是用一种方法处理所有问题。工具集合包含随包提供和单独打包的流程,并配有任务路由、持续发现节奏评分、机会解决方案树结构检查工具。

适合需要选择下一步产品工作,或检查团队是否持续开展需求发现的场景。安装时应同时准备实际要使用的专项 Skill;入口列出了某条路径,并不代表缺失的流程已经可运行。涉及构建与扩展的工作还会引用单独的 agent harness。

02

它有什么特色

01

方法与优势

路由会区分需要研究、优先级判断或其他专项方法的产品问题。提供目标和已有证据后,助手可以按实际工作选择路径,避免所有请求都被笼统归为“产品策略”,却没有明确接下来要完成什么。

02

适用任务

节奏评分和树结构检查让部分需求发现工作可以被核对。工具能够检查所提供记录或结构中的缺口,团队再进一步判断客户证据是否真的支持这些机会与方案,避免把结构完整误认为方向已经正确。

03

安装前的特殊要求

需要准备的输入

产品目标、研究证据、JSON 发现日志或树,以及已安装的目标 Skill。

Agent 与运行环境

使用支持 Skill 且能访问文件的 Agent。随包 Python 辅助工具需要 Python 3;提供数据前先查看样例结构。

需确认的适用边界

需安装产品集合和所需独立插件,路由器无法执行缺失方向。构建级循环还引用独立 agent-harness。

04

安装与开始使用

将指令复制给 Codex 或 Claude Code,让助手从原始仓库下载固定提交,安装完整文件并检查所需依赖。

  1. 打开能访问本机文件和终端的 Codex 或 Claude Code。
  2. 复制下方指令发给正在使用的应用,由助手选择该应用的安装目录。
  3. 查看返回的安装路径和文件检查结果;需要时新建会话,再要求助手使用已安装的 Skill。
请在我当前使用的应用中安装 product-skills,直接执行文件安装,不要只解释步骤。 原始仓库:https://github.com/alirezarezvani/claude-skills.git 固定提交:6d2f02ea077eead1bee5411a31bcc6db5a11a70c Skill 路径:product-team/skills/product-skills 1. 将这个版本下载到新目录。执行随包脚本前,先阅读 SKILL.md 和安装参考文件,不替换成其他作者的包。 2. Codex 安装到 ~/.agents/skills/product-skills,Claude Code 安装到 ~/.claude/skills/product-skills,只安装到我正在使用的应用。此路由器依赖 product-team/skills 中的同级 Skill,请安装该目录下所有包含 SKILL.md 的直接子目录,并保留仓库副本供相对路径引用使用。独立发布的插件不会因此自动安装。先检查所有目标目录;已有安装时,说明差异后再决定是否替换。 3. 比较来源和安装目录的文件清单、文件哈希,检查文档要求的运行时、依赖及外部连接。只配置此 Skill 所需的本地依赖,适用时使用隔离环境;账号登录由我在本地完成,不把凭据贴进聊天。 4. 返回来源提交、实际安装路径、文件检查结果及尚未完成的运行环境配置,说明如何调用 product-skills。文件复制与应用发现分别检查,需要时新建会话。不要执行生产任务,也不要把安装完成说成已确认业务效果。
05

原始 Skill.md

以下为已核对版本未经改写的 SKILL.md。安装完整包才能保留引用的脚本、素材和指引。下方启动提示词为 EcomAgentTools 编写的示例。

---
name: "product-skills"
description: "Use when coordinating product work across the 12 bundled product sub-skills (RICE, OKRs, UX research, design tokens, competitive teardown, analytics, experiments, discovery, roadmaps, spec-to-repo, landing pages, SaaS scaffolding) or the 4 standalone product-team plugins (user stories, Apple HIG, code-to-PRD, research summarizer). Triggers on 'help me prioritize', 'plan a product experiment', 'we ship features nobody uses', 'run the discovery loop', 'is our OST sound'. Forks context to route to one sub-skill via a deterministic signal router and returns a digest; can also drive a continuous-discovery loop (Torres cadence tracker + OST linter as machine gates) or a full goal→plan→execute→verify→close run through the repo-wide agent-harness. Distinct from project-management (how to deliver vs what to build), marketing/landing (from-scratch pages), and engineering/agent-harness (the generic loop engine this orchestrator plugs into)."
context: fork
license: MIT
metadata:
  version: 2.11.1
  author: Alireza Rezvani
  tags: [product, product-management, orchestrator, discovery, ux, analytics, agent-harness]
  compatible_tools: [claude-code, codex-cli, cursor, antigravity, opencode, gemini-cli]
---

# Product Team — Domain Orchestrator & Discovery Loop

This orchestrator does two jobs. **Routing:** fork context, classify a product inquiry
with `scripts/product_goal_router.py` across all 16 product-team lanes (12 bundled + 4
standalone plugins), run exactly one, return a digest. **Looping:** run product work as
bounded agentic loops with machine-checkable gates — the continuous-discovery loop
(weekly cadence scored by `discovery_cadence_tracker.py`, tree structure enforced by
`ost_linter.py`) and goal-scale runs through the repo-wide agent-harness.

## When to invoke

| Symptom | Sub-skill |
|---|---|
| "Prioritize features / RICE / PRD" | `product-manager-toolkit` |
| "OKRs, strategy cascade" | `product-strategist` |
| "Personas, usability, research synthesis" | `ux-researcher-designer` |
| "Design tokens, WCAG contrast" | `ui-design-system` |
| "Competitor matrix, teardown" | `competitive-teardown` |
| "Retention, cohorts, funnels, KPIs" | `product-analytics` |
| "A/B test, sample size, hypothesis" | `experiment-designer` |
| "Discovery, assumptions, opportunity trees" | `product-discovery` |
| "Roadmap comms, release notes, changelog" | `roadmap-communicator` |
| "Spec → runnable repo" | `spec-to-repo` |
| "Landing page (Next.js/Tailwind)" | `landing-page-generator` |
| "SaaS boilerplate" | `saas-scaffolder` |
| "User stories, sprint capacity" | `agile-product-owner` (standalone) |
| "Apple HIG audit" | `apple-hig-expert` (standalone) |
| "PRD from an existing codebase" | `code-to-prd` (standalone) |
| "Summarize papers/articles" | `research-summarizer` (standalone) |

## Routing logic (deterministic)

```bash
python3 scripts/product_goal_router.py --text "<the goal>" --output json
```

Exit 0 → `route_to` names the skill (with `skill_path`, including the standalone
plugins): load its SKILL.md and follow its workflow. Exit 2 → ask ONE clarifying question
naming the listed candidates, with a recommended answer. Exit 3 → no signal: ask the user
to restate the goal with the deliverable named. Never guess silently; never silently
chain — digest first, confirm, then chain.

## The discovery loop (the domain's recurring agentic loop)

Modern discovery is a weekly habit, not a project phase (Torres). Run it as a bounded
loop with two machine gates:

1. **Observe** — maintain `discovery_log.json` (interviews, assumption tests; shape in
   `assets/sample_discovery_log.json`) and score the cadence:
   ```bash
   python3 scripts/discovery_cadence_tracker.py --input discovery_log.json
   ```
   Refuses on < 2 interviews (exit 5) — there is no cadence to measure yet. Output:
   health 0–100, verdict HEALTHY/AT-RISK/DORMANT, named gaps, and `next_loop_action`.
2. **Choose** — the tracker's `next_loop_action` IS the choice: book the touchpoint,
   re-anchor the guide on the outcome, or test the top untested assumption (route to
   `product-discovery`'s assumption_mapper for prioritization).
3. **Act** — run the interview / assumption test with the routed sub-skill's tools.
4. **Verify** — keep the tree structurally sound before it may drive a roadmap:
   ```bash
   python3 scripts/ost_linter.py --input ost.json    # exit 2 = NEEDS-REWORK, fix before citing the tree
   ```
   Rules: one measurable outcome root (O1), opportunities are needs not features (O2),
   targeted opportunities compare ≥ 2 solutions (O3), every solution has an assumption
   test (O4), no orphan solutions (O5 — the feature-factory tell).
5. **Record / Repeat-or-stop** — update the log, keep the weekly streak alive. Stop
   states: HEALTHY + validated assumption → graduate to `experiment-designer` (build the
   A/B gate) or `product-manager-toolkit` (PRD); DORMANT for 4+ weeks → escalate to the
   product lead by name — do not quietly let discovery die.

For build-scale goals ("turn this validated spec into a repo and verify it"), compile
through the repo-wide harness instead:

```bash
python3 engineering/agent-harness/skills/agent-harness/scripts/goal_compiler.py \
  --goal "<goal>" --manifest engineering/agent-harness/skills/agent-harness/assets/harnesses/product-team.json \
  --out .agent-harness/plan.json
```

The domain's three strongest close-out gates plug in as task verifications:
`../spec-to-repo/scripts/validate_project.py` (exit 0), `code-to-prd`'s golden
`expected_outputs/`, and `research-summarizer`'s citation-count check.

## Hard rules

1. **Evidence before conviction**: no roadmap item cites the OST unless `ost_linter.py`
   exits 0; no insight is asserted from a single participant (anecdote, not insight).
2. **Outcome-first**: every loop hangs from one measurable outcome — the linter's O1 rule
   is the intake gate.
3. **Experiments are gated by math**: sample size from
   `../experiment-designer/scripts/sample_size_calculator.py`, never gut feel; report the
   MDE with the verdict.
4. **Prioritization shows its framework**: RICE for steady-state, WSJF/cost-of-delay when
   time sensitivity dominates, opportunity scoring for underserved needs — name which and
   why (see [references/product_operating_model.md](references/product_operating_model.md)).
5. **AI features ship with evals**: a golden set + rubric is the PRD's quality contract
   for probabilistic features
   ([references/ai_product_evals.md](references/ai_product_evals.md)).
6. **Never modify a gate you are judged by**; exhausted budgets escalate to a named human,
   never report as success.

## Forcing-question library (grill-with-docs pattern)

One per turn, recommended answer, canon citation. Never run a sub-skill or start a loop
until the lane-defining decision is locked:

- **DISCOVERY lane**: "What is the single outcome this discovery serves, stated with a
  number? Recommended: write it as the OST root first — opportunities without an outcome
  are a feature factory. Canon: Torres, *Continuous Discovery Habits*; opportunity
  solution trees (producttalk.org)."
- **PRIORITIZE lane**: "Does time sensitivity change this ranking — would delaying any
  item a quarter erode its value? Recommended: if yes, run WSJF/cost-of-delay alongside
  RICE and compare ranks; flag items whose rank flips on a one-step estimate change.
  Canon: Reinertsen, *Principles of Product Development Flow*; SAFe WSJF false-precision
  critique."
- **EXPERIMENT lane**: "What baseline rate and MDE justify this test's runtime?
  Recommended: compute n first; if you can't reach it in 4 weeks, test a bigger lever.
  Canon: statistical power analysis (experiment-designer)."
- **ANALYTICS lane**: "Is your North Star a leading indicator of value exchange, or
  revenue/vanity? Recommended: leading value metric with an input tree. Canon: Amplitude,
  *The North Star Playbook*."
- **STRATEGY lane**: "Are these OKRs outcomes or shipping lists? Recommended: outcomes —
  output OKRs are the #1 operating-model failure. Canon: Cagan, *Transformed* (SVPG,
  2024)."
- **BUILD lanes (spec-to-repo / saas-scaffolder)**: "Which validated assumption says this
  should be built at all? Recommended: link the OST test that survived; building is the
  most expensive way to test an idea. Canon: Torres; Bland, *Testing Business Ideas*."

## Assumptions

1. The user owns (or advises the owner of) the product decision.
2. Discovery data lives in the workspace as JSON logs — the loop is file-backed and
   resumable; every tool ships `--sample` so the shape is visible first.
3. The four standalone plugins are installed alongside the bundle (the router still
   routes to them by path if not).

## Non-goals

- Not the delivery loop — sprint/flow/Jira work routes to `project-management`.
- Not the generic loop engine — that is `engineering/agent-harness`; this orchestrator is
  the product-domain adapter (router + discovery gates).
- Not campaign marketing — `marketing/landing` builds from-scratch marketing pages;
  `landing-page-generator` here scaffolds product Next.js/TSX pages.

## Output artifacts

| Mode | Artifact |
|---|---|
| Route | Sub-skill's own artifact + ≤ 200-word digest with one canon-cited challenge |
| Discovery loop | `discovery_log.json` + cadence report + linted `ost.json` |
| Harness run | `.agent-harness/plan.json` + `state.json` + close handoff |

## Anti-patterns (do not)

- ❌ Run all 16 lanes "to be thorough" — route to one, digest, chain on confirmation
- ❌ Cite an OST that fails the linter, or promote a single-participant anecdote to insight
- ❌ Ship an AI feature whose PRD has no eval (golden set + rubric)
- ❌ Let the discovery streak die silently — DORMANT escalates by name
- ❌ Treat RICE as the only prioritization lens when deadlines dominate

## References

- [references/continuous_discovery_canon.md](references/continuous_discovery_canon.md) —
  Torres, OST, assumption testing, JTBD switch interviews, story mapping
- [references/product_operating_model.md](references/product_operating_model.md) — Cagan
  *Transformed*, North Star framework, PLG benchmarks, WSJF/ODI vs RICE
- [references/ai_product_evals.md](references/ai_product_evals.md) — evals-as-PRD, model
  cards, evaluator-optimizer loops
- Loop engine: `engineering/agent-harness` · Loop vocabulary: `loop-library`
06

开始使用

以下是主要功能的用例提示词,可以直接复制使用。

01

将产品请求路由到一个受支持方向

将产品请求路由到一个受支持方向 适用于:将产品请求路由到一个受支持方向。请准备:产品目标、研究证据、JSON 发现日志或树,以及已安装的目标 Skill。

查看 Prompt 和变量收起 Prompt 和变量
请使用已安装的 product-skills Skill。任务:将产品请求路由到一个受支持方向。输入:[INPUT]。限制:[CONSTRAINTS]。先检查缺失信息,再输出可审查的结果、依据、假设和下一步。需安装产品集合和所需独立插件,路由器无法执行缺失方向。构建级循环还引用独立 agent-harness。

需要替换的变量

[INPUT]
产品目标、研究证据、JSON 发现日志或树,以及已安装的目标 Skill。
[CONSTRAINTS]
任务范围、允许的操作、输出格式和审核要求。
02

检查访谈与假设测试节奏

检查访谈与假设测试节奏 适用于:检查访谈与假设测试节奏。请准备:产品目标、研究证据、JSON 发现日志或树,以及已安装的目标 Skill。

查看 Prompt 和变量收起 Prompt 和变量
请使用已安装的 product-skills Skill。任务:检查访谈与假设测试节奏。输入:[INPUT]。限制:[CONSTRAINTS]。先检查缺失信息,再输出可审查的结果、依据、假设和下一步。需安装产品集合和所需独立插件,路由器无法执行缺失方向。构建级循环还引用独立 agent-harness。

需要替换的变量

[INPUT]
产品目标、研究证据、JSON 发现日志或树,以及已安装的目标 Skill。
[CONSTRAINTS]
任务范围、允许的操作、输出格式和审核要求。
03

在机会树用于路线图决策前进行校验

在机会树用于路线图决策前进行校验 适用于:在机会树用于路线图决策前进行校验。请准备:产品目标、研究证据、JSON 发现日志或树,以及已安装的目标 Skill。

查看 Prompt 和变量收起 Prompt 和变量
请使用已安装的 product-skills Skill。任务:在机会树用于路线图决策前进行校验。输入:[INPUT]。限制:[CONSTRAINTS]。先检查缺失信息,再输出可审查的结果、依据、假设和下一步。需安装产品集合和所需独立插件,路由器无法执行缺失方向。构建级循环还引用独立 agent-harness。

需要替换的变量

[INPUT]
产品目标、研究证据、JSON 发现日志或树,以及已安装的目标 Skill。
[CONSTRAINTS]
任务范围、允许的操作、输出格式和审核要求。
07

实际使用案例:从业务目标进入产品发现并检验假设

模拟目标是将美国会话到订单从 2.5% 提至 3.0%,同时退款/销售额不超过 5%。输入四位购物者的行为记录、机会树、假设表和发现日志。

使用步骤与 Prompt

  1. 准备下方案例输入资料,保留商品、政策和经营记录中的金额、单位及时间口径。
  2. 对照目标、机会树、假设和反面证据,选出下个发现周期最需要验证的问题,并写完整的实验门槛。
  3. 提交下方完整 Prompt,查看右侧主要产物;需要交接给同事时,下载包含全部交付文件的压缩包。

案例输入资料:business-inputs.zip

Use the product-skills Skill.

Help our team plan the next discovery cycle for the returns experience. Use the supplied goal, opportunity tree, assumptions and research evidence to identify the riskiest assumption, set a complete experiment threshold and examine contrary evidence. Deliver the next-cycle brief and a justified continue, pivot or stop decision.

The attached business materials are:
- inputs/assumptions.csv
- inputs/discovery_log.json
- inputs/evidence.json
- inputs/goal.txt
- inputs/merchant.json
- inputs/ost.json

Deliver a complete result.md report that the operations team can read, plus any finished files needed for this task. Keep supporting calculations and evidence with the deliverables. Write the report in English; use the requested target language for customer-facing copy. The business datasets are fictional examples unless the brief explicitly names a live public website.

运行结果

下方直接展示本次 Prompt 产生的主要文件,保留实际输出语言。

HarborMug next discovery cycle

Decision: pivot the discovery focus; continue research and defer a returns build. Investigate whether care and return-policy uncertainty affects purchase decisions before committing to a returns solution. The supplied evidence supports care, arrival and total-cost questions, but contains no return-journey interviews or evidence of return friction. A returns redesign would therefore outrun the evidence.

All supplied business data are synthetic examples. No new customer research or operational changes have been performed.

Outcome and decision boundary

Retain the locked outcome: raise US session-to-order conversion from 2.5% to 3.0% by December 15, 2026, with refunds / gross revenue ≤5%. That is a 0.5 percentage-point, or 20% relative, improvement. Both supplied weeks have 2.5% conversion; the higher order count reflects higher traffic, not better conversion. At 4,800 sessions, 3.0% would mean 144 orders, 24 above the supplied current week, assuming the same traffic denominator. These are targets, not forecasts.

Refunds / gross is 5% in both weeks, already at the ceiling. The data do not identify geography, so confirm the session and order figures represent the US population before treating them as the goal baseline. The weekly refund ratio is an operating guardrail, not a cohort return rate; refund timing can lag sales.

The supplied return example is unopened and requested 14 calendar days after delivery, within the stated 30-day unused-return window. This supports eligibility review only: merchant approval is still required. It does not establish customer confusion, refund approval, processing time or a system defect.

Evidence and contrary explanations

SourceWhat it supportsContrary evidence or limitConsequence
P1–P4, four US mug shoppersAll looked for dishwasher compatibility, compared total price and struggled to estimate arrival; calendar checking is an observed workaroundSummaries repeat identical wording; severity, purchase consequences and verbatim accounts are absentTreat as directional repeated signals; obtain distinct behavioral examples
T2, moderated comprehension, n=4Two initially assumed dishwasher safetyDoes not establish whether correction changes product fit, abandonment or returnsTest desirability separately from comprehension
T1, concept comparison, n=4Three accepted $29 delivered when shown earlyOne did not; no randomized control or real purchase outcomeWeakens the claim that free shipping is necessary; does not prove price disclosure increases conversion
Discovery logFour weekly, outcome-linked interviews; two assumptions marked invalidatedA recorded label is not stronger than its underlying evidence“Care is understood” is contradicted; “care clarity matters to choice” remains unresolved
Return example and policyA concrete unused-return scenario existsNo return-experience research, ticket volume, effort or abandonment evidenceInvestigate the opportunity; do not assert it is validated

A plausible contrary hypothesis is that shoppers understand care once told but reject hand-wash-only mugs because the product does not fit their routine. Clearer copy could then reduce purchases while preventing unsuitable orders. Arrival or delivered price might instead dominate choice. Return reassurance might also create an incorrect expectation of automatic refunds. Capture these outcomes explicitly rather than counting favorable reactions alone.

Riskiest assumption

Use risk × (1 − certainty) to prioritize learning, following the discovery assumption-mapping framework. This ranks uncertainty about a consequential belief; it is not an estimate of revenue impact.

RankSupplied assumptionRiskCertaintyPriority
1Care clarity matters0.900.200.72
2Arrival card is understood0.800.400.48
3Margin supports disclosure0.700.700.21
4Shipping logic is feasible0.500.800.10

Operational hypothesis: uncertainty about care prevents target shoppers from judging product fit, and accurate disclosure lets them make an informed choice without assuming a refund is guaranteed. T2 identifies misunderstanding, not demand for a solution. The proposed returns hypothesis—“uncertainty about unused-return eligibility or approval obstructs purchase or return tasks”—is unscored because the supplied evidence does not justify a numerical certainty estimate.

The top ranking survives an illustrative adverse change of 0.1 in care certainty (score 0.63) combined with a 0.1 decrease in arrival certainty (score 0.56). Larger revisions could change the ranking; reassess after the cycle.

Tree and cadence review

The supplied tree passes the structural gate: one measurable outcome, three needs, two solutions per targeted opportunity, tests on every solution, and no orphan solutions. It compares arrival disclosure with a destination panel, a care card with an image-side comparison, and early total with a calculator. Structural soundness does not validate any branch. Its generic comprehension criteria also do not test whether care clarity matters to decisions.

Keep the three existing branches and focus this cycle on care. Keep returns as a research question outside the validated tree until evidence supports a customer need. Do not label a proposed returns branch as observed fact. The preserved ost.json has not been expanded with invented research.

Cadence scores 100/100, HEALTHY: four distinct participants across four observed weeks, a four-week streak, full outcome linkage and two resolved tests. The tracker’s next action is to book next week’s touchpoint. Healthy cadence permits continued learning; it is not solution validation. discovery_log.json preserves completed activity only; planned sessions must not be recorded as completed interviews.

Next-cycle brief: ten working days

Accountability: Mia coordinates support evidence and research scheduling; Alex owns the decision and any policy approval. Assign a product/research facilitator and prototype builder on day 1. These are proposed responsibilities, not completed assignments.

  • Days 1–2: confirm US metric denominators, approve the scoring rubric and draft copy, review available return-support evidence without treating absent records as zero incidents. Book at least one touchpoint in each cycle week. Freeze the hypotheses and thresholds below before exposure.
  • Days 3–4: prepare both existing care concepts and the separate return task. Recruit five new US mug shoppers who have recently considered an insulated mug, including at least two who normally rely on dishwashers. Recruit three separate recent unused-return requesters for return-journey interviews. Do not substitute prior P1–P4 participants for new evidence.
  • Days 5–7: run individual moderated sessions. Start with past behavior and an unaided product assessment, then show both care concepts in alternating order. Do not mention the hypothesized pain before the unaided task. Keep price and arrival information identical between concepts. Run return interviews separately to avoid contaminating care findings.
  • Days 8–9: review evidence daily, code failures and negative cases, compare concepts on first exposure, and separate prompted answers from unaided success. Recheck policy accuracy and the refund guardrail definition.
  • Day 10: Alex reviews the decision table, counterevidence and missing evidence; record continue, pivot or stop, then update the log and tree with actual findings. Book the following weekly touchpoint.

This cycle uses small qualitative tests to reject weak concepts and improve the problem framing. It is not powered to estimate a conversion effect. Its behavioral tasks are simulated purchase choices, not actual orders.

Experiment A: does care clarity resolve a consequential uncertainty?

Unit and sample: one new eligible shopper; five completed sessions. Record both concepts per participant but analyze each concept separately. Alternate order 3/2 and report that imbalance. Within-person comparison is directional and affected by learning; first-exposure results must be shown separately.

Procedure: ask the shopper to assess whether the mug fits their actual routine and make a simulated buy/decline decision with a reason. Ask for a recent comparable purchase example. Show a care concept and ask them to explain how they would clean and use the mug, then repeat their decision and reason. Finally ask what they expect if they request a return. Do not reward purchase intent or explain the correct answers until scoring is complete.

Predeclared pass conditions, all required:

  1. At least 3/5 independently identify care uncertainty before disclosure as a material obstacle to deciding fit, supported by a specific behavior or recent example; moderator-prompted agreement does not count.
  2. For a concept to pass comprehension, at least 4/5 correctly state both “hand-wash only” and “not microwave safe” without help after viewing it.
  3. At least 3/5 show a specific, accurately reasoned resolution of the initial uncertainty in their simulated choice after disclosure. An informed decline counts as resolution, but must be reported separately from a purchase choice.
  4. 0/5 infer that opening/using the mug guarantees a refund, and the policy review finds no inaccurate promise.

Record denominators, first-exposure counts, corrections, informed declines and contrary examples. Do not add participants after seeing unfavorable results to reach a pass. Missing or ineligible sessions are replaced before analysis; fewer than five eligible completions means inconclusive. These are explicit qualitative gates, not statistical confidence or evidence of conversion lift.

Decision: if all conditions pass, continue with the qualifying concept to further validation; select by first-exposure errors and misconception severity rather than a one-person preference margin. If care matters but comprehension or safety fails, pivot the presentation and retest with new participants. If fewer than 3/5 show a consequential care obstacle, stop prioritizing care as the main conversion lever and investigate arrival/total-cost alternatives. Any false refund promise blocks advancement until corrected.

Experiment B: is there a returns opportunity worth adding?

Interview three separate recent unused-return requesters. Reconstruct the last journey: trigger, eligibility check, request, approval, next step and effort. Ask what actually happened and what they expected, then test this scenario: an unopened mug, delivered 14 days ago, with a return requested today. Ask whether it can be reviewed under the policy and whether a refund is guaranteed.

Problem gate: at least 2/3 independently recount the same eligibility/approval uncertainty plus a concrete consequence, such as repeat contact or delayed action. If met, propose a need-based branch (“Customers cannot determine unused-return eligibility and the approval step”), linked to the new evidence, with two candidates: an eligibility summary and a guided request checklist. Each must carry its own test before the tree is linted again.

Copy safety gate: 3/3 correctly identify the 30-day unused window and merchant approval, with 0/3 believing the draft guarantees a refund. A comprehension failure triggers copy revision even if the problem gate passes. If the problem gate is missed, stop the returns-solution commitment for now; the small sample does not establish that no broader returns problem exists. If recruitment cannot yield three eligible interviews, mark the returns decision inconclusive rather than replacing it with shopper opinions.

Interview prompts and scoring record

Use these prompts verbatim where practical: “Tell me about the last insulated mug you considered. What did you check before deciding?” “What would make this mug fit or not fit your routine?” “Show me where you would look for that information.” “How would you clean and use it?” “What would you expect after requesting a return?” For returners: “Walk me through your last unused-return request. Where did you hesitate, and what did you do next?”

Record participant code, segment, concept order, unaided obstacle, concrete example, comprehension before/after, simulated choice and reason, return expectation, assistance, contrary evidence and pass/fail against each criterion. Use the supplied blank worksheet; do not populate it with fictional new results.

Draft customer-facing prototype copy

No separate target language was supplied; these drafts use English. They are research materials, not published copy.

Care card

Will it fit your routine? This 500 ml stainless steel insulated mug is hand-wash only. It is not microwave safe. If you need a dishwasher-safe mug, consider whether hand-washing works for you before ordering.

Image-side care comparison

Cleaning: hand-wash only. Microwave use: not safe. Check these care requirements before you choose.

Unused-return summary for the separate return task

Need to return an unused mug? The unused-return window is 30 days. Refunds require merchant approval. Request a review of your return eligibility; a request does not guarantee a refund.

Mia and Alex must settle the policy’s window start point and request instructions before publishing a return flow. The supplied policy does not specify return shipping costs, refund timing or the handling of used goods; the drafts make no promises on those points.

Decision after this brief

Pivot now, with bounded continuation of discovery. Preserve the conversion outcome, test the top-ranked care assumption, and establish whether a returns opportunity exists. Stop treating free shipping as a prerequisite and stop short of approving a returns build. Neither the four-person evidence nor the cadence score justifies shipping or claiming sales impact.

A passing qualitative cycle permits further validation, not rollout. A later causal test must define the baseline population, minimum detectable effect, allocation, power, sample size, runtime and refund-maturation window before launch. No causal experiment is authorized or sized here. The bundled statistical sample-size calculator is unavailable, so no powered-test claim is made.

The method follows Torres, Continuous Discovery Habits (weekly outcome-linked touchpoints and competing solutions), and Bland & Osterwalder, Testing Business Ideas (risk and evidence-based test sequencing). The challenge for the decision review is: what observed behavior shows that care or returns uncertainty changes the decision, rather than merely attracting attention?

Supporting deliverables

evidence/ preserves all six supplied materials. calculations.json contains arithmetic and assumption scores; assumption_ranking.txt is the mapper output. cadence_report.json and ost_lint.json contain the machine checks. ost.json and discovery_log.json preserve the current tree and completed discovery record. research_worksheet.csv is the blank next-cycle recording template. No new research results have been added.

案例中的商家经营资料为模拟数据;涉及网站检查时,报告中的页面观察来自所列公开网址。

08

风险与使用注意事项

已知限制

需安装产品集合和所需独立插件,路由器无法执行缺失方向。构建级循环还引用独立 agent-harness。

证据与复核

核对源码及随包文件:GitHub 6d2f02ea077e。本次为静态审查,不代表已完成安装运行或业务效果测试。

采用结果前

使用获授权输入,不把密钥贴入提示词。采用前检查面向客户的声明、计算、代码改动及任何拟议的外部操作。

常见问题

它能做什么,有什么优势?

路由产品工作,并检查持续发现节奏和机会解决方案树。2.11.1 版本提供路由、节奏评分和树校验三个 Python 工具,覆盖 12 个内置方向及四个独立打包方向。

如何安装和开始使用?

按实际 Agent 选择方式,安装完整包,不要只复制页面中的 SKILL.md。 产品目标、研究证据、JSON 发现日志或树,以及已安装的目标 Skill。 开启新 Agent 会话,明确要求使用 product-skills。先用小型样本尝试下方一个场景,并检查输出。

适合哪些使用场景?

将产品请求路由到一个受支持方向;检查访谈与假设测试节奏;在机会树用于路线图决策前进行校验

使用前需要了解哪些限制?

需安装产品集合和所需独立插件,路由器无法执行缺失方向。构建级循环还引用独立 agent-harness。

本页核对了什么?

核对源码及随包文件:GitHub 6d2f02ea077e。本次为静态审查,不代表已完成安装运行或业务效果测试。

暂无评论。

发表评论

请先为每一项打分,再分享你的真实使用体验。

任务有效性
安装与使用难度
稳定性与边界
文档清晰度
首次获得有效结果
作者 / 维护者

Alireza Rezvani

核对源码及随包文件:GitHub 6d2f02ea077e。本次为静态审查,不代表已完成安装运行或业务效果测试。