write-explainerlisted

## When to use this The subject is already understood well enough to explain - root cause from `/flow-debug`, a feature just built or reviewed, or a module/section of code someone needs oriented to - and the goal is understanding, not a change. Produces a citation-heavy walkthrough for a reader unfamiliar with the code. Use `/write-devnote` instead for a short peer-to-peer note on a completed change. Use `/flow-fix` or `/flow-plan` instead when the goal is to change code, not explain it. ## Procedure 1. Establish the subject and source. - `$ARGUMENTS` may name a debug report or bug ticket, a feature or module name, a file or directory path, or nothing at all - in which case default to whatever's already been discussed in this conversation. - If a file is named, read it in full. - If it's a bug/ticket or feature/module name with no artifact, check the conversation and project memory for matching context before asking the user to point at one. - If nothing can be found, stop and ask what to explain. 2. Do not trust any existing citations - from a debug report, prior conversation, or memory - at face value. Re-read every file mentioned in its current state before repeating a citation. Code moves; a prior artifact is a starting hypothesis, not a fact. 3. Identify the natural entry point for understanding the subject: for a bug, the user action or event that starts the chain; for a feature or module, where it's mounted, its main export, or the first file a reader wo