/plan-definition

name: plan-definition
description: Turn a spark (an idea, even a one-liner, in any format) into a clear product definition through a guided, Socratic discovery phase — frame the problem (users, outcome, metrics, constraints, non-goals), explore 2–4 directions with trade-offs, and produce an approved definition that then feeds plan-backlog. Facilitate, never decide. Use when a product owner wants to define a problem before breaking it into a backlog.

Plan Definition

Turn a **spark** into a clear **product definition** through a guided discovery phase — the **most upstream** step of the workflow, for the product-owner persona. It runs *before* `plan-backlog` and closes the loop **define → backlog → ticket → PR**.

`plan-backlog` starts from a *defined* problem and turns it into a backlog; its framing step is deliberately light ("how do we slice this"). **`plan-definition` does the deep part: defining the problem itself** — who it's for, the outcome, why now, the constraints, the success metrics, the chosen direction. Its output is a **definition doc**, not a backlog and not tickets. You **facilitate** the PO's thinking — ask, offer options, and let them decide; never decide the product for them.

Trigger

A request to *define*, *frame*, *scope*, or *think through* a product idea before there are stories — e.g. *"help me define this feature"*, *"I have a rough idea, let's shape it"*, *"what's the problem we're solving here"*. If the request is already a defined problem asking for tickets, that's `plan-backlog`, not this.

Boundary with `plan-backlog` (important)

• **`plan-definition`** = define the problem & direction. **No backlog, no tickets.** Output: a product definition.
• **`plan-backlog`** = turn a *defined* problem into a backlog. When a definition from here is handed in, it consumes it and runs a **lighter framing** (confirm, don't re-derive) instead of framing from scratch.

1. Intake — read the spark in whatever form it arrives

The input is deliberately vaguer than `plan-backlog`'s — **a one-liner is a valid start.**

• **Pasted text / chat description** → use directly.
• **PDF** → read it (page range as needed).
• **Word (`.docx`)** → convert first (`textutil -convert txt file.docx -output -` on macOS, or `pandoc file.docx -t markdown`), then read. If neither tool is available, ask the user to paste the text or export a PDF.
• **Artifact / Confluence page / URL** → fetch it.
• **Figma link** (`figma.com/(design|file)/…`) → run `figma-fetch` for design context. For a **FigJam** board, `figma-fetch` doesn't read `/board/` URLs yet — ask the PO to paste the board's content as text. v1 treats any whiteboard as **read-only context**; nothing is written back to it.

If the spark is thin, that's expected — the framing step (§2) is where you draw it out with questions, not where you fill it in for the PO. See **Grounding & provenance** next; it governs the whole flow.

Grounding & provenance (the core rule — read before drafting)

A one-liner is a valid start, so most of what a definition could contain is **not** in the intake. That is fine — but it makes *how you introduce content* the thing that keeps this honest. Two moves that look identical on the page are completely different:

• **Generating options for the PO to choose** — proposing 2–4 framings, directions, or candidate answers and letting the PO pick — is **the point of this skill.** Do it freely.
• **Asserting facts about the world** the PO didn't give you — "no mainstream app does X", "this is why people churn", "the market for Y is underserved", a specific metric target — is **fabrication when stated as established.** You cannot verify market, prior-art, or novelty claims here; the skill has no research step. So:
• Offer them as the PO's to confirm ("*is it true that…?*"), or
• Mark them **unverified** in the definition, or
• Leave them out.

**Every claim in the definition carries a provenance marker** so a proposal never renders identically to a decision:

• `[PO]` — the PO stated or explicitly confirmed it.
• `[spark]` — it came from the intake source.
• `[proposed]` — you generated it; the PO accepted the option but the *content* is yours.
• `[unverified]` — a factual claim about the world that nobody has checked (all market/novelty/prior-art claims are at least this).

The distinction to never blur: **a direction the PO selected from your options is a real decision; a fact you supplied to justify it is not, until it's checked.** When in doubt, mark it lower, not higher.

2. Frame the problem (zoom-out) — guided questions, proposed answers

Draw out the definition through a **Socratic** exchange: for each dimension, ask, **propose a candidate answer**, and let the PO confirm or adjust. Proposing candidates is exactly right (see **Grounding & provenance**) — just don't smuggle in unverifiable *facts* as if they were established (mark those `[unverified]` or ask). Offer options; don't assume. Move through:

• **Users / audience** — who is this for, and who is it *not* for?
• **Problem / outcome** — what problem, and what does success look like for the user?
• **Why now** — the trigger or opportunity.
• **Constraints** — technical, time, budget, compliance, existing systems.
• **Success metrics** — how we'll know it worked (leading + lagging where possible).
• **Risks / unknowns** — what could break the thesis; what we still don't know.
• **Non-goals** — explicitly out of scope, to keep the definition sharp.

Don't interrogate all seven in one dump — work them conversationally, a few at a time, folding the PO's answers back in. It's fine — often better — to leave an item **explicitly unresolved** rather than force an answer: any must-have section may carry *"not established"* with a note on what's needed to settle it (see §4). This applies especially to **Success metrics**, which POs frequently decline — record "not established (no baseline yet)", never a number you made up.

**No researc