tldr

name	tldr
description	Use when asked to explain or summarize a technical concept quickly — "tldr", "what is", "quick overview", "how does X work" — for concepts, not for deep tutorials, debugging, or code-writing tasks

tldr

Explain a technical concept short, easy, still technical — like a human dev in a hallway, not a form. Keep the real terms; keep it readable; don't lecture.

The output IS 2-3 short sentences of natural prose — not an essay, not a labeled card. No "Keywords:" / "Flow:" / "Analogy:" labels. The terms are bolded inline so they pop without a list.

What to explain (the target)

• With an argument (/tldr WebSocket, "tldr mutex"): explain that concept.
• No argument, or "above" / "this" / "that" (/tldr, /tldr above): the target is the immediately preceding technical content in the chat — the last assistant message, or the concept/term it just explained. Do NOT ask the user for an argument — it's obvious they want the thing above tldr'd. Read up the thread, find the last concept/explanation/term, and tldr it. If genuinely nothing technical preceded, say so in one short line — still don't prompt for arguments.

The contract

Every tldr answer reads like this — natural prose, ≤40 words:

**<Concept>** — <plain-verb definition + a familiar contrast>, with <terms bolded>. <If a real lifecycle: one sentence with → arrows. If none: skip.>

That's the whole answer. No gotchas, watch-outs, variants, failure-modes, "why it exists", and no trailing prose line tying it to the user's code. Those are scope creep — refuse them.

Rules

• Definition sentence (always, the comprehension layer): ≤1 line, plain verbs + a familiar anchor. Name what it does + contrast against something the reader already knows (HTTP for WebSocket, "one-at-a-time" for mutex, the literal word for guardrails). This is the ONLY comprehension layer — no rescue prose. If it uses a word as hard as the term itself, the reader learns nothing.
  • ❌ Guardrails — safety invariants that keep an agent bounded (jargon defines jargon)
  • ✅ **Guardrails** — hard caps that stop an AI agent running off-track, unlike a plain prompt where it does whatever it wants.
• Terms (always, the recall layer): the verbatim jargon you'd grep in docs/errors, bolded inline in the prose — not a labeled list, not paraphrased. This is where the technical words live; the Definition stays plain.
  • ❌ switching response (loses the search term 101 Switching Protocols)
• Flow (conditional, the behavior layer): weave it as one sentence with → arrows only if the concept has a real lifecycle (handshake, acquire→release, OAuth). Absent for flat concepts (idempotent, pure function, array) — no lifecycle, no flow sentence. Present iff a sequence exists, NOT iff the concept is hard.
• Analogy (opt-in only): add ONLY when the user asks ("give me an analogy", "ELI5") OR the concept is pure abstraction with no concrete handle. Never by default. One clause, woven in — never replaces the technical layer.

Worked example (copy this feel — natural, not labeled)

WebSocket keeps one TCP conn open so both sides push anytime, unlike HTTP's request-then-response. It starts as an HTTP Upgrade → server replies 101 Switching Protocols → both sides trade frames (ping/pong keepalive) until a close frame.

No "Keywords:" line. No "Flow:" line. Just prose with the terms bolded and the flow as arrows.

HTML visual mode (same content, rendered)

Same definition + terms + flow, shown visually instead of text. Browser = the rendering stdlib; no new dependency.

• Auto-trigger HTML iff the concept has a branching structure — ≥3 branches / decision points / parallel paths / a state machine with loops (OAuth redirect paths, a decision tree, CI fan-out). Linear A → B → C flows read fine as prose — do NOT auto-HTML those.
• Else on-demand — "show me" / "draw it" / "visual". Flat or linear concepts → text unless asked.
• One self-contained .html in the OS temp dir, all CSS inline, no external deps, no framework. Render the same definition + terms + flow — terms as styled chips, flow as a diagram. Don't invent new sections.

Rationalizations — refuse these

Rationalization	Reality
"User said technical → they want thorough"	Technical = verbatim terms, not more depth. tl;dr wins.
"This concept needs watch-outs to be useful"	Prose = the contract above. Watch-outs ≠ tldr. Refuse the section.
"A short analogy up front helps first"	Analogy is opt-in. Lead with the definition.
"Label the terms 'Keywords:' for clarity"	Labels read robotic. Bold them inline in prose instead.
"Define guardrail with 'invariants'/'bounded'"	Definition is the comprehension layer. Jargon defining jargon teaches nothing. Use plain verbs + a familiar anchor.
"One closing line tying it to their code helps"	Trailing prose = scope creep. The answer IS the 2-3 sentences.
"I need an argument to proceed — let me ask"	No-arg / "above" means tldr the preceding chat content. Never prompt for args.

Red flags — STOP, rewrite

• More than ~3 sentences, or over ~40 words on a simple concept
• "Keywords:" / "Flow:" / "Analogy:" labels (robotic — weave as prose)
• Analogy appearing without being asked
• Terms paraphrased instead of verbatim
• Definition uses a word as hard as the term itself (jargon defines jargon)
• Gotchas / watch-outs / variants / failure-modes sections
• Any prose line after the answer tying it to the user's code
• Asking the user for an argument when invoked with none or with "above"

When NOT to use this skill

"explain deeply", "full tutorial", "how do I implement X", debugging, code review, writing code. This is for quick-concept recall, not depth or task execution.

Answer in the language of the question. Terms stay verbatim English regardless.