IntermediateAgent Skill

Product Skills: Product Routing and Discovery Tools

Coordinate product management skills for research, discovery, strategy and analysis from one entry point. This Skill routes your assistant to the relevant specialist, while Python tools check discovery cadence and Opportunity Solution Trees, helping a team connect a product question to the next concrete piece of work.

Views
0
Copies
0
Favorites
0
Editorial Score
82/100
01

What this Skill does

Product Skills is a coordinator rather than a single method for every product problem. Its collection contains bundled lanes and separately packaged workflows, with tools for task routing, discovery-cadence scoring and checking the structure of an Opportunity Solution Tree.

Use it when the team needs to choose a product workflow or review how consistently discovery is being practiced. Install the target specialists as well as the router; missing lanes cannot run just because the entry point lists them. Build-scale workflows also reference a separate agent harness.

02

What makes it different

01

Approach and advantage

Routing separates product questions that need research, prioritization or a different specialist method. Provide the goal and available evidence so the assistant can choose a lane based on the work to be done rather than the broad label 'product strategy.'

02

What you can use it for

Cadence scoring and tree linting make parts of the discovery process inspectable. The tools can flag structural gaps in supplied logs or trees, while the team still needs to judge whether the underlying customer evidence supports the proposed opportunities and solutions.

03

Before you install

Inputs to prepare

A product goal, research evidence, JSON discovery logs or trees, and installed target Skills.

Agent and runtime

Use a Skill-capable agent with file access. Python 3 is required for the bundled Python helpers; inspect their sample schemas before supplying data.

Scope to confirm

Install the product collection and required standalone plugins; the router alone cannot execute missing lanes. Build-scale loops additionally reference the separate agent-harness.

04

Install and get started

Copy this request into Codex or Claude Code. The assistant downloads the original repository at the specified commit, installs the complete files and checks required dependencies.

  1. Open Codex or Claude Code with local file and terminal access.
  2. Copy the request below into the app you are using. The assistant will select that app’s installation directory.
  3. Check the returned path and file checks. Start a new session if needed, then ask the assistant to use the installed Skill.
Install product-skills in the app I am using and carry out the file installation, not just explain it. Original repository: https://github.com/alirezarezvani/claude-skills.git Commit: 6d2f02ea077eead1bee5411a31bcc6db5a11a70c Skill folder: product-team/skills/product-skills 1. Download this exact source into a new directory. Read SKILL.md and its setup references before running any bundled scripts. Do not substitute another author’s package. 2. For Codex, use ~/.agents/skills/product-skills; for Claude Code, use ~/.claude/skills/product-skills. Install only for my current app. This router requires the sibling Skills in product-team/skills; install every direct child folder containing SKILL.md, and retain the repository checkout for repository-relative references. Separately distributed plugins are not automatically installed. Check all destination folders first; if any already exist, report differences before replacing them. 3. Compare the source and installed file lists and hashes. Inspect documented runtimes, dependencies and required connections. Configure only the local dependencies needed for this Skill; use an isolated environment when appropriate. Ask me to complete any account login locally, without putting credentials in chat. 4. Report the source commit, actual installation path, file-check results and any remaining runtime setup. Explain how to invoke product-skills in this app. Check discovery separately from file copying; start a new session if needed. Do not run production tasks or claim a successful business outcome from installation alone.
05

Original Skill.md

This is the unchanged source SKILL.md for the reviewed version. Install the complete package to retain referenced scripts, assets, and instructions. Starter prompts below are EcomAgentTools examples.

---
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

Get started

Starter prompts for the main use cases—copy and use them directly.

01

Route a product request to one supported specialist

Route a product request to one supported specialist Use for: Route a product request to one supported specialist. Prepare: A product goal, research evidence, JSON discovery logs or trees, and installed target Skills.

Show prompt and variablesHide prompt and variables
Use the installed product-skills Skill. Task: Route a product request to one supported specialist. Inputs: [INPUT]. Constraints: [CONSTRAINTS]. Check missing information first. Produce a reviewable result with evidence, assumptions, and next steps. Install the product collection and required standalone plugins; the router alone cannot execute missing lanes. Build-scale loops additionally reference the separate agent-harness.

Replace these variables

