External Agent Skills Worth Trying, and the Filter We Run Them Through

Key Takeaways: A skill’s trigger line is context you pay for on every session (the body loads only when it fires), so the bar for installing one is higher than “it looks neat.” We run four checks: does it change behaviour you can measure, does it stay useful after the next modelA mathematical function trained on data that maps inputs to outputs. In ML, a model is the artifact produced after training — it encapsulates learned patterns and is used to make predictions or… upgrade, is its trigger narrow enough to stay out of the way, and what happens when it fires on the wrong task. Six entries passed for us — ponytail, Matt Pocock’s engineering set (four skills), eli5, humanizer, prompt-master, and Anthropic’s own skill-creator — and the reason each passed is more useful than the list itself.

We wrote earlier about why our team builds skills: a skill takes the promptThe input text provided to an LLM to guide its response. Prompt design — choosing words, structure, and examples — significantly affects output quality. Also referred to as the user message or query. your best developer retypes every morning out of their head and makes it reviewable. The other half of that story is the skills we did not write. New ones now land faster than anyone can evaluate them, at wildly varying quality, and our internal thread for collecting them has turned into a curation problem rather than a discovery problem.

This post is the current state of that curation — what we kept, and more importantly the filter.

A Skill Is Not Free

In Claude Code, an installed skill’s name and description are listed to the modelA mathematical function trained on data that maps inputs to outputs. In ML, a model is the artifact produced after training — it encapsulates learned patterns and is used to make predictions or… at session start so it can decide whether to load one; the body only loads when the skill is invoked. So the trigger line is a standing cost and the body is a variable one. Twenty skills is a small permanent tax before you have typed anything.

The bigger cost is the wrong skill firing. A skill that hijacks a task it was not written for is worse than no skill, because you now debug the agent’s instructions instead of your code. So, four questions:

1. Does it change behaviour you can observe? If you cannot tell from the output whether it was active, it is decoration.
2. Will it survive the next modelA mathematical function trained on data that maps inputs to outputs. In ML, a model is the artifact produced after training — it encapsulates learned patterns and is used to make predictions or…? Skills that encode taste and process age well. Skills that patch a specific modelA mathematical function trained on data that maps inputs to outputs. In ML, a model is the artifact produced after training — it encapsulates learned patterns and is used to make predictions or…’s weakness get obsolete fast — and then actively hurt, because the modelA mathematical function trained on data that maps inputs to outputs. In ML, a model is the artifact produced after training — it encapsulates learned patterns and is used to make predictions or… is now smarter than the instructions it is being handed.
3. Is the trigger narrow? A description that reads “use for all coding tasks” fires on far more than it should.
4. What is the blast radius when it misfires? A skill that rewrites prose is recoverable. A skill that rewrites migrations is not.

Point 2 is not hypothetical. It is the sharpest thing anyone said in our internal thread: as models improve, some skills become detrimental, because the modelA mathematical function trained on data that maps inputs to outputs. In ML, a model is the artifact produced after training — it encapsulates learned patterns and is used to make predictions or… would have done better without them. Any skill you install today is a bet that its advice ages slower than the modelA mathematical function trained on data that maps inputs to outputs. In ML, a model is the artifact produced after training — it encapsulates learned patterns and is used to make predictions or… improves.

The Ones We Kept

ponytail — a laziness ladder for over-building agents

ponytail makes the agent behave like a senior developer who has been paged at 3am. It runs a ladder before writing anything: does this need to exist, is it already in the codebase, does the stdlib do it, does the platform do it natively, is an installed dependency enough, can it be one line — and only then, write the minimum that works.

It is the highest-impact skill on this list for us, because over-building is the failure mode we hit most often with capable coding agents. Ask for a date picker and you get 400 lines instead of <input type="date">.

It also passes check 1 in an unusually honest way: the project publishes a benchmark, took public criticism that its original 80–94% figure was inflated by an unfair conversational baseline, and replaced it with a lower, defensible agentic measurement (−54% lines of code, −22% tokens, −27% time against the same agent with no skill, mean over 12 featureAn individual measurable property or characteristic of the data used as input to a model. Feature engineering — selecting, transforming, and creating features — is a critical step in the ML pipeline. tasks on Haiku 4.5, full write-up). A project that revises its own headline number downward is a project you can read the rest of.

For Odoo work the ladder maps almost directly onto our review checklist. Rung 2 is “already in this codebase” — which in Odoo means the field, the mixin or the OCA module already exists. Rung 4, “native platform featureAn individual measurable property or characteristic of the data used as input to a model. Feature engineering — selecting, transforming, and creating features — is a critical step in the ML pipeline.,” is the one that saves the most time: a _sql_constraints entry instead of a Python constrains, a related field instead of a compute, a server action instead of a new module.

Matt Pocock’s engineering skills — process, not tricks

Matt Pocock’s set is the clearest example of skills that encode process rather than patch a modelA mathematical function trained on data that maps inputs to outputs. In ML, a model is the artifact produced after training — it encapsulates learned patterns and is used to make predictions or… weakness. Four of them earn their place:

• diagnosing-bugs — a phased diagnosis loop that forces reproduction before hypothesis. It is the antidote to the agent’s instinct to patch the first plausible line.
• tdd — the red-green loop, plus the part everyone skips: what makes a test worth keeping.
• code-review — reviews a diff on two axes in parallel sub-agents: does it follow the repo’s documented standards, and does it match what the originating issue actually asked for. The second axis catches the failure that matters most in ticket-driven work — code that is clean and solves a different problem than the one specified.
• grilling — interviews you about a plan, mapping decisions as a tree and asking the whole frontier of answerable questions in one round with recommendations attached.

