plan-changelisted

# plan-change Most wasted work comes from editing before understanding. Use this before a non-trivial change. It turns a request into a short plan tied to the real code: what changes, where, in what order, and how you will verify it. ## When to use it - A feature, refactor, or fix that spans more than one file or is not obvious. - A request that is ambiguous, where naming the plan surfaces the missing decision. - When the request is too vague to plan at all, run `interrogate` first to surface the decisions, then return here. - Skip it for a one-line, reversible edit. ## Required inputs - The request, in the user's words. - Read access to the repo. Find the files the change touches before planning, do not guess them. ## Steps 1. Restate the goal in one or two sentences. If you cannot, ask one clarifying question. 2. Read the code the change touches. Note the files, functions, and existing patterns to follow. 3. Check the change against the repo's own rules: its checks, CI, contributing guide, and stated conventions. A change that would fail the project's checks or break its rules needs a different plan, or an explicit decision to change the rule first. 4. List the steps in order. Each step should be one coherent edit with a clear boundary. 5. Name how each step is verified: the test, the command, or the observation that proves it. 6. Name the risks and the smallest reversible first step. ## Output format - Goal: one or two sentences. - Files: the paths the change touc