In one consultancy's 60-skill library, 29 skills miss a tested skill-format requirement

Key findings

• The sample: one SEO and AEO consultancy's working library (ours): 60 skills, holding 733 files besides their 461 recorded learnings. We measured it on 10 November 2026 (UTC) from a copy scrubbed of client names; the newest file in the copy is dated 5 November 2026. Every figure describes this one library, not skill libraries in general.
• Format requirements: 29 of the 60 skills miss at least one format requirement we tested, from the Agent Skills specification or Claude's skill documentation. For 15 of them it's only the name, written as a title with capitals and spaces instead of lowercase words joined by hyphens. The other 14 miss a frontmatter or description requirement. It's 33 if a placeholder in angle brackets (the kind of thing <brand> is) counts as one of the "XML tags" Claude's documentation rules out; that's a reading, not a test, so we lead with 29.
• Authoring advice, counted apart because Anthropic's guide gives it as advice, not as a requirement: 46 descriptions open with a command ("Build …", "Run …") instead of the third person the guide asks for, and 39 skills have a reference file over 100 lines with no contents list at the top.
• The checker needed checking: it's a pattern matcher, so we read its findings, with an AI model; no person checked the labels. On that reading all 34 format findings held. Of 52 "not third person" flags, 6 were noun phrases, which are in no grammatical person, so they aren't counted. Three other checks were dropped: two were wrong too often in the findings we read, and two have no source sentence behind them (one check failed both tests).

What this doesn't show

• One library. One practitioner's 60 skills say nothing about consultants or skill libraries in general.
• Files, not loading. We checked the files as they were copied on 5 November. We didn't test whether any assistant refuses, skips or misreads these skills, so we make no claim about what fails to load.
• The copy, re-checked. Replacing names can change a description's length, so we ran the same checks on the stored originals of the same date (see the method). No result changed: 0 of 60 skills differ on any rule here.
• Not every requirement. We tested eleven format requirements (listed below), under our own reading of each. Two stated rules weren't measured. The 29 is what these checks found, not a full conformance audit.
• Where the library lives. The system it lives in also stores each skill's name and description on the skill's record. A copy of the bare folder would carry only what's in the files, which is what we measured.
• No quality claim. Missing a format rule says nothing about whether a skill does its job well.

Which format requirements does it miss?

The requirements come from the open Agent Skills specification and Claude's Agent Skills overview, both read on 10 November 2026. A skill counts once per requirement. The table's 34 findings fall in 33 skills, because one skill misses two; without the XML row, 29 skills.

29 of 60 skills miss a tested format requirement (33 if a placeholder in angle brackets counts as an XML tag)

Skills, of 60, that miss each rule; a skill counts once per rule. One consultancy's 60-skill library, measured 10 Nov 2026.

Format requirements (the Agent Skills spec, Claude's skill docs)

1. Name isn't lowercase-with-hyphens: 15
2. Description over 1,024 characters: 6
3. <Placeholder> in the description (a reading): 5
4. No frontmatter: 5
5. Frontmatter isn't valid YAML: 3

Authoring advice (guidance, not requirements)

1. Description opens with a command: 46
2. Reference file over 100 lines, no contents list: 39
3. A file reached only through another file: 8
4. SKILL.md body of 500 lines or more: 3

• Names written as titles: all 15 read like headings. None of the 15 misses another format requirement. The name checks apply to the 52 skills whose frontmatter parses; the other 8 already count under the frontmatter rows. The pattern also rules out a hyphen at either end and two hyphens in a row.
• Placeholders in angle brackets: all 5 are the authors' own fill-in markers, not markup, and not the names our scrub put in (none of those contains an angle bracket). They match the rule's wording, but whether the rule is meant to cover placeholders is a reading, and we didn't test whether any tool treats them as tags. 4 of the 5 skills miss nothing else; the fifth also has a description over the limit.
• Frontmatter that doesn't parse: in all 3, the description holds a colon followed by a space in unquoted text, which YAML doesn't allow there, so the whole block fails to parse.

Tested, and nothing found: the frontmatter is a key-value mapping; a name and a description are present; the name is at most 64 characters, has no XML tags and has neither reserved word ("anthropic", "claude"). Every one of the 60 skills has a SKILL.md.

Not tested: the spec's "Must match the parent directory name" (the library's system stores skills by id, not in folders) and the best-practices guide's "Should describe what the Skill does and when to use it" (our only check for it is a house pattern, not a public rule).

Which pieces of advice does it miss?

Anthropic's skill authoring best practices gives advice rather than requirements. Two of these points are also in the specification, worded as advice there too.

• Third person: the 46 open with a command, which addresses the reader; the guide's good example opens with a third-person verb. We classified only the opening. The guide's reason: "The description is injected into the system prompt, and inconsistent point-of-view can cause discovery problems."
• Body length: we counted the body after the frontmatter. The spec's sentence is about the whole file, so it could flag a few more.

How often did our reading uphold the checker?

