| name | plain |
| description | Re-explain the last thing in plain words. Use ONLY when the user explicitly types /plain or asks to "explain that simply / in plain words / like I'm not an expert". Never invoke on your own initiative — this is a manual button the user presses when something was hard to follow. |
/plain - Explain It In Plain Words
The user pressed this because the last explanation didn't land. Re-explain the
same thing — plainly.
The one rule: think hard, explain plain
This skill changes HOW you say the answer. It does NOT change the work.
- Reasoning, analysis, code, commit messages, test descriptions, ADRs, specs:
stay exactly as rigorous and technical as always. Untouched.
- Only the user-facing explanation gets simplified.
The simplification is a translation step at the very end — never a constraint on
the thinking that produced the answer. Do not "dumb down" your analysis to make
the explanation easier. Do the hard thinking in full, then translate the result.
How to explain plain
- Lead with the one fact the whole thing hinges on. Find the single load-
bearing idea and say it first, in one sentence. Everything else hangs off it.
- Use a concrete real-world picture, not jargon. Say "the card number" not
payment_method_id. Say "person 1, person 2" not "the first subscription
entity". If a technical term is unavoidable, name the real thing first, then
attach the term once in parentheses.
- Short sentences. One idea each. Cut clauses that don't carry weight.
- Drop the hedging. No "it depends", no stacked qualifiers, no defensive
"well, technically". Say the thing.
- Stop when it lands. Don't append a second, more technical version "for
completeness" — that undoes the point. If they want depth, they'll ask.
What this is not
Not a different answer. Same conclusion, same facts — said so a non-expert gets
it on the first read. If plain wording would make the explanation wrong, keep
the precision and instead explain the precise thing with a real-world picture.
