v1.15.0

1.15.0 - 2026-08-20

Two rules that had been warnings since 0.14 became errors. Nothing happens to you until you opt in.

Do you need to do anything?

If library.json has a standard line (the version of the rules you are graded against), no. Your grade does not change until you raise that number yourself.

If it does not have one, yes - today. A plugin with no standard line is graded against the newest rules the moment they ship, so both rules below already apply to you. Add the line and pick a version:

{ "standard": "0.14" }   // grades you against 0.14's rules, not whatever is newest

See what adopting 0.15 would cost, before you commit

npx agent-skills-toolkit . --strict

That grades you against the newest rules without changing your pin. Anything that appears only under --strict is something adoption would turn real. Nothing is written; it just tells you.

The two rules

1. Declare your workflows. Every _workflows/<name>.md file must be listed in library.json under components.workflows, and everything listed there must exist on disk.

Why it matters: a workflow file you never declared is invisible to whoever installs your plugin - it ships, and nothing loads it. A declared file that does not exist cannot be delivered at all.

2. A marketplace catalogue must be readable in one piece. If you ship .claude-plugin/marketplace.json, it must parse, it must have a plugins array, and its entries must not mix skill-style sources with plugin-style sources.

Why it matters: a catalogue that mixes both kinds is claimed entirely by the first tool that reads it, so the other half is examined by nothing and fails silently.

Also new: your pinned GitHub Actions get checked

If you pin an Action by commit SHA, the # v1.2.3 comment next to it is the only part a human reads - and the bots that bump the SHA routinely leave that comment stale. We had caught that by eye three times and never once automatically.

npm run action-pin-watch

It resolves every pin and reports where the label disagrees with what the SHA actually points at. It reports and never rewrites, because which half is wrong is a judgement call. A pin that is merely behind the latest release is reported and never fails the run - that is news about someone else's release, not a defect in yours.

This runs on our workflows. It adds no requirement to your plugin.

Also new: three skills for keeping up with the agents

• askit-capability-whats-new - surveys what Claude Code, Cowork, Codex and the upstream spec shipped since you last looked, and writes a dated record. It decides nothing, and it records a version rather than a date, so "everything since 2.1.208" is exact and anyone can re-check it.
• askit-capability-gap-analysis - takes one of those findings and works out what it means for you. It proposes a change and implements none of it.
• Together with the existing askit-capability-advisor they read as the sequence they are: what shipped, what it means for us, what we tell an author.

Why a survey you run rather than an alarm that fires: while building this we measured one platform moving through 29 versions inside a single changelog window, and another carrying 31 entries. An alarm that fires weekly on entries which almost never matter teaches you to close it unread - and then it is worse than nothing, because its existence looks like assurance.

A documentation fix worth re-reading

docs/reference/universal-checks.md - the page describing the entry-level requirements - had stopped at U13, missing four checks across two releases. The README always said 34 because that number is machine-checked; the table it pointed at was not. If you used that page to understand the entry-level bar, read it again.

What did not change

34 checks, same as before. None added, none removed. Every plugin in our reference set was graded before and after, at its own pin, and not one changed grade.

The part we would rather not print

The catalogue rule graduated against a survey that found zero real instances of the problem it prevents. It is preventive, not corrective. We shipped it anyway, because nothing in our plan schedules the growth that would change that answer - so "wait for evidence" would have quietly meant "never". If catalogues that mix entry kinds turn out to be a real pattern rather than a mistake, that is the thing to tell us.

The other rule waited a full release for one specific reason: graduating it immediately would have cost a real plugin in our reference set an entire grade, over nine workflows it shipped and had not declared. That plugin declared all nine the day after we published the decision - inside the window the decision created. That is what a migration window is for, and it is the first time we watched one work end to end.