Product Discovery Brief Builder

Discover

Establish product context that later skills can use without guessing. Help the user make the current decision, then record the basis, scope, rules, and unresolved risks in ${SPECS_DIR}/product-brief.md. om-brainstorm handles an individual idea; this skill establishes or refreshes the product context it reads. The brief's Non-goals, Business rules and Decisions also supply the protected contract that om-code-review and om-ux-review-pr enforce under SDLC.md.

<HARD-GATE>
Never invent research, user behaviour, quotes, or measurements. A missing fact stays unknown or becomes an explicitly identified hypothesis. A human may choose to build with an untested assumption; that decision does not turn it into evidence. Decisions without human confirmation remain `proposal`. Material needed for the current decision goes on a collection plan; irrelevant empty sections need no research task.
</HARD-GATE>

Arguments

• {topic} (optional): product or area to discover. When absent, ask what the brief is for.
• --mode existing|client|own (optional): use the stated mode; otherwise infer it from the material and confirm it with the opening decision frame.
• --refresh (optional): update an existing brief, preserving ids and superseded decisions.
• --research <dir> (optional): raw material directory; default ${SPECS_DIR}/research.
• --quick (optional): one round, normally two or three independent questions; inline skeptic; the same evidence, coherence, and compression checks. Use material already available, including flows. Defer details irrelevant to the next decision without creating research tasks. Further substantive questions require the user to choose to extend the session.

Modes

Read references/modes.md for the selected mode. Modes guide where to look and what might matter; depth follows the current decision and its risks.

Workflow

ALWAYS check first: Apply .ai/skills/om-discover/SKILL.md when present; safety rules still win.

0. Load context. Follow references/agentic-setup.md. Config is optional; without it use .ai/specs and do not start pipeline setup. Resolve paths, load available repository and design context, and apply the untrusted-content boundary. Tracker operations, when configured, are read-only: search-issues, search-prs, get-issue, list-issue-comments. Read references/rules.md for shared conventions.

1. Frame the decision and mode. Read enough material to state what the session should help decide. If unclear, ask what decision the user needs to make. An explicit mode stands; otherwise propose existing for a product with users, client for material from a client, or own. Confirm the inferred mode in the same exchange rather than a separate setup round. Combine relevant concerns when modes overlap. The brief owner defaults to the person running the session; settle missing names only when needed to attribute a decision.

2. Check the material. Follow references/context-gate.md. Read available research, repository files and tracker context before asking the user for facts. Identify what supports the current decision and what could change it. Keep unsupported claims as unknown; with the user's choice to continue on assumptions, record them honestly. Put consequential missing material on a collection plan. Keep other empty sections short and deferred. On --refresh with a tracker, read resolved-assumptions comments on open and merged spec PRs through search-prs and list-issue-comments here, before drafting. Record confirmed choices with the confirmer and source; factual assumptions remain unverified unless new evidence supports them.

3. Ask and record. Follow references/interview-rounds.md and references/voice.md. Ask two or three independent questions that could change the decision, or one when later questions depend on it. Use batches of up to eight only when the user prefers them. Ask about experiences without suggesting the answer. Offer a recommendation for a decision only when its alternatives and tradeoff can be explained. Accept a concrete story or “we don't know”. Full sessions have at most three substantive rounds including skeptic questions unless the user asks for more; quick sessions have one. Record confirmed decisions under ${research}/decisions/; a direct account may be captured under ${research}/interviews/ as described in the context gate. Writing a record documents its origin, not the truth of every belief it contains.

4. Draft the brief. Use references/brief-template.md and references/evidence-tiers.md. Start with the short Decision summary, then retain all existing detailed headings and ids. Give each claim a clear meaning as an observation, decision or hypothesis and a source tag in its canonical section. Keep full rule wording in one place and refer to it elsewhere. Show the independent source basis and important unknowns beside the legacy Coverage count; the count is not product validation.

5. Check the draft. Apply references/quality-gate.md, including source fidelity, problem/solution fit, the proposed test, and compression. Fix your own unsupported generalizations, transcription mistakes and duplicate prose from the sources. An honestly incomplete brief may be written, but must say what it cannot support yet.

6. Get a skeptical reading. Give a fresh-context subagent the draft, mode, cited source paths, and references/skeptic-prompt.md. It checks the material independently. If subagents are unavailable, use the same checks inline and disclose that the full pass lacked independent review. Separate agent errors, which you correct, from missing facts or consequential decisions, which go back to the user within the round budget. Under --quick, use the same checks inline and state the lack of independent review. If the budget is spent, leave the unresolved item visible and ask permission to extend only when needed; do not add a hidden round. Recheck changed content.

7. Confirm and write. Present the Decision summary, the scope split, consequential decisions and owners, evidence limitations, and remaining blockers. Use clear prior confirmation when it covers these exact choices and their material consequences; otherwise wait for the user's confirmation before writing ${SPECS_DIR}/product-brief.md. A batch confirmation covers only explicit independent choices; it cannot supply missing facts or answer unresolved prerequisites. A pending choice may remain a proposal. On --refresh, retain old ids and history; a changed decision gets a superseding row approved by its owner. If material or decisions have changed since review, repeat steps 4–6 on the changed content before confirmation and writing. Write only the brief and the context gate's authorized records and templates.

8. Offer a relevant next step. Follow references/prototype-handoff.md. Offer one action the current evidence makes useful and run another skill only when the user authorizes it. A synthetic panel requires a concrete Key flow and a reason that examining it would inform the current decision, or the user's request. Without a flow, name what is missing and skip that handoff; never invent one. Choose the panel subject and arguments through references/modes.md. After a completed panel, offer a relevant neutral prototype through om-mockup-prototype, then a separately authorized walkthrough only when its verification passed. Refresh the brief once through steps 2 and 4–7 from the completed material, preserving confirmation and review. Resume at readiness, without repeating panel or prototype offers. If readiness is met, offer om-backlog <brief> --dry-run; otherwise name the specific missing material or decision. Further questions require an explicit session extension. A backlog dry run does not authorize issue filing. Missing companions stop only their handoff; do not install anything.

9. Report. Follow references/report-templates.md. State the useful outcome and the remaining uncertainty, link the detailed record, and end with the output lines below.