[INPUT]
A product goal, research evidence, JSON discovery logs or trees, and installed target Skills.
[CONSTRAINTS]
Scope, allowed actions, output format, and review requirements.
02

Review interview and assumption-test cadence

Review interview and assumption-test cadence Use for: Review interview and assumption-test cadence. Prepare: A product goal, research evidence, JSON discovery logs or trees, and installed target Skills.

Show prompt and variablesHide prompt and variables
Use the installed product-skills Skill. Task: Review interview and assumption-test cadence. Inputs: [INPUT]. Constraints: [CONSTRAINTS]. Check missing information first. Produce a reviewable result with evidence, assumptions, and next steps. Install the product collection and required standalone plugins; the router alone cannot execute missing lanes. Build-scale loops additionally reference the separate agent-harness.

Replace these variables

[INPUT]
A product goal, research evidence, JSON discovery logs or trees, and installed target Skills.
[CONSTRAINTS]
Scope, allowed actions, output format, and review requirements.
03

Check an opportunity tree before using it for roadmap decisions

Check an opportunity tree before using it for roadmap decisions Use for: Check an opportunity tree before using it for roadmap decisions. Prepare: A product goal, research evidence, JSON discovery logs or trees, and installed target Skills.

Show prompt and variablesHide prompt and variables
Use the installed product-skills Skill. Task: Check an opportunity tree before using it for roadmap decisions. Inputs: [INPUT]. Constraints: [CONSTRAINTS]. Check missing information first. Produce a reviewable result with evidence, assumptions, and next steps. Install the product collection and required standalone plugins; the router alone cannot execute missing lanes. Build-scale loops additionally reference the separate agent-harness.

Replace these variables

[INPUT]
A product goal, research evidence, JSON discovery logs or trees, and installed target Skills.
[CONSTRAINTS]
Scope, allowed actions, output format, and review requirements.
07

Worked example: Route a business objective into discovery and assumption checks

The synthetic objective is to move US session-to-order conversion from 2.5% to 3.0% while keeping refunds/sales at or below 5%. Inputs include four shoppers’ records, an opportunity tree, assumptions and a discovery log.

Steps and prompt

  1. Prepare the attached business materials, preserving amounts, units, dates and metric definitions.
  2. 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.
  3. Submit the exact prompt below. Read the primary deliverable on the right and download all deliverables for the team handoff.

Case input files: 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.

What the run produced

The primary file produced by this prompt is shown below in its original language.

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.

Merchant business data is synthetic. Website observations, when present, come from the public URLs listed in the report.

08

Risks and operating notes

Known limits

Install the product collection and required standalone plugins; the router alone cannot execute missing lanes. Build-scale loops additionally reference the separate agent-harness.

Evidence and review

Source and package files reviewed: GitHub 6d2f02ea077e. This is a static review, not an installation or business-outcome test.

Before acting on the result

Use authorized inputs and keep secrets out of prompts. Review customer-facing claims, calculations, code changes, and any proposed external action before applying them.

Frequently asked questions

What does it do, and what is the advantage?

Route product work and check continuous-discovery cadence and Opportunity Solution Trees. Version 2.11.1 adds three Python tools for routing, cadence scoring, and tree linting across 12 bundled and four separately packaged lanes.

How do I install it and start?

Choose the method for your agent and install the complete package, not just the displayed SKILL.md. A product goal, research evidence, JSON discovery logs or trees, and installed target Skills. Start a new agent session and explicitly ask to use product-skills. Try one use case below with a small sample and review the output.

Which situations is it useful for?

Route a product request to one supported specialist; Review interview and assumption-test cadence; Check an opportunity tree before using it for roadmap decisions

What limitations should I know?

Install the product collection and required standalone plugins; the router alone cannot execute missing lanes. Build-scale loops additionally reference the separate agent-harness.

What was checked for this page?

Source and package files reviewed: GitHub 6d2f02ea077e. This is a static review, not an installation or business-outcome test.

No reviews yet.

Leave a review

Rate every dimension, then share your real experience.

Task effectiveness
Setup and ease of use
Reliability and guardrails
Documentation clarity
Time to first useful result
Author / maintainer

Alireza Rezvani

Source and package files reviewed: GitHub 6d2f02ea077e. This is a static review, not an installation or business-outcome test.