/discuss-change

name: discuss-change
description: "Align on the shape of a change through an interview, then implement it. Use when the user asks to \"discuss this change\", \"ask me questions first\", or \"agree on the approach before coding\"."

Discuss Change

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

Task Tracking

Use `TaskCreate` to create a task for each step:

1. Capture the task 2. Escalate product decisions 3. Deep-dive discussion 4. Confirm the shape 5. Act on the user's reply 6. 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 `AskUserQuestion` 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
• A constraint on the solution that someone other than the user set and the user has not confirmed, such as a request relayed from another session or a consuming project's stated needs, rules out an option that is sounder on technical merit; offer that option and name the constraint it relaxes

**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 WebSearch as a fallback) and drop the option unless current documentation confirms that behavior.

**Look up a named precedent before escalating.** When the request, or a document it points to, names a precedent the change is meant to follow, such as an existing product, a protocol, or a standard, look up how it behaves on the points the change touches, and frame options against what the lookup found. Mark as unverified only a claim about it that the lookup could not settle.

**Observe existing surfaces before escalating.** When an option concerns how an existing surface looks, observe it as it currently renders, by running the app from the current code, or from a screenshot requested from the user, and drop any option its rendered state rules out.

**Read the code an option's benefit lands in before escalating.** When an option is justified by what it lets code outside the change do, such as the caller of an interface or the consumer of an output, or by what it does for data already stored, read that code, or every path that has written that data, and follow the benefit through what you read. Confirm the code or data needs what the option provides and does not already get it another way. Drop a benefit the reading does not bear out. **Apply the UX lens before escalating.** When a decision concerns what the software does for the person using it, a default or a control included, run the `/user-experience` skill on it first, and state each option as the behavior that person gets and the goal it serves. Leave the mechanism behind each behavior to Step 3.

Output what is at stake as text first, even when the reading it came from is fresh in this conversation. When the decision turns on a failure or misuse scenario, that means the invariant the change would protect and what makes that scenario reachable given the existing guards. Then use `AskUserQuestion` to present the decision as a concise trade-off with options. Keep each option's description to the decision being asked and its trade-off. When an option would also commit to a design choice the question does not ask about, ask that choice on its own or state it in the shape Step 4 confirms. Mark the strongest option "(Recommended)" and place it first. Treat the work of departing from the codebase's existing structure as a cost to state beside the option that incurs it, with no bearing on which option is strongest.

Offer a **Get a second opinion** option whenever the decision is costly to reverse (it establishes a pattern others will follow, defines an interface, commits to a data shape, or imports a pattern the codebase has not used), and whenever no option earns "(Recommended)" with conviction. It runs the `/consult-codex` skill for what each option commits to, what reversing it costs, and what the prevailing convention is. Hold the concrete options to three so the question stays within the four-option limit. Then resolve the decision with that answer in hand, re-asking when the choice stays the user's.

Step 3: Deep-Dive Discussion

Interview the user about the implementation shape until you reach shared understanding. Use `AskUserQuestion` in rounds: put every question whose answer depends on nothing still open into one call, up to its four-question limit, and hold a question that depends on an open answer for a later round. 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 to