waitwhat · diff
git:20260925.8d07e01 to git:20261031.530e852
8 added, 7 removed. Audit A to A.
---
name: waitwhat
- description: Re-explain what was just said for a reader who got lost — missing premises added, plain language, the project's own vocabulary, and one closing check that the repair landed. User-invoked only; only the reader knows when understanding broke.
+ description: Explain what was just said, and why it is being done this way, in plain everyday words a newcomer can follow — the problem it solves, what goes wrong without it, what was given up. User-invoked only; only the reader knows when understanding broke.
disable-model-invocation: true
argument-hint: "optional: the part that lost you"
---
# Wait, What?
- The user typing this means one thing: **your map of what they understood was wrong.** An explanation is a checkpoint like any other, and this one failed — the repair is a corrected map, not a louder pitch, and not a telegram either: an agent told "you lost me" backs up and supplies the ground.
+ The user typing this means **your picture of what they understood was wrong.** The repair is a clearer explanation, not a louder pitch and not a shorter one: back up and supply the ground you had and they didn't.
- - **Add the missing premises** — the context that makes the conclusion parseable, which you had loaded and they didn't. Behavior level, not implementation level.
- - **Speak the project's language** — terms from `CONTEXT.md` where the project keeps one, never shorthand this conversation invented. Leaning on a concept no shared vocabulary covers? Define it now, and if it is a project concept rather than a general one, record it through the `domain-glossary` skill, which owns what the glossary admits and its shape. An explanation that coins a term and doesn't write it down has to coin it again next time.
- - **Shorter and clearer, not shorter and blunter.** Deleting words isn't the job; supplying the ground is.
- - **End on evidence, not delivery.** "Explained" is a claim, and its evidence is the reflection: close with the one question whose answer shows whether the map is repaired. A wrong answer is a finding about the explanation, not the reader.
+ The concept: **explain the why in plain words, as to someone who has never written code.** Assume that reader unless they have shown otherwise, because asking for "simpler" every time is the cost this command exists to remove.
- A second `/waitwhat` on the same topic is a finding: the gap isn't the wording, it's a missing shared concept. Name it, record it through the `domain-glossary` skill when it is the project's own, then explain with it — the repair feeds the project's memory, so the next first draft lands on its own.
+ - **Say why, not just what.** What problem this solves, what would go wrong without it, and what was given up for it, because a reason the user can repeat is what lets them agree or overrule.
+ - **Everyday words first.** One analogy and one concrete example from their own project carry more than a definition. A technical or project term, where one is needed, is said in plain words the first time it appears.
+ - **No closing question.** End when the explanation ends, because a quiz after every answer is a prompt the user waves off; if it still didn't land, they will type `/waitwhat` again.
+
+ A second `/waitwhat` on the same thing means a shared concept is missing, not a better wording. Name it and explain with it; where it is the project's own, record it through the `domain-glossary` skill, so the next explanation starts from it.