plan-definition

Turn the spark given in the arguments into a product definition: $ARGUMENTS

Follow the plan-definition skill. This is the most upstream step — it defines the problem before plan-backlog turns it into a backlog. It produces a definition doc, never tickets.

Rules:

• If the arguments contain no idea or source, ask for one — but a one-liner is a valid start (this step is for vague sparks; you draw the rest out with questions). Accept pasted text, a path to a file (PDF / Word / Markdown), or a URL / artifact / Figma design link.
• Facilitate, never decide. Ask, propose candidate answers, and let the PO confirm or adjust at each step.
• Ground it. Generating options for the PO to choose is the job; asserting unverifiable facts (market/novelty/prior-art claims, invented metrics) as established is not. The skill's Grounding & provenance rule governs — mark each claim [PO]/[spark]/[proposed]/[unverified], and there's no research step, so market/novelty claims are [unverified] unless the PO supplies a source.

Run it in THIS conversation (guided, interactive)

The definition flow is interactive, so conduct it in the main conversation — the PO makes a decision at each step (do not hand it to a context-isolated subagent, whose output the user can't see mid-run). You may delegate intake reading (e.g. a large PDF/Figma fetch) to the plan-definer subagent to keep this context clean.

1. Intake — read the spark in whatever form it arrives (§1 of the skill). If it references a Figma design, run figma-fetch for context (FigJam /board/ URLs aren't fetched yet — take a board's content as pasted text).
2. Frame the problem (zoom-out) — draw out users, problem/outcome, why-now, constraints, success metrics, risks/unknowns, non-goals through guided questions with proposed answers. Work them conversationally, a few at a time — don't interrogate all seven at once. Leave genuinely-undecided items as open questions.
3. Directions & trade-offs (zoom-in) — propose 2–4 solution directions with trade-offs, recommend one, and wait for the PO to choose or refine.
4. Definition + approval gate: assemble the definition (problem statement, users, goals & non-goals, success metrics or "not established", chosen direction + alternatives, key decisions, risks/unknowns, open questions), each line carrying its provenance marker. Before the OK, walk the [unverified]/[proposed] claims — ask "what in here rests on something nobody has verified?" — then ask the PO to approve, adjust, or cancel. When the host supports artifacts, also render it as a navigable artifact (see the skill's review step) — but the approval still happens in the chat.
5. Handoff: on approval, tell the PO the definition is ready and hand it to /plan-backlog (whose framing is then lighter). Say plainly whether it's backlog-ready — if core must-haves are "not established" or it leans on [unverified] claims, flag that so plan-backlog re-derives rather than just confirming. If the backlog won't be built in the same sitting, offer to save it to docs/definitions/<slug>.md so plan-backlog can read it later. Create no tickets here.