grilling is the one to try first if you write functional specs. Handing it a vague ticket produces a numbered list of the decisions nobody made yet, which is exactly the work that otherwise surfaces halfway through implementation.

eli5 — for the conversation after the implementation

eli5 explains a topic at a level a non-specialist can act on, and outputs it as a picture explainer — big visuals, few words. That sounds like a novelty until you spend a week explaining a scheduled action’s retry semantics to a client’s finance lead.

The genuine use is asymmetric-knowledge conversations: developer to functional consultant, consultant to client, anyone to a steering committee. Ask for the eli5 version of the thing you just built, keep the framing and the diagram, drop the cartoon.

humanizer — for anything a customer reads

humanizer strips the tells of AI-generated prose: rule-of-three lists, “it’s not just X, it’s Y” constructions, inflated significance, em dash abuse. It is built from Wikipedia’s “Signs of AI writing” guide, a community-maintained catalogue of these patterns with examples for each.

We run it on outward-facing text — release notes, proposals, this blog. Never on documentation where the flattened phrasing loses precision.

prompt-master — for the tools that are not Claude

prompt-master generates a production-ready promptThe input text provided to an LLM to guide its response. Prompt design — choosing words, structure, and examples — significantly affects output quality. Also referred to as the user message or query. for a specific target tool, and refuses to output one until it knows which tool that is.

Its real value is the negative advice. It explicitly downranks the meta-reasoning frameworks that get recommended in promptThe input text provided to an LLM to guide its response. Prompt design — choosing words, structure, and examples — significantly affects output quality. Also referred to as the user message or query.-engineering threads — Tree of Thought, Graph of Thought, simulated multi-persona routing — on the grounds that simulating parallel reasoning inside a single forward pass raises fabrication risk without adding capability. That matches our own experience, which is a team observation rather than a measurement: a plain role assignment with a few examples and explicit verification criteria has beaten the elaborate framework in every case we have compared side by side.

Where we use it: the LLMA neural network trained on vast amounts of text data to understand and generate human language. LLMs use the Transformer architecture and can perform a wide range of tasks — summarization,… nodes inside n8n workflows, image and video generation, and anywhere a promptThe input text provided to an LLM to guide its response. Prompt design — choosing words, structure, and examples — significantly affects output quality. Also referred to as the user message or query. has to be pasted into a tool that has no skill system of its own.

skill-creator — the one that tests the others

Anthropic’s own skill-creator now ships an eval mode and a benchmark mode with dedicated executor, grader, comparator and analyzer agents. That turns the first question in our filter from a guess into a measurement: run the task with the skill and without it, on your repo, and compare. Point it at a task the skill was not written for and you get a read on question four as well — a skill that hijacks unrelated work shows up as a worse result than the no-skill run.

If you install one thing from this post, install this one — not because it writes skills, but because it is how you find out whether the others are still helping.

On terseness skills

caveman (compress the agent’s prose) is fun and does cut visible output. But ponytail’s own benchmark used it as a control arm and found it raised total tokens by 7% and cost by 3% — shorter answers, no less thinking. Worth knowing before you install one to save money. Install it because you prefer reading dense output, not because you expect a smaller bill.

Also on the Shortlist

Four more that came up in the same internal thread and are worth a look, with the caveat attached:

• code-simplifier (in Anthropic’s official plugin set) — a sub-agent that passes over freshly written code and simplifies it without changing behaviour. It overlaps heavily with ponytail: one prevents the over-build, the other cleans up after it. Running both is redundant; pick the preventive one first.
• karpathy-guidelines — behavioural rules distilled from Andrej Karpathy’s list of LLMA neural network trained on vast amounts of text data to understand and generate human language. LLMs use the Transformer architecture and can perform a wide range of tasks — summarization,… coding pitfalls: state assumptions instead of guessing, make surgical changes, define what “done” means before starting. It says up front that it trades speed for caution, which is the right disclosure to make and rare to see.
• skill-creator variants — several community forks exist alongside Anthropic’s. Ours is the upstream one, for the eval mode; if a fork’s only edge is a nicer template, that is not a reason to switch.
• Bundle repos (everything-claude-code and friends) — worth mining for individual skills, not worth installing whole, for the reason in the next section.

What We Skipped

Two categories, consistently:

Mega-bundles. Repositories that install dozens of skills in one go. The context tax is real, the quality inside a bundle is uneven, and when behaviour changes you cannot tell which of them did it. Take the two you want; leave the rest.

Skills that duplicate a tool. If a deterministic script does the job, the script is better: same result every run, no tokens, testable in CI. A skill earns its place when it encodes judgement — which tool to reach for, in what order, and how to verify the result.

Our own /utils:pdf is deliberately built the second way: the conversion is a plain Python script, and the skill is the decision tree around it. Which raises the obvious question about a new arrival like Firecrawl’s anydoc — is the underlying tool now good enough that the skill should just call it instead? We benchmarked all three converters head to head, and the answer is a genuine split: anydoc vs markitdown vs /utils:pdf.

How to Try These Without Regret

Install one at a time. Run a task you have done before, with and without it. Keep it only if you can name the difference in the output.

Then re-check every few months, because the second question in the filter is the one that quietly changes its answer: the skill did not get worse, the modelA mathematical function trained on data that maps inputs to outputs. In ML, a model is the artifact produced after training — it encapsulates learned patterns and is used to make predictions or… got better. The install list you curated in spring is not automatically the right list in autumn.