Discuss Change

Discussion Guidelines

• If a question can be answered by exploring the codebase, explore the codebase instead.
• When a question 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, before framing options. Drop any option its rendered state rules out.
• When a question concerns how to guard against a state, find where that state is constructed before framing options. When a single place constructs it, offer making the state impossible to construct there alongside the shapes that detect it downstream or change its consumers.
• 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, read that code and follow the benefit through it before framing options. Confirm the code needs what the option provides and does not already get it another way. Drop a benefit the reading does not bear out.
• When a question defines a boundary, contract, or data shape, add a Get a second opinion option and hold the concrete options to two so the question stays within the three-option limit. It runs the $consult-claude skill for the soundest answer on technical merit alone, independent of the task's original scope; on a question of product intent, run it for what each answer commits to and what reversing it costs. Then resolve the question with that answer in hand, re-asking when the choice stays the user's.
• When a question turns on how a surface looks or how an interaction behaves, and an answer in prose would leave the user guessing, add a Prototype it first option and hold the concrete options to two so the question stays within the three-option limit. It runs the $prototype skill on that unknown, then asks the question again with the prototype in hand.
• When a question concerns what the software does for the person using it, a default or a control included, run the $user-experience skill on it before framing options, and state each option as the behavior that person gets and the goal it serves.
• 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.
• Before closing the discussion, hold each decision resolved in Step 2 or earlier in this step against the shape as it now stands: re-read what its chosen option was described as doing. Where a description no longer holds, name the claim that fails and re-ask that decision.
• 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. Label any consistency or durability machinery the shape adds (a lease, lock, queue, versioning scheme, or new persistent entity) as machinery. For each, name the stated requirement or user decision that demands it, or say that none does, and state what dropping it would give up. For each deferred item, including an addition the user declined earlier, state the user story it serves, or what it simplifies when it is a technical item, and recommend noting it for later or dropping it. Recommend noting only an item that serves a goal the person using the software actually has or that simplifies existing code. This text is the change description Step 6 implements, so keep it concrete enough to act on.

Close with how to reply: approve the shape as settled, or describe what to change. When the shape defers items, add that an approval notes the ones recommended for noting and drops the rest, and can flip any of them. When an unknown that only a built artifact settles is still open, also offer prototyping it first, and recommend that over approving, since a surface or interaction pattern that is still unproven cannot be judged from the shape description.

Then end the turn.

Step 5: Act on the User's Reply

A goal continuation turn that carries no reply from the user is not an approval: end it without calling any tool and without advancing.

• Revise — apply the correction the user describes. Then re-present the shape, close with Step 4's reply guidance, and end the turn again.
• Prototype first — run the $prototype skill, then fold what it settled into the shape. Then re-present the shape, close with Step 4's reply guidance, and end the turn again.
• Approve — the shape is settled, along with any deferred item the approval flips. Run the $note-improvement skill once for each deferred item settled as noted. Once every such item is noted, continue to Step 6.

Step 6: Run $implement Skill

Run the $implement skill. The shape the user approved 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 5 to reading, discussion, confirmation, any prototype those steps called for, and the backlog entries Step 5 notes.
• 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.