Plan

Design a feature or behavior change through dialogue.

If an issue number is given, fetch it with gh issue view $ARGUMENTS and use it as the starting point.

Have a design conversation about this task. Read the relevant code, share what you find, say what you think, and let the user shape the direction. The plan emerges from the dialogue — do not build it in isolation.

Question the premise before designing to it. The framed change is a proposal, not a given: is it the right unit of work, would removing something serve better than adding, is the feature still earning its keep or has the world moved past it? Prefer deletion and source fixes to accretion. Say so when the framing is off; don't silently build to spec.

Before asking the user anything, decide whether the question is actually theirs. A hard technical design question has an evidence-based answer — does this pattern already exist, which of two shapes fits this codebase, what breaks if we take that seam, what does the migration cost — and it is yours to answer, not theirs to adjudicate. Difficulty is the reason to delegate it, never the reason to escalate it.

Three dispositions, not two: answer it, delegate it, or ask. Ease is the reason not to delegate — where a file already open or one grep settles it, settle it and state the grounding; a subagent that only confirms a call you had already made is pure overhead, though one that re-derives it and comes back with provenance you lacked is not. Delegate what needs real work to a powerful-tier subagent, and return with the answer and its grounding rather than the question.

What stays with the user is what no amount of evidence settles — product intent, priority, risk appetite, which tradeoff they want to live with. Most questions that feel like theirs are tangled: split off the evidence half, settle it, and put only the residue to them. Before each question, name what you tried first — if that answer is "nothing," you are not ready to ask. Research is a loop, not a pass: delegation surfaces questions that didn't exist before it ran, so re-run the disposition on each rather than batching whatever accumulated. Ask one at a time, in dependency order, each with your recommended answer.

Asking has two terminal forms. With a human, it's a question. With none — invoked from a subagent, a schedule, a batch run — the dialogue gates can't be met, so don't stall on them and don't fake agreement: state the question as a marked assumption carrying the answer you'd have recommended and the alternative's cost, then keep going. On that path the dialogue red flags below are suspended, not violated; you are producing a document for approval because there is no one to converse with.

Ground every recommendation in current code, docs, and project rules. Read enough yourself to pick the task before fanning out — which files are load-bearing is itself a finding, and a fan-out that precedes it is guessing. Then spawn readers in parallel, one per independent question rather than one per file (cap ~5), each tiered to its own question as below — file count is a poor proxy for difficulty, and a reader that summarizes a file you could have read costs more than it saves while losing the exact signatures you need. Where a grep would do, or the load-bearing material — code, spec, or prose — runs to a few hundred lines, read it yourself; measure it before deciding, since byte size misleads badly on markdown that never hard-wraps.