Drop Jargon
The user did not understand your last message. Explain the same content again, from
scratch, in language a smart person with no background in this specific topic would follow.
This is a re-explanation, not a summary and not an apology. The user still wants every
substantive point you made — they just want it in language that actually lands.
Rules
- Re-explain the previous assistant message. Not the whole conversation, not a new
topic. If that message covered five findings, the plain version covers all five.
- Give the context first, then the point. The user is not assumed to know the setup.
Before saying what you found, spend a sentence on what the thing is and why anyone
would look at it. A finding with no context is still incomprehensible, just shorter.
- No unexplained terms. Either use an everyday word, or use the technical word and
define it inline the first time in the same breath. If a term is not needed, cut it.
This includes field-specific vocabulary, metric names, file/function/variable names,
library names, acronyms, and units the user may not read fluently.
- Prefer concrete over abstract. "We slid one signal against the other in time to see
which shift lined up best" beats "we cross-correlated over lags".
- Say what it means for the user, not just what is true. Each point should land as
"so this is fine" / "so this is broken" / "so this is a decision you need to make".
- Keep the honesty exactly as it was. Simplifying language must not upgrade a maybe
into a yes. Keep every hedge, every "not yet verified", every caveat, and every number
the user's decision depends on. If you were uncertain before, be plainly uncertain now.
- Do not lose the numbers. Keep the ones that matter, but say what each one means and
whether it is good or bad. A number with no interpretation is jargon too.
- Short sentences. Short paragraphs. One idea per sentence. Break up walls of text.
- Do not be condescending. Simple language, not baby talk. No "as you may know", and
no over-apologising for the earlier message. One brief orienting line is enough.
- No word-swapping. Do not just trade a hard word for a slightly less hard word.
Restate the underlying idea in terms of what physically or practically happens.
Output shape
- Open with one sentence naming what the previous message was actually about.
- Then take the points in the same order as the original message, each with: what the thing
is, what was done or found, and what it means.
- If the original message ended with open questions, pending work, or a decision the user
has to make, restate that plainly at the end so nothing gets dropped.
- A little bolding or bulleting helps scanning, but plain prose is fine. Avoid dense
tables; if the original had a table, explain the rows that carry the point.
Do not
- Do not introduce new findings, new analysis, or new work in the re-explanation. If you
realise something new while rewriting, say so separately and mark it clearly as new.
- Do not quietly drop a caveat because it is awkward to phrase simply.
- Do not re-run tools or re-verify. The information is already in the previous message.
1---2name: drop-jargon3description: Re-explain your own immediately previous message in plain, simple language with no jargon, assuming the user does not already know the technical background. Use whenever the user says they did not understand, that you were too technical, that you were spitting jargon, asks you to explain it simpler or more clearly, or invokes /drop-jargon explicitly.4---56# Drop Jargon78The user did not understand your last message. Explain **the same content again**, from9scratch, in language a smart person with no background in this specific topic would follow.1011This is a re-explanation, not a summary and not an apology. The user still wants every12substantive point you made — they just want it in language that actually lands.1314## Rules15161. **Re-explain the previous assistant message.** Not the whole conversation, not a new17 topic. If that message covered five findings, the plain version covers all five.182. **Give the context first, then the point.** The user is not assumed to know the setup.19 Before saying what you found, spend a sentence on what the thing *is* and why anyone20 would look at it. A finding with no context is still incomprehensible, just shorter.213. **No unexplained terms.** Either use an everyday word, or use the technical word and22 define it inline the first time in the same breath. If a term is not needed, cut it.23 This includes field-specific vocabulary, metric names, file/function/variable names,24 library names, acronyms, and units the user may not read fluently.254. **Prefer concrete over abstract.** "We slid one signal against the other in time to see26 which shift lined up best" beats "we cross-correlated over lags".275. **Say what it means for the user**, not just what is true. Each point should land as28 "so this is fine" / "so this is broken" / "so this is a decision you need to make".296. **Keep the honesty exactly as it was.** Simplifying language must not upgrade a maybe30 into a yes. Keep every hedge, every "not yet verified", every caveat, and every number31 the user's decision depends on. If you were uncertain before, be plainly uncertain now.327. **Do not lose the numbers.** Keep the ones that matter, but say what each one means and33 whether it is good or bad. A number with no interpretation is jargon too.348. **Short sentences. Short paragraphs.** One idea per sentence. Break up walls of text.359. **Do not be condescending.** Simple language, not baby talk. No "as you may know", and36 no over-apologising for the earlier message. One brief orienting line is enough.3710. **No word-swapping.** Do not just trade a hard word for a slightly less hard word.38 Restate the underlying idea in terms of what physically or practically happens.3940## Output shape4142- Open with one sentence naming what the previous message was actually about.43- Then take the points in the same order as the original message, each with: what the thing44 is, what was done or found, and what it means.45- If the original message ended with open questions, pending work, or a decision the user46 has to make, restate that plainly at the end so nothing gets dropped.47- A little bolding or bulleting helps scanning, but plain prose is fine. Avoid dense48 tables; if the original had a table, explain the rows that carry the point.4950## Do not5152- Do not introduce new findings, new analysis, or new work in the re-explanation. If you53 realise something new while rewriting, say so separately and mark it clearly as new.54- Do not quietly drop a caveat because it is awkward to phrase simply.55- Do not re-run tools or re-verify. The information is already in the previous message.
Enrikkk