Back to Writing
· 4 min read ai-agents skills open-source workflow

My First Public Agent Skill: tldr

I’ve written before about what a skill is and how I make them. Up to now, I hadn’t actually published one.

Most of mine are wired into my own world — my task tracker, my servers, a client’s codebase. That makes them useful for me and pretty useless for everybody else. Also not something I should be tossing onto the internet.

This one is different. It’s public now:

npx skills add Chr15t1an/christians-claude-skills-public

What it does

A lot of the time, you ask an agent a question and it gives you 900 words back. Findings. Caveats. A table. Three options with trade-offs. Technically correct, maybe. Still not the thing you actually needed, which was: okay, so what are we doing?

tldr fixes that.

If I say “tldr,” I get the same shape back every time:

What we’re doing: the goal, in one sentence.
Where we’re at: done, in flight, or just found out.
What needs deciding: the open question as a this-or-that.
My call: which one, and why in a few words.

Ten lines max. Plain English. No unexplained acronyms. No filenames. No line numbers.

Here’s a real example, after a long dry-run report on a search migration:

What we’re doing: moving our logs to a newer search system before the old one stops getting updates.
Where we’re at: dry run done. Everything passed except one field whose type changes, which would break tag searches.
What needs deciding: fix that field first (safe, adds a day), or migrate now and fix tags after (faster, tag search broken for ~4M records meanwhile)?
My call: fix first. A day is cheap; broken search on live data isn’t.

That’s the report I wanted. The rest can stay one scroll up if I need it.


The part I’d steal even if you never install it

The obvious way to build this is: summarize, then recommend.

That sounds sensible. It was also a trap.

If you force a model to make a recommendation, you’re putting pressure on the exact part that’s most likely to bluff. Early on, this skill told me to investigate a process I thought might be burning money and escalate it to a teammate. Two queries later, I found out the process had stopped days earlier, and most of the spend was just real traffic. So both parts of the recommendation were wrong. It sounded convincing, though.

Now the skill has a rule that beats the format when it needs to: if the decision depends on a fact the agent could simply check, the recommendation becomes “run this check first” instead of a guess.

I’ve found that’s way more useful in practice. A confident wrong call costs me more than ten seconds of verification, because I might actually act on it.

That rule didn’t come from some grand prompt-design breakthrough. I got burned once, then wrote down what should’ve happened instead. That’s basically how I make all of these anyway.


Installing it

The skills CLI works with Claude Code, Cursor, Codex, Copilot, and around twenty other agents:

npx skills add Chr15t1an/christians-claude-skills-public

If you’d rather do it manually, you can clone the repo and drop the folder into ~/.claude/skills/.

It’s one markdown file. I’d read it first — here it is. Takes about a minute. No scripts, no network calls, nothing running on your machine.

That’s true of this skill. It is very much not true of every skill out there, and “it’s just markdown” stops feeling comforting the second a skill ships with a scripts/ folder.

Then just say “tldr” after something long.

One other thing worth knowing about the directory: there’s no submission form and no review queue. A skill shows up on skills.sh because someone installed it and the CLI reported it. That’s a low bar on purpose. Good for publishing. Also worth keeping in mind before you install something just because it has a big number next to it.