Five agent skills from a working studio, and the mistakes inside them

The short answer

A skill pays for itself when it holds what a model cannot know: which of two tools has the true sales figure, which page is the template, what we never do for free. Generic advice the model already has does little. The research agrees more than it seems to: in one benchmark, curated skills raised the pass rate by 16.6 points; in another, 92 of 98 public skills made no measurable difference.

Our own five are short where the work is judgement and long where it has to be exact. Every one of them ends the same way: the agent prepares, and a person sends, publishes or deletes. And because one large scan this year found a critical security issue in about one public skill in seven, and another found some vulnerability in one in four, we install other people's skills the way we install plugins: rarely, and after reading them.

If you are new to the format itself, start with our guide to Agent Skills for agencies, which covers what a SKILL.md is and how to write one. This article is what happened after.

The five skills we run

Codeable is the WordPress freelance marketplace where we take some of our work. The two Library skills read the client's details from the project's files at run time; the other three have them written in, which comes up again below.

Most of each skill is a mistake we made once

The monthly report: numbers first, words after

The report skill is the longest because the numbers go to a client. Nearly every rule in it has a story:

• One source per number. The client's shop runs on WooCommerce, the traffic on Google Analytics. In one month Analytics recorded about a third of the orders the shop actually took, so the skill says sales come from WooCommerce only, conversion is WooCommerce orders over Analytics sessions, and the gap between the two is checked every month as a sign the tracking tag is broken.
• A check list before any sentence. Orders fetched must equal the total; product revenue must add up to net revenue within a dollar; every percentage is worked out again in Python from the raw numbers. Even a superlative is checked: "best since March" means every month after March was lower.
• Plain email. A table pasted from Analytics into the cover email once made it 1,708 pixels wide and cut the text off on the right. The rule now: no screenshots and no pasted HTML in the body.
• Do not edit what someone has open. Changes made to a Gmail draft while Ali had it open were overwritten by his window. The skill edits a draft only when he has closed it.
• Never sent by the agent. The email is drafted after Ali approves the PDF, and sent by him.

The landing page: never invent a heading

The landing page skill copies an existing page in the WordPress block editor and changes only the parts that differ. Its rules are mostly about the editor and about honesty:

• Content comes from the client's document, nothing else. The skill says, in so many words, not to make up a heading, slogan, eyebrow or subtitle that is not in the document, because Ali kept catching them.
• The editor does not behave like a text box. One click on a block selects the block, not the text; the canvas scrolls after a selection. So the agent takes a screenshot after every click and places the cursor with the arrow key before typing.
• Look at what you uploaded. After the cover image goes to the media library, the agent opens its URL and checks it with its own eyes. If it is wrong it uploads a new one and tells Ali; it never deletes a file itself.
• Draft, then ask. The page is left as a draft and Ali publishes it.

The marketplace reply: say less, give nothing away

The reply skill is the shortest of Ali's three, because writing to a prospect is judgement. Part of it, as written:

2. No self-praise. Never write lines like "I have 10 years of experience" ...
   Credibility comes from the specific observations about their site,
   not from claims about yourself.

3. No free work. Free is limited to a short look at the public site to ask
   informed questions. Anything that requires logging in, auditing the
   install, mapping URLs, writing a plan document, or fixing something
   "quickly" is paid.

4. Keep it short. Two or three questions, one or two sentences each.

It also tells the agent to read the whole thread first and not to repeat a question another expert already asked, and never to promise search rankings by a date: "SEO fixes are fast to apply, slow to show."

Page QA and the health check: report, never fix

The two Library skills are for any client, so they hold no client facts at all. The QA skill reads the project's client-context.md and says its rules win over the defaults. It checks the page at 390, 1440 and 1920 pixels, opens every link, runs PageSpeed, fills forms only with obviously fake details and never pays for anything. Then it reports. "Do not fix, publish, delete or change any setting" is a line of its own, and so is "Report only what you checked."

The health check reads the client's own health-checks.md and runs what is due. What it cannot run, because it needs an admin login, a payment or a person's judgement, it lists as "Needs a person" instead of guessing.

Long where it must be exact, short where it is judgement

Anthropic's authoring guide puts this better than we could: "Match the level of specificity to the task's fragility and variability." Its picture is a narrow bridge with cliffs on both sides, where you give exact steps, and an open field, where you give a direction.

Our report skill is the bridge: it has the exact API calls, the checks and the page layout, because a wrong number in front of a client costs more than a long file. The reply skill is the field: four rules and a way of reading a thread. The same guide also says "Default assumption: Claude is already very smart" and asks of every paragraph whether it justifies its cost, which is the test we now use when a skill starts to grow.

Where we broke our own rules

Our own guide says a skill should keep client details out, start its description with "Use when", and be approved by a person before anyone uses it. Measured against that:

