Plain English

What this is for

Users keep having to tell Claude to redo, rephrase, or "use plain English." The root cause usually isn't formatting. It's that the explanation is too long, buried in jargon, or explaining things they didn't need explained. They bounce off it and have to ask again.

This skill is the fast fix. The user fires it, you rewrite the thing so they actually read it.

What to do

Default target is the last thing you said. If the user points it somewhere else (an email, a doc, text they paste), rewrite that instead.

Rewrite it so:

• Lead with the answer. First line says the thing or what it means for them. No runway, no "so basically," no "great question."
• Cut the jargon. If a technical word is genuinely load-bearing, drop one plain phrase next to it in parentheses. Otherwise replace it. Assume the reader is smart but does not want to debug your internals.
• Shorter than you think. Most of these collapse to 2-4 sentences or a few bullets. If the original was ten lines, the rewrite is probably three.
• Drop what they can't act on. The caveats, the "it's worth noting," the background they didn't ask for. If it doesn't change what they do next, it goes.
• Keep it human. No filler, no corporate buzzwords, no "it's not X, it's Y" constructions, short sentences. If it reads like a LinkedIn post, it's wrong.

Then just give the clean version. Don't show the before, don't explain what you trimmed, don't apologize for the first one. They asked for the short version, so the response to "make it shorter" should not itself be long.

The instinct to carry forward

The bigger signal: if the user is invoking this, the last answer missed. Carry that into the rest of the session without being told. Default to shorter and plainer for the rest of the conversation. They can always ask for more depth. They rarely will.

Examples

Example 1, too technical

Before:

The cron routine fires via a scheduled trigger on a weekday cadence and the dedup logic keys off whether the thread already has a draft, so idempotency is preserved across overlapping invocations.

After:

It runs every weekday morning. It won't double-draft the same email because it checks whether a draft already exists first.

Example 2, too long

Before: (eight lines walking through every step of how a report gets built, the data sources, the fallback path, and three caveats)

After:

The report is built from the live numbers, with a screenshot-paste backup if the data source is down. Want me to run one now?

Example 3, they just don't want to read it

Before: (a dense paragraph weighing three options with tradeoffs)

After:

Go with option B. It's the least work and you can change it later. The other two lock you in.

Want the reasoning, or is that enough?