stdd-start-changelisted

<!-- generated by stdd plugin build v0.9.2 — do not edit --> # Start change Start Change is the action boundary. Invoke it only after explicit intent to persist a work artifact or modify the repository. Read-only factual diagnosis routes directly to `stdd-investigation`; opinions, future behavior, and hypothetical implementation approaches route directly to `stdd-brainstorming`. Neither needs a task. A hypothetical plan shown only in chat remains Brainstorming. Run `stdd policy show` before asking anything: it may already answer which agent owns this area, which standing permission covers the work, and what this repository treats as routine rather than a decision. Read it through the command, never as raw markdown — the command is where the rules are applied. Open one task boundary before carrying action state across prompts: ```bash stdd task start "<short change name>" stdd status --local ``` If another task is active, do not reset it silently. Finish it, continue it, or ask the user which task owns the checkout. Then classify the chosen action and route to the smallest applicable workflow: - behavior or scope is still uncertain → invoke `stdd-brainstorming` within the active change boundary; - agreed multi-step behavior → invoke `stdd-planning`; - known defect without a diagnosis → invoke `stdd-debugging`; - small agreed change → invoke `stdd-implement` directly. Read `.stdd/method.md` and the canonical docs governing the touched behavior. The classification is