"Held" means every reading run held it (see the method); a skill counts once per check, whichever of its files the check fired on.

• Scripts: the guide asks to "Make clear in your instructions whether Claude should" run a script or read it. In 5 of the 10 we read, the text made that clear in a way the pattern didn't catch.
• ALL-CAPS: the skill guide doesn't advise against capitals. It shows "ALWAYS use this exact template structure:" in an example, and lists "stronger language such as “MUST filter”" among the changes a reviewer might suggest. Anthropic's general prompting guide says "The fix is to soften any aggressive language", about tools and skills that over-trigger, which is a different claim. Our checker attributed the rule to the skill guide; that was wrong. Its matches also caught labels, titles and quoted examples.
• Every file named: all 10 we read held, but no source sentence asks for it.

What it means

Four habits address every format miss we found in this library:

• Write name in lowercase words joined by hyphens, and keep a display title somewhere else.
• Keep the description to 1,024 characters.
• Start SKILL.md with a --- frontmatter block, and write it with a YAML library, then parse it back, rather than by hand, so a colon in a description can't break it.
• If you want to stay clear of the XML rule's wording, write placeholders without angle brackets: "the brand" rather than a bracketed word.

The specification names a validator, skills-ref: "This checks that your SKILL.md frontmatter is valid and follows all naming conventions." We didn't run it for this article; going by that description, it covers the spec's rules, not Claude's XML rule or the authoring advice. Then read what any checker flags before acting on it: of the 12 checks that found something here, we dropped 3.

Methodology

• Data: the 60 skills of one account (ours): 55 personal skills and 5 kept in client projects. The newest file in the copy is dated 5 November 2026. Client, partner and person names were replaced with fictional stand-in names (a private map of 201 rules), and the copying step proved, file by file, that each difference from the stored version is one such replacement. That alone doesn't show the checks give the same result on the originals (a longer stand-in can lengthen a description), so we compared all 733 files of the 60 skills with the store's versions of that date. 0 skills differ on any rule here, on frontmatter or on line counts; 12 descriptions differ in length by at most 15 characters, and none crosses the 1,024 limit. Quoted examples in this article are illustrative forms, not text from the library. We publish counts only.
• The checker: lint-v1, our own rule set, limited to the rules it attributes to the specification or Anthropic's guide; our house rules (evals, a learning loop) are left out. Two format checks aren't in lint-v1: the name's form, using the specification's pattern, and the reserved words. A skill whose frontmatter is missing or doesn't parse isn't checked for the name; it already counts under the frontmatter rules.
• The reading: an AI model (Claude), in the session that wrote this article, read every format finding and every finding of the four advice checks we count, against the rule's source sentence. It read the lines each finding fired on (the description, the first frontmatter lines, a reference file's first 15 lines, the lines that name a file), not whole skills; "a contents list at the top" means within the first 15 lines. For the three other checks it read up to 10 findings each, drawn with a fixed seed (Python's random.Random("956:<rule>")); an earlier draw was read as a pilot and replaced. A rule was dropped when more than 20% of the findings read were wrong, or when no source sentence states it. The sampled checks only decide what we leave out; every count we publish comes from a full read.
• A second run of the model: a new session of the same model, given the written protocol but not the first labels, re-read the 131 findings of six of the seven advice checks (body length is a line count, so it wasn't re-read; format findings are decided by a parser, a character count or a pattern, except the XML reading, which one run made). The two runs agreed on 129 (Cohen's κ = 0.93). That measures consistency between two runs of one model, not correctness. For the re-read checks, a finding counts only when both runs held it, and a check's error rate counts a finding as wrong when either run did. Of the two differences, one is a nested reference whose file SKILL.md may or may not name (it names a file of the same name in another folder), so that count is 8, not the first run's 9; the other is in the dropped scripts check. No person checked the labels.
• What the reading can't show: it checks that each flag is right, not that the checker missed nothing. The format checks are deterministic: PyYAML's safe loader for the frontmatter, Python's character count of the trimmed description, and the specification's name pattern. Our unit tests cover them, which shows how they behave, not that they match every tool's reading of the rules.
• Sources: the specification, the overview, the best-practices guide and the prompting guide, read on 10 November 2026. The pages carry no version, so the result file keeps every sentence we judged against, verbatim.
• Reproducibility: two scripts count every number from the copy, the private labels and the scrub's own files (one for the library's size, one for these checks); neither writes to the store. They record a fingerprint of the copy and of the labels, and their output holds counts only. The labels are the model's verdicts, which the scripts only tally. The copy and the labels stay private, so the numbers can be audited by us but not re-run by a reader.

Disclosure

Unilytics builds a skill system for consultants. This library lives in it, and the checker is ours. The skills, including the 5 kept in client projects, are the consultancy's own playbooks; nothing from them is published but counts. The findings were read by Claude through Anthropic's API. Corrections: if a number here is wrong, we fix it on this page with a dated note at the top.