Idea

/idea — a rough idea → a solid, decision-complete brief

This is the front of the loop. Before work gets scoped into a sprint, one idea gets thought all the way through: researched, stress-tested, and reduced to the simplest shape that actually solves the problem. You (the main loop) frame the idea and own the write-down; the idea-architect agent (deep planning, on fable) does the thinking. The output is a brief solid enough that /plan-sprint can scope it without re-deciding anything load-bearing.

Operating principle — collaborative, not autonomous

Unlike /work, this skill is a dialogue. It's the user's idea, and the goal is a plan they trust. So: think hard, present the brief, and iterate with the user before writing anything down. The one thing the architect must not do is hedge — it makes the real design decisions and defends them; the user is refining a concrete plan, not answering a questionnaire.

1. Frame the idea + gather context (you, before the architect)

• Capture the idea from the argument. If it's a one-liner, restate what you understand it to mean in a sentence and proceed (don't interrogate the user — that's the architect's job to resolve from the repo).
• Read CLAUDE.md, the README, and any relevant product/architecture docs and docs/adr/ so the brief is grounded in this repo's reality, constraints, and direction. git log --oneline -20 for recent context.
• Note the release model (this framework assumes a tagged merge to main) so the plan lands shippable.

2. Spin up the deep planning architect

Dispatch one idea-architect agent with the framed idea + the context you gathered — workflow:idea-architect when this plugin is installed, or bare idea-architect when running project-scoped from the source repo (use whichever form resolves). It researches best practices and prior art (WebSearch), lays out 2–3 genuinely different approaches, challenges the idea's assumptions, recommends the simplest approach that works, resolves the load-bearing decisions, and returns a decision-complete brief. It writes no files and cuts no tickets — it returns the brief to you.

(If the idea-architect agent isn't available — e.g. running outside the plugin — fall back to a general planning agent with the same brief and the same "research, compare approaches, challenge assumptions, be decision-complete, bias to simplicity" instructions.)

3. Present the brief and iterate (the human loop)

Show the user the brief — lead with the recommended approach and why, the key decisions, and anything the architect pushed back on (assumptions that don't hold, a simpler thing to build instead). Then work with them: if they disagree or add constraints, re-run or refine with the architect until the plan is one they'd stake the sprint on. This back-and-forth is the value of the skill; don't rush to write-down.

4. Write it down (automatic) + hand off to /plan-sprint

As soon as the brief is settled, write it to docs/ideas/<slug>.md automatically (create docs/ideas/ if absent) — no separate confirmation for the write itself; the brief is a durable, low-risk artifact and capturing it is the whole point. Then:

• Record ADRs. Any load-bearing decision the brief settles gets an ADR in docs/adr/ (match the repo's existing format/numbering; create docs/adr/0001-<slug>.md if the repo keeps none yet). Big decisions live in the repo, not just a brief.
• Auto-advance to plan-sprint: once the brief is settled, invoke the plan-sprint skill automatically — as /workflow:plan-sprint when this plugin is installed, or bare /plan-sprint when running project-scoped from the source repo. Use whichever of those two is actually available in this session; do not skip the handoff because one form isn't registered. Pass the brief's HANDOFF TO PLAN-SPRINT framing as the theme — the cycle flows on into ticketing without a manual re-invoke. It still stops at /plan-sprint's own approval gate before any tickets are created, so this handoff commits to nothing outward. Skip the handoff only if the user scoped the run to the brief alone ("just the brief", "don't build this yet") or the brief's conclusion is "don't build it."

Guardrails

• /idea produces a brief and ADRs — no tickets, no code. Ticketing is /plan-sprint; building is /work. Keep the stages separate.
• Bias to simplicity: the best outcome is often a smaller build than the idea proposed, or a well-argued "don't build this." Surface that plainly rather than dressing up a faithful plan for the wrong thing.
• Don't skip the human loop — this is the one skill in the set that's meant to be collaborative. Write the brief down only once the user is satisfied.