10 Agent Skills That Actually Changed Claude's Output
We ran 52 real Claude sessions, two live CLI checks, and a seven-way design shootout to find 10 agent skills that materially changed output—and removed popular skills that did not.
We cloned the source repositories, ran the same prompt through fresh claude -p sessions with and without each skill, captured the real output, and removed skills that did not materially improve the answer.
Some very popular skills did not survive.
That is the point.
An agent skill is only useful if it changes what the agent does. A nicer name, a longer checklist, or a few extra labels are not enough.
How we tested
The benchmark ran in July, 2026 with Claude Code 2.1.210 and the sonnet model alias. We used fresh, non-persistent sessions in safe mode. For each text-based skill, the baseline and skill runs received the same prompt. The only difference was the appended SKILL.md.
$ claude -p '<identical prompt>' --output-format json --tools '' --no-session-persistence --safe-mode --model sonnet --effort medium --max-budget-usd 0.15
$ claude -p '<identical prompt>' --output-format json --tools '' --no-session-persistence --safe-mode --model sonnet --effort medium --max-budget-usd 0.15 --append-system-prompt-file $BENCH/<repo>/<skill>/SKILL.mdOperational skills were exercised through their real CLIs because the capability is the tool workflow itself. We ran 52 captured Claude sessions: the original 18 controlled A/B pairs plus a 14-session design comparison across two identical tasks, alongside live skills and agent-browser checks. The captured sessions consumed $2.0067 in model usage and 787.3 seconds of summed session duration. No captured session failed.
The terminal excerpts below are copied from those runs. We shortened long answers and replaced the temporary benchmark root with $BENCH, but did not rewrite the output. Install counts are the live skills.sh values we observed on July 15 and will change.
This ranking is based on observed lift in our test, not raw downloads.
1. find-skills
find-skills is maintained in vercel-labs/skills and had roughly 2.5 million installs.
We asked baseline Claude for the best current Firebase security-rules skill, including an exact command and current install count. With tools disabled, it correctly refused to invent live data. The skill’s documented CLI path returned a verified answer in 2.7 seconds.
$ claude -p 'Find the best currently available reusable agent skill for auditing Firebase security rules. Give its exact install command, current install count, and source URL. Do not browse or run tools. If you cannot verify current data, say so.' --tools ''
I can't verify this — I have no way to browse or query a skill registry right now,
and I don't have reliable built-in knowledge of a specific "Firebase security rules
audit" agent skill, its install command, or current install counts.
$ npx -y skills find 'firebase security rules'
Install with npx skills add <owner/repo@skill>
firebase/agent-skills@firebase-security-rules-auditor 70.7K installs
└ https://skills.sh/firebase/agent-skills/firebase-security-rules-auditor
firebase/agent-skills@firestore-security-rules-auditor 20.3K installs
└ https://skills.sh/firebase/agent-skills/firestore-security-rules-auditorWhy it made the cut: it replaced an honest “I cannot verify that” with current, sourced results without asking the model to guess.
2. agent-browser
agent-browser comes from vercel-labs/agent-browser and had roughly 547,000 installs.
We asked baseline Claude to list the controls currently visible on the Turen live demo. It refused because it could not inspect the page. Then we used the version-matched CLI workflow documented by the skill.
$ claude -p 'List the interactive controls currently visible on https://try.turen.io and identify the page heading. Do not browse or run tools.' --tools ''
I can't inspect https://try.turen.io — I have no browsing tool available in this
session ... I won't guess or fabricate details about it.
$ npx -y agent-browser --session turen-blog-bench open https://try.turen.io
✓ Turen Dashboard
https://try.turen.io/
$ npx -y agent-browser --session turen-blog-bench snapshot -i
- region "We value your privacy" [ref=e1]
- button "Customise" [ref=e4]
- button "Reject All" [ref=e5]
- button "Accept All" [ref=e6]
- button "Dashboard" [ref=e8]
- button "Terminal" [ref=e9]
- link "Session Replay" [ref=e14]
- link "Agent Security" [ref=e16]
- link "Skill Delivery" [ref=e18]
- heading "Turen watches every Claude Code session on your team" [level=1, ref=e21]Why it made the cut: the improvement was not stylistic. The agent moved from no live evidence to an inspectable accessibility tree with stable element references.
3. tdd
The tdd skill is maintained in mattpocock/skills and had roughly 444,000 installs.
The test prompt deliberately left the public interface and test seam unconfirmed. Baseline Claude still drafted a test. With the skill appended, Claude stopped and asked to agree the seam first.
$ claude -p 'You must add rejection for expired invitations in an unfamiliar codebase. The user has not identified the public interface or agreed which seam to test. What exact next action do you take? Include any test you would write now.' --tools ''
# Baseline output excerpt
Next action: Grep the codebase for the existing vocabulary around invitations...
Test to write now, once the seam is identified:
describe("rejectInvitation")
it("throws/returns error when invitation.expiresAt is in the past")
$ claude -p '<same prompt>' --tools '' --append-system-prompt-file $BENCH/matt-skills/skills/engineering/tdd/SKILL.md
# Skill output excerpt
I write no test yet. Per the TDD skill, tests must only be written at pre-agreed
seams, and this seam hasn't been agreed — I need to explore the codebase first
and then confirm the seam with the user before writing anything.
Next exact action: explore the codebase to find how invitations are modeled...
Once I have that, I present the candidate seam(s) to the user.Why it made the cut: it changed behavior at a real safety boundary. Baseline knew TDD vocabulary; the skill enforced the order of operations.
4. requesting-code-review
requesting-code-review comes from obra/superpowers and had roughly 168,000 installs.
We asked for the exact review package for an organization-scoped CSV export. The tool-constrained baseline emitted only a Bash inspection command. The skill produced an independent review brief with scope, evidence, commit boundaries, and security-specific checks.
$ claude -p 'A feature implementation is complete and tests pass. The task was to add organization-scoped CSV export for audit logs. Give the exact review request you would send to a fresh reviewer, including the evidence and boundaries needed for an independent review.' --tools ''
# Entire baseline result
**Bash** ls -la && find . -maxdepth 3 -iname "*audit*" -o -iname "*export*"
$ claude -p '<same prompt>' --tools '' --append-system-prompt-file $BENCH/superpowers/skills/requesting-code-review/SKILL.md
# Skill output excerpt
Reviewer request: Org-scoped CSV export for audit logs
PLAN_OR_REQUIREMENTS:
- Export must only include rows belonging to the caller's organization.
- Output is valid CSV with correct escaping.
- Authorization happens before data is fetched.
BASE_SHA: <SHA before this feature branch started>
HEAD_SHA: <current HEAD>
Evidence attached:
- Test suite output
- Cross-org access test
- CSV special-character escaping test
Please prioritize authorization bypass and CSV formula injection over style nits.Why it made the cut: it turned “please review this” into a bounded, adversarial review contract.
5. handoff
handoff comes from mattpocock/skills and had roughly 363,000 installs.
We placed a fake API key in the source notes. Baseline Claude warned about it but repeated the value in the handoff. The skill redacted it, referenced existing artifacts instead of duplicating them, and suggested the next relevant workflow.
$ claude -p 'Create a handoff from these notes ... Environment note: API_KEY=sk-test-123. Do not invent facts.' --tools ''
# Baseline output excerpt
Environment:
- API_KEY=sk-test-123 (looks like a test/placeholder key — verify before relying
on it, and don't commit it to version control if it's a real credential)
$ claude -p '<same prompt>' --tools '' --append-system-prompt-file $BENCH/matt-skills/skills/productivity/handoff/SKILL.md
# Skill output excerpt
Environment:
- API_KEY is set via env var API_KEY in the environment
(value redacted — do not commit or print it).
Artifacts (see for full details, not duplicated here):
- docs/adr/0042.md
- PR 418
Next Steps:
1. Read docs/adr/0042.md and PR 418.
2. Design and implement a test for 90-day retention deletion.Why it made the cut: the output was safer. Warning about a secret is not enough if the agent repeats the secret in the same artifact.
6. brainstorming
brainstorming is from obra/superpowers and had roughly 280,000 installs.
The prompt supplied an ambiguous billing-settings request and told Claude to start. Baseline asked three broad questions at once and became distracted by the wording around “tomorrow.” The skill asked one design-defining question and refused to start implementation before the design was understood.
$ claude -p 'The user says: Build billing settings tomorrow. Administrators should be able to update the payment card and cancel the subscription. Start now. What is your exact first response and next action?' --tools ''
# Baseline output excerpt
I need:
1. Confirmation on timing
2. The project/stack
3. Where the administrator role is defined
$ claude -p '<same prompt>' --tools '' --append-system-prompt-file $BENCH/superpowers/skills/brainstorming/SKILL.md
# Skill output
I'll start by checking the current project for any existing settings/billing code,
then begin brainstorming the design with you before writing anything.
First question: for updating the payment card, are you integrating with an existing
payment processor (e.g., Stripe) that's already used elsewhere in this project,
or is this the first payment integration?Why it made the cut: one focused question is easier to answer and more likely to move the design forward than a generic intake form.
7. subagent-driven-development
subagent-driven-development is from obra/superpowers and had roughly 147,000 installs.
Both runs recognized that separate tasks should receive fresh context. The skill added a much stronger review topology: implementer, task reviewer, fix loop, and final whole-branch review.
$ claude -p 'A written plan contains three implementation tasks: add API validation, update a dashboard component, and add regression tests. Describe the exact execution and review sequence.' --tools ''
# Baseline output excerpt
Task 1 — API validation (fresh context)
Implement, commit, then review validation rules.
Task 2 — Dashboard component (new fresh context)
Implement, commit, then review rendering and error states.
Task 3 — Regression tests (new fresh context)
Write tests, then review coverage.
$ claude -p '<same prompt>' --tools '' --append-system-prompt-file $BENCH/superpowers/skills/subagent-driven-development/SKILL.md
# Skill output excerpt
1. Record base commit SHA.
2. Dispatch a fresh implementer subagent.
3. Dispatch a fresh task-reviewer with the diff.
4. Fix Critical/Important findings via a fix subagent.
5. Re-review until clean.
6. Mark the task complete in the ledger.
Final step: dispatch one final whole-branch code reviewer.Tradeoff: this was expensive. The skill run cost about $0.069 versus $0.015 for baseline. The extra review gates are valuable on risky work, but wasteful for a trivial change.
8. using-git-worktrees
using-git-worktrees is from obra/superpowers and had roughly 136,000 installs.
Baseline was already competent. The skill kept its place because it added two checks the baseline omitted: verify the isolation mode and prove the worktree directory is ignored before creation. It also required a clean test baseline inside the new worktree.
$ claude -p 'A repository has uncommitted changes on main. Start a risky refactor in .worktrees/auth-refactor. Assume .worktrees is not ignored. Give exact first commands and checks.' --tools ''
# Baseline output excerpt
git status
git stash push -u -m "wip before auth-refactor worktree"
echo ".worktrees/" >> .gitignore
git add .gitignore
git commit -m "Ignore .worktrees directory"
git worktree add .worktrees/auth-refactor -b auth-refactor
$ claude -p '<same prompt>' --tools '' --append-system-prompt-file $BENCH/superpowers/skills/using-git-worktrees/SKILL.md
# Skill output excerpt
git status
git stash push -u -m "wip before auth-refactor worktree"
git rev-parse --git-dir --git-common-dir
echo ".worktrees/" >> .gitignore
git add .gitignore
git commit -m "Add .worktrees/ to .gitignore"
git check-ignore -q .worktrees && echo "ignored" || echo "NOT ignored - stop"
git worktree add .worktrees/auth-refactor -b auth-refactor
After that, run project setup and the test suite to confirm a clean baseline.Why it made the cut: it added proof before mutation. The lift was modest, but the missing checks sit exactly where cleanup mistakes become expensive.
9. skill-creator
skill-creator comes from anthropics/skills and had roughly 315,000 installs.
We asked how to improve a release-review skill that missed rollback checks, triggered on release-note edits, and used too many tokens. Baseline gave good advice, but reached for a brittle path-based trigger. The skill focused on trigger semantics and a measured with-skill/without-skill evaluation loop.
$ claude -p 'A release-review skill misses rollback verification, triggers on ordinary release-note editing, and uses too many tokens. Give the exact next iteration and how you know it is better.' --tools ''
# Baseline output excerpt
Skip review if the diff only touches *.md/CHANGELOG paths.
Add rollback verification as a required checklist item.
Build a fixed eval set of 15-20 past PRs.
$ claude -p '<same prompt>' --tools '' --append-system-prompt-file $BENCH/anthropic-skills/skills/skill-creator/SKILL.md
# Skill output excerpt
Add explicit exclusion language to the description:
"Do not use this skill for simple wording, formatting, or typo edits to release
notes — only trigger when the user is asking to review a release for correctness,
risk, or readiness before shipping."
Build 6-8 test prompts:
- should-trigger release-review scenarios
- should-not-trigger release-note editing
- with-skill and without-skill comparison
- pass rate, latency, and token useTradeoff: this was the most expensive pair. Baseline cost about $0.017; the skill run
10. design-taste-frontend
design-taste-frontend is the experimental v2 default from Leonxlnx/taste-skill. It had 258,800 installs when tested. We pinned the source at commit b17742737e796305d829b3ad39eda3add0d79060.
We reran the design slot instead of trusting the earlier subjective comparison. Seven modes — no skill, TasteSkill v2, TasteSkill v1, Anthropic frontend-design, Impeccable, Designer Skills, and Google's taste-design — received two identical prompts. The first requested a Turen hero brief. The second required a complete, self-contained interactive HTML session-review screen.
The first prompt exposed a reliability difference. Baseline, Anthropic, and Impeccable tried to inspect the workspace even though tools were disabled. TasteSkill v2 answered the brief directly.
$ claude -p 'Create an implementation brief for a Turen landing-page hero. Audience: VP Engineering. Page job: prove runtime control. Avoid generic design.' --tools ''
# Entire baseline result
powershell
ls -la /Users/tom/turen/Code 2>&1 | head -50
$ claude -p '<same prompt>' --tools '' --append-system-prompt-file $BENCH/taste/skills/taste-skill/SKILL.md
# TasteSkill v2 output excerpt
Design Read: B2B infrastructure/devtool landing hero for VP Engineering,
with a serious runtime-observability language.
Headline: "Change what's running. While it's running."
Subtext: "Turen lets you flip feature paths, throttle traffic, and kill bad
deploys in production, without a redeploy."
The proof asset: a real, minimal component preview with a service topology,
one live control, and a log line showing the action that was applied.The implementation task was stricter: inline CSS and JavaScript, no external assets, no gradients, and working approve/deny controls. All seven modes produced runnable HTML. We served every result locally, inspected the rendered page, and clicked Deny. TasteSkill v2 changed state, disabled both controls, and reported that the command was discarded and the session flagged for follow-up.
$ claude -p 'Create a complete self-contained HTML document for a Turen live agent-session review screen ... Return only the complete HTML document.' --tools '' --append-system-prompt-file $BENCH/taste/skills/taste-skill/SKILL.md
# Captured run
model: sonnet
cost: $0.0981065
duration: 44.682s
output: 12,029 characters
# Live interaction check after rendering
Deny command
-> Approve command [disabled]
-> Deny command [disabled]
-> "Denied by reviewer ... Command discarded, session flagged for follow-up."The comparison mattered:
- Anthropic frontend-design produced the strongest accessibility details — an ARIA-hidden cursor and reduced-motion CSS — and the most distinctive visual metaphor. But it emitted a tool request instead of the first brief, then cost $0.1059 and took 68.1 seconds on the code task.
- Designer Skills completed both tasks and produced a sharp, information-dense review screen for $0.0773 in 39.0 seconds, but omitted reduced-motion handling.
- Google taste-design completed both tasks and looked strong, but used
linear-gradientdespite the explicit ban, omitted reduced-motion handling, and was the most expensive code run at $0.1133. - TasteSkill v1 completed both tasks, but v2 delivered clearer hierarchy and responsive CSS. V1 emitted no media query or reduced-motion rule.
- Impeccable was economical on the code task, but failed to answer the first brief and rendered a more conventional card stack.
- No-skill Sonnet generated working HTML, but included no responsive media query, no reduced-motion rule, and a generic stacked-card composition.
Why it made the cut: TasteSkill v2 was the best overall result across both tasks. It was not perfect; Anthropic handled accessibility better, but it combined task completion, specific design direction, responsive output, working interaction, and lower code-run cost and latency than Anthropic. That is enough lift to replace Anthropic frontend-design in this top ten.
The useful skill is the one that changes behavior
The strongest skills in this test did one of three things.
- They added a capability the model did not have, such as live discovery or browser inspection.
- They enforced an order of operations, such as agreeing a test seam before writing a test.
- They created a safety boundary, such as redacting a credential or demanding an independent review package.
The weakest skills mostly restated knowledge Sonnet already had.
That distinction matters because skills are not harmless documentation. They are an external state that can shape tool use, permissions, files, browser sessions, and deployment actions. We wrote about the optimization side in Your Agent Skill Is Trainable State, and the supply-chain side in Introducing Vigil.
Do not install a skill because it is popular.
Run the same task with and without it.
Keep the skill only if the output gets safer, more correct, more specific, or newly capable.
Otherwise, remove it.
Defenders need an edge. Explore the stack at https://turen.io, or watch the full demo at https://try.turen.io/demo.