• Three of our five name a client. The report skill has the client's contact and analytics property in it; the landing page skill has page and form IDs. It works because one person runs each one for one client. It also means they could not go into a shared library as they are, and that is a real limit: Anthropic's overview says custom skills in claude.ai are "Individual user only. Each team member must upload separately." Nobody else at the studio can run them.
• None of Ali's three descriptions starts with "Use when", and one is written in Turkish. Anthropic's guide asks for descriptions in the third person, and its own skill-writing skill warns that "currently Claude has a tendency to "undertrigger" skills" and suggests making descriptions "a little bit "pushy"". We have not measured how often ours are picked up on their own.
• We wrote them backwards. The guide says to "Create evaluations BEFORE writing extensive documentation", with at least three test scenarios and a run on Haiku, Sonnet and Opus. We did the job by hand first and wrote the skill from it, then fixed it each time a run went wrong. The skills are better for the real runs; we still have no baseline to say how much better.

What the research says

The two benchmarks look like they disagree. SkillsBench (Li et al., version 4 of 14 June 2026) gave agents curated skills written for 87 tasks and saw the average pass rate go from 33.9% to 50.5%, with smaller, focused skills doing better than large bundles. SWE-Skills-Bench (Han et al., version 2 of 27 October 2026) took 98 public skills, ran 3,920 paired tests, and found 92 had no significant effect; the average moved from 76.6% to 76.9%. The paper says the harmful ones "anchor the agent on their own templates and override the task's explicit instructions".

Our reading, and it is only a reading: a skill helps when it carries something the model does not have. A public skill on how to write good React mostly repeats what the model knows. "WooCommerce is the sales source, not Analytics" is not in any model.

Vercel's own eval (Jude Gao, 27 January 2026) adds the other half: "In 56% of eval cases, the skill was never invoked." Told explicitly to use it, the agent passed 79% of their Next.js tasks against 53% without; a plain index in AGENTS.md passed all of them. Vercel's conclusion is that skills "work better for vertical, action-specific workflows that users explicitly trigger". All five of ours are started on purpose, by a person or by a task on the board, which may be why the triggering problem has not bitten us yet.

Public skills: read them like code

Two scans this year looked at what is published:

• Snyk (ToxicSkills, 5 February 2026) scanned 3,984 skills from ClawHub and skills.sh: 13.4% had at least one critical security issue, and it found 76 malicious payloads, 91% of which also used prompt injection. Snyk sells security scanning, so read it as a vendor study.
• Liu et al. (Agent Skills in the Wild, 15 January 2026) analysed 31,132 skills from two marketplaces: 26.1% had at least one vulnerability and 5.2% showed patterns that strongly suggest malicious intent. Skills that bundle scripts were 2.12 times as likely to have a problem as instructions alone.

Anthropic's advice is blunt: "Use Skills only from trusted sources: those you created yourself or obtained from Anthropic", and "Treat like installing software". None of our five bundles a script; the report skill shows code, but the generator it runs lives in the client's project, where we can see every change to it.

For platform work the safer start is the platform's own skills: WordPress publishes 18, written with GPT-5.2 Codex and "reviewed and edited by WordPress contributors"; Shopify and Webflow publish their own. Even then, read them. Vikas Singhal of InstaWP, a WordPress hosting company, cloned fifteen public skill repositories for his own roundup and kept seven: "Most public agent skill repos will not survive contact with a client site."

Where a skill should live

The same file works in many agents, but where you put it decides who can use it:

And where each tool looks for skills, from its own documentation:

How we run them on the board

The two team skills live in the Proofyard Library, which keeps the SKILL.md shape and hands skills to Claude over the connector: Claude lists them, reads the one whose description fits and follows it, and the instructions it gets say a skill never overrides the person's request, the board's rules or safety. A new skill, or a change to one, waits for a person to approve it. When Claude notices it has followed the same steps on several tasks it can draft one, and a person decides.

The facts about each client, the things that made Ali's three skills single-client, belong in the project's files instead, where our AI knowledge base keeps them; our shared AI knowledge base guide explains the split. The rule that every skill ends with a person deciding is the one in our guide to what an AI agent should ask before it acts, and our agent test shows how four models handled written rules across 40 client notes. Prices are on our pricing page.

Sources

• Anthropic, Skill authoring best practices and Agent Skills overview, undated, read 31 October 2026.
• Anthropic, skill-creator SKILL.md, read 31 October 2026.
• Li et al., SkillsBench, arXiv 2602.12670, version 4, 14 June 2026.
• Han et al., SWE-Skills-Bench, arXiv 2603.15401, version 2, 27 October 2026.
• Liu et al., Agent Skills in the Wild, arXiv 2601.10338, 15 January 2026.
• Snyk, ToxicSkills, 5 February 2026.
• Vercel, AGENTS.md outperforms skills in our agent evals, Jude Gao, 27 January 2026.
• InstaWP, Claude Code skills for web development, Vikas Singhal, updated 3 September 2026.
• Our five skills, as they stood on 31 October 2026. Client names, contacts and figures are left out.