方法与优势
路由会区分需要研究、优先级判断或其他专项方法的产品问题。提供目标和已有证据后,助手可以按实际工作选择路径,避免所有请求都被笼统归为“产品策略”,却没有明确接下来要完成什么。
从一个入口组织调研、需求验证、策略和分析等产品管理 Skill。这项 Skill 会根据任务选择对应专项流程,并用 Python 工具检查持续发现节奏与机会解决方案树,帮助团队把宽泛的产品问题转成下一项具体工作,适合为店铺、商家软件或内部工具推进产品改进。
Product Skills 的作用是协调产品工作,而不是用一种方法处理所有问题。工具集合包含随包提供和单独打包的流程,并配有任务路由、持续发现节奏评分、机会解决方案树结构检查工具。
适合需要选择下一步产品工作,或检查团队是否持续开展需求发现的场景。安装时应同时准备实际要使用的专项 Skill;入口列出了某条路径,并不代表缺失的流程已经可运行。涉及构建与扩展的工作还会引用单独的 agent harness。
路由会区分需要研究、优先级判断或其他专项方法的产品问题。提供目标和已有证据后,助手可以按实际工作选择路径,避免所有请求都被笼统归为“产品策略”,却没有明确接下来要完成什么。
节奏评分和树结构检查让部分需求发现工作可以被核对。工具能够检查所提供记录或结构中的缺口,团队再进一步判断客户证据是否真的支持这些机会与方案,避免把结构完整误认为方向已经正确。
产品目标、研究证据、JSON 发现日志或树,以及已安装的目标 Skill。
使用支持 Skill 且能访问文件的 Agent。随包 Python 辅助工具需要 Python 3;提供数据前先查看样例结构。
需安装产品集合和所需独立插件,路由器无法执行缺失方向。构建级循环还引用独立 agent-harness。
将指令复制给 Codex 或 Claude Code,让助手从原始仓库下载固定提交,安装完整文件并检查所需依赖。
请在我当前使用的应用中安装 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。文件复制与应用发现分别检查,需要时新建会话。不要执行生产任务,也不要把安装完成说成已确认业务效果。以下为已核对版本未经改写的 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`
以下是主要功能的用例提示词,可以直接复制使用。
将产品请求路由到一个受支持方向 适用于:将产品请求路由到一个受支持方向。请准备:产品目标、研究证据、JSON 发现日志或树,以及已安装的目标 Skill。
请使用已安装的 product-skills Skill。任务:将产品请求路由到一个受支持方向。输入:[INPUT]。限制:[CONSTRAINTS]。先检查缺失信息,再输出可审查的结果、依据、假设和下一步。需安装产品集合和所需独立插件,路由器无法执行缺失方向。构建级循环还引用独立 agent-harness。[INPUT][CONSTRAINTS]检查访谈与假设测试节奏 适用于:检查访谈与假设测试节奏。请准备:产品目标、研究证据、JSON 发现日志或树,以及已安装的目标 Skill。
请使用已安装的 product-skills Skill。任务:检查访谈与假设测试节奏。输入:[INPUT]。限制:[CONSTRAINTS]。先检查缺失信息,再输出可审查的结果、依据、假设和下一步。需安装产品集合和所需独立插件,路由器无法执行缺失方向。构建级循环还引用独立 agent-harness。[INPUT][CONSTRAINTS]在机会树用于路线图决策前进行校验 适用于:在机会树用于路线图决策前进行校验。请准备:产品目标、研究证据、JSON 发现日志或树,以及已安装的目标 Skill。
请使用已安装的 product-skills Skill。任务:在机会树用于路线图决策前进行校验。输入:[INPUT]。限制:[CONSTRAINTS]。先检查缺失信息,再输出可审查的结果、依据、假设和下一步。需安装产品集合和所需独立插件,路由器无法执行缺失方向。构建级循环还引用独立 agent-harness。[INPUT][CONSTRAINTS]模拟目标是将美国会话到订单从 2.5% 提至 3.0%,同时退款/销售额不超过 5%。输入四位购物者的行为记录、机会树、假设表和发现日志。
案例输入资料: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 产生的主要文件,保留实际输出语言。
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.
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.
| Source | What it supports | Contrary evidence or limit | Consequence |
|---|---|---|---|
| P1–P4, four US mug shoppers | All looked for dishwasher compatibility, compared total price and struggled to estimate arrival; calendar checking is an observed workaround | Summaries repeat identical wording; severity, purchase consequences and verbatim accounts are absent | Treat as directional repeated signals; obtain distinct behavioral examples |
| T2, moderated comprehension, n=4 | Two initially assumed dishwasher safety | Does not establish whether correction changes product fit, abandonment or returns | Test desirability separately from comprehension |
| T1, concept comparison, n=4 | Three accepted $29 delivered when shown early | One did not; no randomized control or real purchase outcome | Weakens the claim that free shipping is necessary; does not prove price disclosure increases conversion |
| Discovery log | Four weekly, outcome-linked interviews; two assumptions marked invalidated | A recorded label is not stronger than its underlying evidence | “Care is understood” is contradicted; “care clarity matters to choice” remains unresolved |
| Return example and policy | A concrete unused-return scenario exists | No return-experience research, ticket volume, effort or abandonment evidence | Investigate 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.
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.
| Rank | Supplied assumption | Risk | Certainty | Priority |
|---|---|---|---|---|
| 1 | Care clarity matters | 0.90 | 0.20 | 0.72 |
| 2 | Arrival card is understood | 0.80 | 0.40 | 0.48 |
| 3 | Margin supports disclosure | 0.70 | 0.70 | 0.21 |
| 4 | Shipping logic is feasible | 0.50 | 0.80 | 0.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.
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.
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.
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.
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:
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.
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.
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.
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.
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?
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.
案例中的商家经营资料为模拟数据;涉及网站检查时,报告中的页面观察来自所列公开网址。
需安装产品集合和所需独立插件,路由器无法执行缺失方向。构建级循环还引用独立 agent-harness。
核对源码及随包文件:GitHub 6d2f02ea077e。本次为静态审查,不代表已完成安装运行或业务效果测试。
使用获授权输入,不把密钥贴入提示词。采用前检查面向客户的声明、计算、代码改动及任何拟议的外部操作。
路由产品工作,并检查持续发现节奏和机会解决方案树。2.11.1 版本提供路由、节奏评分和树校验三个 Python 工具,覆盖 12 个内置方向及四个独立打包方向。
按实际 Agent 选择方式,安装完整包,不要只复制页面中的 SKILL.md。 产品目标、研究证据、JSON 发现日志或树,以及已安装的目标 Skill。 开启新 Agent 会话,明确要求使用 product-skills。先用小型样本尝试下方一个场景,并检查输出。
将产品请求路由到一个受支持方向;检查访谈与假设测试节奏;在机会树用于路线图决策前进行校验
需安装产品集合和所需独立插件,路由器无法执行缺失方向。构建级循环还引用独立 agent-harness。
核对源码及随包文件:GitHub 6d2f02ea077e。本次为静态审查,不代表已完成安装运行或业务效果测试。
核对源码及随包文件:GitHub 6d2f02ea077e。本次为静态审查,不代表已完成安装运行或业务效果测试。
暂无评论。