Discuss

/discuss — Idea Exploration & Validated Planning

Bridge "I have an idea" to "I'm ready to build" through conversation, research, and adversarial validation.

Shape

• Triage first. If the idea is small and already clear, say so and offer /dev "<description>" directly — a research pass for a one-file change is waste. Discuss earns its cost when the problem, approach, or scope is genuinely open.
• Research runs alongside the conversation. Use the built-in Explore subagent for codebase scouting and web search for the external landscape (libraries, platform features, recent releases). Weave findings in as they land; let them change your questions.
• Validation is one adversarial pass, not a committee. Before delivering, deliberately stress-test the drafted plan with fresh eyes (a readonly /spec-reviewer pass over the plan, or a deliberate refute pass): feasibility against the real codebase, simpler alternatives, native platform features that replace custom work, recent releases that change the picture, and assumptions nobody verified. Report only findings that would change the plan.
• End with a handoff. The validated plan closes with an <adlc-handoff> block so /spec (complex work) or /dev (small validated change) inherits the hypothesis, assumptions, and human decision boundaries without re-asking.

Modes

• Fresh — new idea, no existing implementation. Scout maps patterns and integration points.
• Revisit — critique something already built. Scout analyzes the current implementation; the adversarial pass also asks whether change is needed at all — "keep it" is a valid outcome.
• Reference-driven — @files or URLs provided. Read them all before the first question; your opening should show you understood them.

Modes combine; detect and adapt.

Constraints

• Don't start implementing — that's /dev.
• Ask at most 2-3 questions per turn; genuine exploration beats interrogation.
• If research contradicts a user assumption, surface it plainly.
• The adversarial pass runs before delivery on any plan headed for implementation; skip it only when the outcome of discussion is "don't build this."
• Unattended mode (--unattended in the request — headless/CI runs with no user to answer): don't end the turn on a question and don't wait on the interview. Run the research and the adversarial pass, adopt the most reasonable interpretation for each open question and list every adopted assumption in the plan, then deliver the plan and the <adlc-handoff> tagged assumptions: unreviewed so a human can veto before /spec or /dev consumes it.

Full phase instructions: references/phases.md.