using-loom-discovery

name	using-loom-discovery
description	Family entry router for loom-discovery, the loom problem-space station. Use when unsure which discovery skill applies, or when a product idea's target users are still unclear (說不清是給誰用的 / not sure who this is for / 誰のためかまだ不明) — comes BEFORE product-principles. Routes worth-doing asks (值不值得做 / worth my time budget) to business-value, and user-needs asks (需求研究 / user research / ユーザーインサイト) to user-insights. Non-discovery asks redirect to their family entries. Members share no artifact and no agent.
version	0.1.0

using-loom-discovery

If you are a subagent already dispatched with an explicit role prompt, **do not** re-route through this skill. Follow the prompt you were dispatched with directly. This router is for the parent orchestrator only. **You have loom-discovery.** This skill does not map needs, assess worth, or write any artifact itself — it is the thin entry that decides which of loom-discovery's two member skills the work needs, after checking whether discovery is even the right station yet.

§Intake

All user-facing narration in this router — briefs, routing decisions, recommendation asks — follows loom-pipeline/hooks/family-relay.md §Family relay discipline (pointer, never copy).

Step 1 — 前站檢查 (upstream check). Discovery sits upstream of principles/design/spec/code — it is normally the FIRST station a product-shaped idea reaches, not a station something else feeds into. Still, check the target repo against the loom family's on-ramp criteria table (loom-pipeline/hooks/family-reception.md — the reception SSOT; reference it, don't copy its rows here) for the negative guard: a bug fix, a refactor, or a test-covered increment skips discovery entirely and proceeds straight to whichever downstream station applies. When both a discovery row and another row fire on the same ask, the precedence note recorded in family-reception.md governs — don't re-derive it here.

Step 2 — 對站檢查 (peer check). If the ask isn't discovery work at all — it's a product-constitution ask, a UI/UX design ask, a spec fan-out ask, or an implementation/code ask — redirect to the matching family entry (using-loom-product-principles, using-loom-interface-design, using-loom-spec, using-loom-code) rather than forcing it through loom-discovery.

Step 3 — family routing (disambiguation). Once the ask is confirmed discovery work, route between loom-discovery's two members by the specific verb:

• "worth doing?" / is this worth my time or resources — an adversarial worth-it check, a GO / NO-GO / NEEDS-MORE-RESEARCH call → business-value.
• "what do users need?" / what problem exists, for whom — evidence- linked opportunity mapping, or committing to which needs to serve → user-insights.

When in doubt, ask "are we deciding whether it's worth doing, or are we figuring out what the problem/users actually are?" — the answer picks the member.

Step 4 — brief before a complex fork. A discovery fork this router surfaces (a value commitment, an on-ramp choice) can itself be non-trivial. Before you ask the user a discovery fork this complex — ≥3 trade-offs, ≥2 implementation paths, or architectural blast radius — run dev-workflow:brief-before-asking first instead of improvising the question.

Family

• business-value — adversarial worth-it check (Shape Up betting register, not a Cagan business-viability study). Optional: fires only under its own named trigger conditions (see its SKILL.md), silently skipped for personal tools or an already-decided GO. Produces business-value.md.
• user-insights — the core research verb. Maps the opportunity space (evidence-linked needs) and then proposes a value commitment the user must ratify. Produces user-insights.md, evidence.md, research/.

Typical sequence: user-insights ↔ business-value. Most discovery work starts with user-insights — map the opportunity space with evidence before anyone can judge whether it's worth doing. business-value (the "assess" step) is skippable — it only fires under its own trigger conditions — and re-entrant: it can run again after user-insights surfaces more research, and user-insights can loop back after a NEEDS-MORE-RESEARCH verdict. Neither member is a required gate on the other; call the one the ask actually names.

Professional isolation is contract-level. The two skills share no artifact and no agent: business-value's agents may not map needs; user-insights's agents may not render investment verdicts. Do not blend their outputs into one file or one dispatch.

How to access skills

Harness	Mechanism
Claude Code	Use the Skill tool, e.g. Skill(skill: "business-value") or Skill(skill: "user-insights").
Codex CLI	Use the skill tool (Codex shape).

If the user types /business-value or /user-insights, that is an explicit invocation — load it via the Skill tool directly. Do not guess names that are not listed above.

What this router does NOT do

• Does not assess worth-doing itself — that is business-value.
• Does not map needs or research evidence itself — that is user-insights.
• Does not auto-invoke either member — the harness invokes them when the user's next message + this routing decision match.