Some of the people you write to will read the TL;DR, decide what to do, and never open the rest. That is not a failure of attention. You labelled a passage the short version and they took you at your word.
So the question to ask of it is not "is this a fair summary of my message". It is "does someone who reads only this end up doing the right thing".
State the conclusion, not the topic
Most TL;DRs name a subject and stop. That is a folder label, not a summary.
Before: An update on the vendor review, plus some thoughts on next steps.
After: We should switch to the second vendor. Their quote is higher, but they are the only one who can hit the March deadline, and I need your sign-off this week to hold the price.
The first version was writable before any of the work happened. That is the test — a TL;DR should contain a sentence that would have been wrong a week ago. If yours survived the investigation unchanged, it is a subject line in a summary's clothes.
The second tell is disagreement. Nobody can push back on "following up on the hiring conversation", so it says nothing; "I want to make the offer to the second candidate at the top of the band, and I need budget confirmation by Thursday" is arguable in three places.
Write it last, read it first
Written before the body, a TL;DR is an outline — a promise about a message that does not exist yet. The body then goes where the thinking actually leads, the two quietly disagree, and the reader trusts the summary and acts on a version you abandoned in paragraph three.
Written last, it audits the body for free. If summarising forces you to notice you never actually decided anything, better to find that now than in the reply asking what you wanted.
It has to survive being read alone
Three rules do most of the work.
No shorthand that resolves only against the body. No "the migration", no "her", no "the new plan", unless the TL;DR has said which one. A pronoun whose antecedent sits in paragraph four is a broken link — the discipline you owe a cold reader, with no surrounding text to rescue you.
Include the load-bearing specifics. The number, the date, the name. If the reader would act differently knowing the number, it belongs up here rather than filed safely in the detail.
No sentence that inverts once you read on. "We are on track" above a body explaining a two-week slip is not a summary. It is a lie with a footnote.
Then run the test almost nobody runs. Show one person the TL;DR alone and ask what they would do next — not "is this clear", which only gets you politeness. If the answer is wrong, or is "it depends", it failed at the only job it has.
Before: The pilot went well, though a couple of issues came up worth discussing.
After: The pilot worked and I want to roll it out in September, with one team held back — two accounts stopped syncing and I have not found the cause.
A teaser is a failed TL;DR
"Some surprising numbers came out of the review" is a hook. Withholding the conclusion to keep someone reading is borrowed from formats that must win an audience they do not have — and you already have yours. Between colleagues the move reads as a game or a hedge, and the message gets set aside for later, which is where most of them quietly die.
Two sentences, or the thinking is not finished
The conclusion, then what follows from it. The rule earns its keep when you fail it, because the failure is diagnostic. Three usual causes.
You have not decided yet. That still fits — "I cannot choose between the two suppliers without knowing whether we can move the launch, and you are the only person who knows that" is finished thinking about an unfinished decision. What does not fit is dressing indecision up as a survey of considerations.
The message carries two decisions. Send two messages. A reader acts on one conclusion at a time, and bundling doubles the odds that half never gets answered.
It is genuinely a list of unrelated updates. Say so plainly rather than dressing a list as a verdict — and accept that a bundle gets skimmed.
Its role inside a briefing
In a RelayLink briefing the TL;DR is a required field, sitting alongside the ask, the context brief, and the assumptions. Two mechanics make "safe to act on alone" a description rather than advice.
The notification email that reaches the recipient's mailbox carries your note, the thread topic, the TL;DR, and a link; everything else sits behind that link. An assistant checking its user's inbox receives envelopes — sender, topic, note, TL;DR — and not the full briefing, which takes a second call to fetch. Triage runs on your two sentences at both ends.
The field is capped at 400 characters server-side and the drafting guidance asks for at most fifty words; two sentences fits inside both.
One honest limit. The TL;DR carries no provenance label — your note gets one, assumptions carry a tag of their own, and the TL;DR arrives bare. Whatever it says reads as your position, whether you wrote it or approved a draft of it, and since nothing recalls a sent package, review is the only pass you get.
Take the last message you sent that got a slow, vague reply and rewrite its opening as two sentences that state the conclusion. If that is hard, the reply was slow for a reason — the same discipline applies one field up, in the subject line. If you would rather have the first draft assembled from the session where you did the thinking, connect your assistant — deciding whether those two sentences are true stays with you.