feat: /plan-definition — a guided discovery/definition phase upstream of plan-backlog

[atamanvega]

Spin-off from #72 (idea from @santielizondo).

The gap

plan-backlog starts from a defined problem and turns it into a backlog. But the hardest, most valuable part often comes before that: defining the problem — the discovery/definition thinking. plan-backlog's guided framing step is deliberately light ("how do we slice this into a backlog"); it is not deep product definition. /plan-definition fills that: a guided discovery/definition phase that produces a clear problem definition, which then feeds plan-backlog.

Full flow becomes: /plan-definition (define the problem) → /plan-backlog (turn it into a backlog) → ticket → PR → follow-ups.

What it does (proposed)

A guided, Socratic phase — facilitate, don't decide — moving zoom-out → zoom-in:

1. Intake — a spark in any form (even a one-liner; vaguer than plan-backlog's input). Reuse the multi-format intake (text / PDF / Word / artifact / Confluence / Figma).
2. Frame the problem — guided questions + proposed answers to confirm/adjust: users, the problem/outcome, why now, constraints, success metrics, risks/unknowns, non-goals. Offer options, don't assume.
3. Directions & trade-offs — propose 2–4 solution directions (e.g. MVP vs full, different approaches/sequencing) with trade-offs → PO chooses/refines.
4. Produce a definition — a structured product definition / brief (problem statement, users, goals & non-goals, success metrics, chosen direction, key decisions, open questions). Rendered as a rich navigable artifact on Claude (reuses idea: richer artifact format for generated plans (navigable/collapsible/searchable HTML) #74), Markdown elsewhere. Approval-gated.
5. Handoff — the definition becomes the input to /plan-backlog, whose framing step is then lighter because the problem is already defined.

Boundary with plan-backlog (important)

• /plan-definition = define the problem & direction — no backlog, no tickets.
• /plan-backlog = turn a defined problem into a backlog (and, when a definition exists, consume it instead of re-framing from scratch).

Discovery surfaces (Santi's idea)

Collaborative whiteboards fit discovery well:

• FigJam — via the existing Figma connector, could be a context source (read a board) and/or a place the definition maps to. (Figma MCP is already in the kit.)
• Miro — no first-party connector today; treat as out-of-scope for v1 unless one exists.

v1 could be text + rich artifact, with FigJam as an optional context input; deeper whiteboard integration is a follow-up.

Guardrails (same doctrine)

• Facilitate, never decide for the PO. Offer alternatives, ask for decisions.
• Never fabricate — ground everything in the intake + the PO's answers.
• Approval gate before the definition is finalized; nothing downstream (no tickets) until plan-backlog.
• Portable across hosts (skill + a Claude command/agent, like plan-backlog).

Open questions (to refine)

• Separate command/skill (/plan-definition) vs a "deep-definition" mode of plan-backlog? (Leaning separate — different output: a definition doc, not a backlog.)
• The canonical definition template — which sections are must-have vs optional?
• Where the definition lives: an artifact only, a committed file, or a Confluence page?
• FigJam in v1: read-only context, or also produce/seed a board? Worth it now?
• How much of plan-backlog's framing should collapse when a definition is handed in?

Design-only for now — capturing so it can be refined before any build. Relates to #72 / #74.

[atamanvega]

@santielizondo — fleshed this out into a design plan (your idea): a guided discovery/definition phase that runs before plan-backlog — frame the problem (users, outcome, metrics, constraints, non-goals), explore 2–4 directions with trade-offs, and produce a product definition (rich artifact) that then feeds /plan-backlog. Facilitate, never decide; approval-gated.

Would love your take on the open questions — especially: separate /plan-definition vs a deep-definition mode of plan-backlog; the must-have sections of the definition template; and whether FigJam is worth pulling in for v1 (via the existing Figma connector) or a later step. Refine away 🙏

[atamanvega]

v1 is up in #79 🎉 — the plan-definition skill + /plan-definition command + plan-definer agent, plus plan-backlog now runs a lighter framing when a definition is handed in.

I took a first pass at the open questions (separate command; the must-have template sections; FigJam as read-only context in v1; definition lives in-chat/artifact with optional docs/definitions/<slug>.md) — all called out in the PR description as v1 decisions to refine. @santielizondo, review + refine away 🙏