dcouple Discussion
Topic: $ARGUMENTS
Have an interactive, opinionated discussion. The goal is shared clarity - understanding
the problem, weighing the options, or pinning down what's actually happening - not a
document. When the discussion converges on something worth building or fixing and no work
item exists, capture starts through the create-brief skill - invoked by the user or
this agent; this skill's job still ends at clarity.
Conversation and research only - unless asked
Don't edit source files, propose diffs to apply, or write documents, specs, tickets,
or verification criteria unless the user explicitly asks for one mid-discussion.
Capture belongs to the create-brief skill. Two exceptions: Step 3's decision
log - a record of what was decided, not a deliverable - and Step 2's throwaway
probes, which are research.
Steps
1. Dispatch the right specialist for each question
Delegate legwork to sub-agents so bulky exploration stays out of this thread. Pick by what the user is actually asking:
- How does our code work? What exists today? → the
codexskill, rolecode-researcher(returns file:line findings). - What do the docs / ecosystem / other people do? → the
web-researchersub-agent (returns a cited dossier). Reach for it whenever up-to-date information or outside opinions would sharpen the discussion - library versions, current best practice, how others solved this. - Why is this broken? Is this a bug? → the
codexskill, roleinvestigator(reproduces and root-causes, returns a finding with evidence and confidence). If reproduction requires driving the running app, dispatchfrontend-verifierfirst to exercise the flow and capture evidence, then pass its transcript along with the defect report.
Only research what the discussion actually needs - let questions pull research, not the other way around. Dispatch mid-conversation as new questions arise; run independent dispatches in parallel.
Success criteria: every claim you make about the codebase, ecosystem, or defect traces to a sub-agent finding, a probe result, or a user statement, not a guess.
2. Discuss and converge
- Present findings and options with tradeoffs; be opinionated - recommend with reasoning, defer to user judgment.
- Validate, never guess. A checkable fact (what the code does, what a tool supports, what a doc says) gets checked - Step 1's specialists or a direct look - before it shapes a decision; state what was validated vs what remains assumption. Where a choice hinges on an intangible - the user's risk appetite, priorities, taste - ask the user; never substitute an assumption for their answer.
- Probe before you ask. Classify a fork before surfacing it. When the answer
is observable by running something - behavior, timing, output, perf, layout -
build the cheapest throwaway probe under
./tmp/, run it, and present the result with a recommendation. Probes run local and read-only against isolated state; anything that touches production or mutates real data gets the user's go-ahead first. Reserve questions for the product and preference calls no experiment settles. A probe answers faster than the user can, and hands them a result to react to. - Name disagreements and unresolved choices instead of papering over them.
- Keep altitude: decisions and direction, not file-by-file detail.
Success criteria: the user says the question is answered, the direction is clear, or they're ready to capture a work item.
3. Log the decisions, then hand off
When the discussion converges, write the decision log to
./tmp/discussions/YYYY-MM-DD-<slug>.md: the decisions made and why, the
direction chosen and over what alternatives, constraints the user stated,
open questions. A few lines each - dated and slugged so parallel
workstreams never collide. This is how intent survives past the
conversation: /create-brief's drafting step reads it, and anyone resuming
the thread starts from it instead of from memory.
When the discussion has converged on capturable work with no existing item, start capture
yourself with /create-brief - single-outcome or multi-phase, the phase cut is the capture
skill's step. Publish remains gated by the capture skill's alignment pause. Otherwise, suggest
the relevant next steps:
Decision log: ./tmp/discussions/YYYY-MM-DD-<slug>.md
Suggested next steps:
- `/create-brief [title]` - capture the work (feature or bug, single-outcome or multi-phase) as a brief
- `/discussion [follow-up]` - keep exploring a different aspect