Setup Discovery Pipeline

om-setup-agent-pipeline configures the delivery pipeline: ticket to merged PR. This skill adds the product layer on top of it — the part of the process that decides what gets built and why, before any ticket exists. A team that only wants the delivery pipeline never runs this skill and never sees the sections it writes.

The layer is switched by one config key, discovery.enabled, and lives in the same files the delivery setup already owns. What it adds:

• In SDLC.md: the product roles (Product owner, and optionally Domain expert and Designer), the Discovery stage driven by om-discover, the Intake row that requires a ready ticket, the Definition of Ready section, and Product decisions as a protected contract. Paragraphs and sections are inserted between <!-- discovery:start --> and <!-- discovery:end --> markers; rows and bullets carry an inline <!-- discovery -->. A re-run finds and refreshes exactly those without touching anything else.
• In .ai/agentic.config.json: the discovery block below. Nothing else in the config is changed.
• In the repository: <paths.specs>/research/ for interview notes, data extracts, and decision records, and one routing row in AGENTS.md when it carries the task-routing table.

What the layer unlocks once it is on: om-auto-manage-issues and om-auto-fix-issue check tickets against the Definition of Ready and stop cleanly on a gap instead of guessing; om-backlog refuses to file from assumptions; om-code-review treats the brief's non-goals, rules, and decisions as a protected contract; and the process document names who owns the why.

The product skills do not require this skill. om-discover, om-synthetic-users, om-backlog --dry-run, and om-mockup-prototype run in a repository without it (and, for om-discover, without any pipeline at all); they only mention this skill once in their reports as the way to get the gates. This is the single entry point of the product layer, and it pulls in what it needs: a missing delivery setup is run first, and missing product skills are named with their install command.

Arguments

• --defaults (optional) — skip the questions: no domain expert, no designer, brief under paths.specs.
• --refresh (optional) — re-render every marked block from the current template and show the diff; use after upgrading the collection.
• --dry-run (optional) — show every change it would make, write nothing.