tldr

name

tldr

description

Compress the previous assistant response into a single TL;DR line, then propose exactly three terse next-step labels (≤8 words each, slash commands welcome) the user can take. Use whenever the user types `/tldr`, `/recap`, says "tldr", "tl;dr", "summarize and suggest next steps", "recap that", "what should I do next", "give me the gist", or otherwise asks for a quick summary of what was just said plus suggestions for what to do next. Trigger even when the user phrases it casually ("ok so what now?", "give me the short version + next steps") — this skill exists exactly for those moments where a long answer needs distilling and a clear handoff to action.

tldr

Distill the previous assistant response into one line, then offer three concrete, takeable actions.

Why this exists

Long assistant responses are useful while you're reading them, but expensive to re-read later or to act on under time pressure. A reader who has already followed the thread doesn't need the full thing again — they need (a) a one-line anchor that confirms what was decided/explained and (b) a short, ordered menu of moves they can make right now. That's the whole job.

Scope

By default, summarize only the previous assistant message. If that message is short or self-referential ("yes, exactly", "see above") and a one-line summary would be uninformative on its own, look back at the most recent assistant message that actually carried content and summarize that instead — but stay anchored to the current state of the conversation. Don't recap the whole session unless the user asks for it explicitly (e.g. "recap everything", "/recap all").

Output format

Always use this exact shape — nothing before, nothing after:

**TL;DR:** <one sentence, ≤140 characters, no preamble>

1. <next step>
2. <next step>
3. <next step>

Rules that make this shape work:

• The TL;DR is one sentence. Not two. If you need a comma or semicolon, fine — but no second sentence and no trailing parenthetical that's secretly another sentence.
• No "In summary,", "To recap,", "Basically," or any other warm-up. Start with the substance.
• Each next step is a short, terse label — ideally 1–6 words. Think menu items, slash commands, or chip labels: Run tests, Apply fix, /ui-review, Pick option B, Open PR. Not full sentences with file paths, rationale, or how-to detail. The user reading the recap doesn't need instructions — they already followed the conversation. They need a short menu of moves they can take. If a step needs explaining beyond the label, the label is wrong; pick a sharper one.
• Order the steps by what makes sense to do first, not by importance. If step 2 only makes sense after step 1, that ordering is doing real work.
• Exactly three steps. Not four "in case", not two "to keep it tight". Three is the contract — it's enough to give a sense of options without becoming a checklist the user has to triage.
• Use slash commands when one fits. If the next move maps cleanly to an installed skill or command (/commit, /ui-review, /pr-feedback), prefer that over prose. It tells the user exactly what to type.

How to pick good next steps

The previous response usually contains the raw material. Pull from:

• Loose ends the response left open — "we still need to verify X", "you might want to test Y" → those are next steps.
• The natural follow-up to whatever was just delivered — if the response explained a bug, step 1 is usually "fix it" with the specific change. If the response proposed options, step 1 is "pick one" framed as a decision.
• Adjacent moves the user hasn't thought of yet — one of the three slots is well spent on something the response didn't explicitly mention but that a careful reader would do anyway (write a test, update the docs, check the related call site).

If the previous response was itself a question to the user, the next steps should be ways to answer it or things to gather before answering.

Avoid generic filler like "review the changes", "let me know if you have questions", or "consider edge cases" — these are not actions, they're throat-clearing.

Examples

Example 1 — after a bug-fix explanation:

**TL;DR:** Missing `await` on `db.users.find()` in `auth/login.ts:34` — added it, route works.

1. Run tests
2. Grep for other unawaited calls
3. Add lint rule

Example 2 — after presenting two architectural options:

**TL;DR:** Redis (faster, more infra) vs per-request memo (simpler, less win) — depends on whether you need cross-request hits.

1. Pick approach
2. Prototype on hottest endpoint
3. Benchmark

Example 3 — after a long research dump on a library:

**TL;DR:** TanStack Query covers caching, retries, and stale-while-revalidate out of the box; only the auth-refresh interceptor stays custom.

1. Install + provider setup
2. Migrate one read-heavy hook
3. Port mutations

Example 4 — when a slash command fits the next move:

**TL;DR:** Component looks ready — passes a11y check and matches the design system.

1. /ui-review
2. /commit
3. /pr-feedback

When to bend the rules

• Last assistant message was already a one-liner. Don't recap a recap. Tell the user "the previous response was already brief — here are next steps:" and skip the TL;DR line.
• There's nothing meaningful to do next. Rare, but it happens (e.g. the previous response was "you're all set, the deploy succeeded"). In that case, give the TL;DR and explicitly say next steps are optional, then offer three optional moves (verify, document, monitor).
• User asks for more or fewer steps. Honor it. Three is the default, not a religion.