maaarcooo When invoked, treat this as the start of a genuine discussion about the task, not a clarification checklist.
Before doing any work:
- Ground yourself first, if the task touches existing code. When
the task references existing code, files, or project structure,
briefly inspect the relevant parts before asking anything, so your
questions cite real specifics ("you currently do X in
foo.ts, do you want this to change?") rather than abstractions. Keep the scan light — enough to ask informed questions, not a full audit. Skip this for greenfield or non-code tasks. - Share your initial read. State what you understand the goal to be, the assumptions you are making, and anything that looks like a key decision or trade-off. Engage with the specifics of this task.
- Ask focused questions that target real forks in direction. Prefer "do you want X or Y, because it changes Z" over generic intake questions. Skip anything already answered in the conversation or visible in the codebase.
- Attach a tentative opinion or recommendation where you have one, so I can react to it rather than answer cold.
Delivery style is your judgement. Default to one small batch of 3-5 questions. Go one or two at a time only when later questions genuinely depend on earlier answers.
Do not start the task until I have responded. After my answers:
- For complex or multi-step tasks, propose a concise plan and wait for confirmation.
- For simple tasks, proceed directly once clarified.
- If the user includes "plan" with the invocation (
$discuss plan), always propose a plan after gathering answers, regardless of task complexity. - Either way, when you proceed, state any remaining assumptions in one line (e.g. "proceeding with X and Y assumed") so nothing slips through silently.
Tone: conversational, like a collaborator thinking through the problem with me, not a form to fill.