Discuss Change

Discuss Change

Escalate open decisions, agree on the implementation shape, then implement.

Task Tracking

Use update_plan to track each step, restating any remaining steps of a parent workflow alongside them:

• Capture the task
• Escalate product decisions
• Deep-dive discussion
• Confirm the shape
• Run $implement skill

Step 1: Capture the Task

Absorb the request without interrupting. Take the task from the user's request, or from conversation context when the task was already established. Restate the goal in one or two sentences and confirm.

Step 2: Escalate Product Decisions

Identify product or design decisions the request did not resolve. Escalate these via request_user_input before any code is written. Read the code the change would touch before judging whether a bullet matches. Skip when no bullet below matches the change.

Escalate when:

• The change requires choosing between user-facing behaviors the request did not specify (opt-in vs opt-out, strict vs lenient, sync vs async)
• The change assumes product requirements that were not stated
• Design trade-offs affect UX or product direction rather than technical implementation
• Multiple valid approaches exist and the choice is a matter of product preference, not technical merit
• The change would introduce a pattern not yet established in this codebase, or follow one sourced from outside it
• The change adds consistency or durability machinery (a lease, lock, queue, versioning scheme, or new persistent entity) that no stated requirement demands; carrying that machinery is itself a product decision

Do not escalate technical decisions the agent can make autonomously: which data structure, which existing pattern to follow, internal implementation approach. The boundary is product intent.

Confirm external constraints before escalating. When an option depends on a third-party API, service, or platform behaving a particular way, query documentation MCP tools (or web search as a fallback) and drop the option unless current documentation confirms that behavior.

Present each decision as a concise trade-off with options. Mark the strongest option "(Recommended)" and place it first.

Step 3: Deep-Dive Discussion

Interview the user about the implementation shape until you reach shared understanding. Use request_user_input, one question at a time. Cover whichever of these matter for the task. Do not present a rigid checklist. Skip when the request and the resolved decisions already name the files to touch, the existing code to build on, and the tests to write.

| Area | What to explore |

|---|---|

| Reuse vs new | Which existing code should the change build on? Which patterns should it deliberately not follow, and why? |

| File placement | Where do new files live? Which existing files are modified? |

| Data flow | How does data move through the change? Any new boundaries or contracts? |

| Edge cases | Partial failure, empty states, backward compatibility, concurrency |

| Tests | Which existing test patterns apply? Where do new tests live? |

| Scope cut | Anything to explicitly defer? |

Discussion Guidelines

• If a question can be answered by exploring the codebase, explore the codebase instead.
• Pair each question with a recommendation and the reasoning behind it, so the discussion stays collaborative.
• When the user says "you decide," make the call and explain why.
• Probe short answers before moving on.
• Stop once the shape is clear or the user signals readiness.

Step 4: Confirm the Shape

Output the agreed shape as text, short enough to read at a glance: what the change does, where it lands, the decisions resolved in Steps 2 and 3, how to tell it worked, and anything deliberately deferred. This text is the change description Step 5 implements, so keep it concrete enough to act on.

Then use request_user_input to offer two paths:

• Approve (Recommended) — the shape is settled.
• Revise — the user describes what to change. Apply the correction, then re-present the shape.

Step 5: Run $implement Skill

Run the $implement skill. The shape confirmed in Step 4 is the change it applies.

Then call update_plan to mark this step completed and continue with the next step of the active workflow.

Rules

• Confine Steps 1 through 4 to reading, discussion, and confirmation.
• When a gate in Steps 2 through 4 cannot reach the user, stop and state which decisions are unresolved instead of continuing to Step 5.
• If the work turns out to need writing down — unclear scope surfaces, the approach needs surveying first, or context risks being lost across sessions — stop and tell the user to run $turboplan for plan mode.