v1.18.0

1.18.0 - 2026-09-03

New here? This toolkit checks a library of agent skills - the kind Claude Code and Codex load - against a written standard, and tells you what it meets and what it does not. It runs the same way on your laptop and in CI, and gives the same answer both times, because nothing about the grading involves a model.

---

What changed for you

	What	Why it matters
📘	The GitHub Action is documented	It existed before, explained nowhere except a comment in its own config file
🏷️	It has a clearer name	Agent Skills Toolkit Grader, was Advanced Skill Library Standard Gate. Nothing breaks
📊	The full result is published	Previously you got a badge. Now you get the whole report
⚖️	Every grade states its own limits	A tier says the structure matches a standard. It does not say the skills are good

Do you need to do anything? No. No check was added, changed or removed, so nothing that passed before will start failing. The Standard stays at 0.15 and the check count stays at 34.

---

Add it to your CI

Two lines in a workflow and every push gets checked. Full guide: run the gate in GitHub Actions.

- uses: actions/checkout@v7
- uses: product-on-purpose/agent-skills-toolkit@v1.18.0
  with:
    path: .

The rename does not affect this. uses: points at the repository, not the display name, so existing workflows keep working untouched.

Read the full result online

These are regenerated automatically on every deploy, so their date and their numbers cannot drift apart.

• The full report - every check, whether it passed, and what to do about the ones that did not
• The same thing as data - if you want to script against it
• The family registry - every plugin in the marketplace, graded together

---

Where to start

If you want to	Go here
Understand what this is	What the tiers mean
Try it without installing anything	Install and run via npm
Add it to CI	Run the gate in GitHub Actions
Understand a failure	Troubleshoot the gate
Know the limits of the claim	What a tier does not certify
Read everything	The documentation site

Under the hood - what we fixed about our own process

Most of this release is the toolkit checking its own work in places it previously could not.

We now test the Action the way you use it. It had shipped broken to everyone twice, because our own CI called the underlying scripts directly and never went through the Action itself. The path you use was the one path nobody tested.

The marketplace report is measured fresh on every deploy rather than being a snapshot someone ran by hand. The old one had gone three weeks stale carrying two claims that were no longer true.

A release can no longer be tagged with broken release notes. The check that catches that used to run after publishing, which is how the previous release went out with a formatting placeholder as its heading.

A monthly job now watches the upstream specification we track. It had existed for several releases and nothing ever ran it.

v1.17.1 - the records patch

1.17.1 - 2026-09-01

Three defects in the records are fixed, one of them a gate that was failing a valid marketplace.

Do you need to do anything?

No. No check is added or removed, the spine stays at 34, the Standard stays at 0.15, and no
verdict moves. One class of verdict can only get BETTER: if your marketplace carries a command-source
entry, it stopped being falsely rejected.

What changed

• A valid marketplace stops being falsely failed. Claude Code v2.1.229 added command as a
  marketplace plugin-entry source kind. The gate did not know it, so such an entry read as an unknown
  kind - and a source rejection reds the whole catalogue. If that was you, your collection was red for a
  reason that was this tool's fault, and it is not any more. Nothing else moves: all six members of the
  reference family grade byte-identically before and after.
• The provenance ledger's cross-references are trustworthy again. Four documents claimed a vendor
  claim was pinned when it had never existed. They now say what actually happened, and a new guard
  (npm test) makes the class impossible to reintroduce quietly.
• Two published records stopped contradicting reality. The family registry now grades every member at
  the sha the catalogue pins, so all six rows are reproducible from the commands the page prints. And
  nine internal planning files stopped describing two long-shipped features as undecided stretch goals.

For maintainers of this repository

Two standing policies were adopted: unshipped work carries a phase name rather than a version number
(ADR 0057), and
every audit-origin item now has a tracked row in
the audit-intake index.

v1.17.0

1.17.0 - 2026-08-28

Releases now reach npm on their own, and your gate stops swallowing one class of failure.

Do you need to do anything?

No. No check is added or removed, the spine stays at 34, the Standard stays at 0.15, and
no verdict moves. One new warning can appear: if a folder's README.md exists but cannot be read (a
directory carrying that name, a permissions failure, a corrupt checkout object), G8 now reports
that instead of silently skipping the folder. A warning cannot move your tier, and the escalation to
error is scheduled for Standard 0.17, not now.

A tagged release publishes itself, through a human approval

v1.16.2 and v1.16.3 were tagged and GitHub-released on 2026-08-25 and were still absent from npm
three days later, because publishing required someone to remember to dispatch a workflow. Two fixes
written for consumers of the reusable Action reached those consumers by no route at all.

Now a pushed v* tag runs every release gate and stops at a required reviewer on the
npm-publish deployment environment. Nothing reaches the registry until a human approves, and
nothing depends on a human remembering. A forgotten publish is a silent failure; an unapproved
deployment is a visible one that sits in the Actions tab until someone rules on it. This release is
the first to ship through that path.

G8 stops reporting success for folders it never examined

If a folder's README existed but could not be read, G8 caught the error and emitted nothing: the
folder-guide and inventory checks were silently disabled for that folder while the run reported
success. That is the "reports success while checking nothing" class this toolkit grades other tools
on, and it sat in the spine since 2026-06-03. It now emits a finding naming the path, the error
code, and the fact that the dependent checks did not run - at warn until Standard 0.17, per
ADR 0056 (an unreadable folder README is a finding, not a silent pass).
The window was measured before being trusted: 213 READMEs across the six reference-family members,
zero affected today.

Shipped records stop being rewritten

The count guard used to keep policing a release's packet and CHANGELOG section after that release
shipped, so every test the NEXT release added pushed on numbers that were already tagged history. By
2026-08-24 this blocked the pre-cut gate outright, on a number that was correct for the tag it
described. Once v<version> exists, its packet and CHANGELOG section are now exempt as records;
STATUS.md never is, because it is live state. The guard fails closed on a clone with no tags.

A documentation style contract, with a report instead of a gate

The repository's own documentation passes had satisfied a sentence-length metric and still read as
hard. The defect was structural: one sentence carrying three ideas, the reason buried in brackets, a
specification arriving before the thing it specifies. There is now a written contract per
documentation quadrant and npm run doc-style, a report that measures all 88 published pages
against the checkable half of it and ranks them. Report-only, deliberately not wired into the gate.
The rewritten docs/explanation/architecture-internals.md is the exemplar: measured debt fell from
122 to 32 while the page got 17 percent longer, which is the intended trade on an explanation page.

How this release was verified

Suite 1439 tests, 0 failures (1 skipped, POSIX-only); the conformance gate at Advanced, 0
errors, 0 warnings; release-ready green on all five release-blocking gates. The Codex
round-trip was run for this tag: the emitted .codex-plugin/plugin.json was exercised against
codex-cli 0.144.5 on 2026-08-28 and the skills were confirmed ingested, not merely listed - the
first release since v1.14.0 to record this check. The publish itself ran through the new
tag-triggered path described above, as its first live exercise.

v1.16.3

1.16.3 - 2026-08-25

If you copied the SARIF step from the Action's usage comment, change @v3 to @v4.

Do you need to do anything?

Only if you enabled SARIF upload. The example told you to use github/codeql-action/upload-sarif@v3. That action targets Node 20, which runners now force onto Node 24 with a deprecation warning, and the v3 line deprecates in December 2026. Change the pin to @v4 and both warnings go away.

Nothing else changes. No check is added or removed, the spine stays at 34, the Standard stays at 0.15, and no grade moves.

What was wrong

This repository's own CodeQL workflow was already on the v4 line. The usage comment, which exists to be copied, was still on v3. The toolkit had updated the path it uses itself and left the path it hands other people behind.

That is the second instance of that shape in one day. v1.16.2 fixed an Action that failed before it graded anything, for the same underlying reason: internal path maintained, consumer-facing path not.

v1.16.2

1.16.2 - 2026-08-25

If you used the reusable Action, your gate never ran. It does now.

Do you need to do anything?

Yes, if you consume the Action. Bump your uses: pin to v1.16.2. Nothing else changes: no check
is added or removed, the spine stays at 34, and the Standard stays at 0.15. Grades are
unaffected, because the broken step failed before any grading happened.

What was broken

The Action's Set up Node step asked setup-node to cache npm using a cache-dependency-path built
from github.action_path. That is an absolute path outside the workspace, and setup-node resolves
the input as a glob relative to GITHUB_WORKSPACE, so it never matched. An unresolved path is an
error there, so the composite step failed and took the gate with it.

The failure was maximally confusing: a red required check, a log complaining about dependency caching,
and no findings, no tier, and no SARIF, because the grader never executed. Anyone reading it would
reasonably conclude their repository had a problem.

Why the cache is gone rather than fixed

The install being cached is one package. There is also no workspace-relative path that can point at
the Action's own lockfile, which is the whole reason the absolute form was reached for. Removing the
cache costs a second or two per run and removes an entire failure mode.

v1.16.1

1.16.1 - 2026-08-24

If you installed this toolkit from npm rather than cloning it, you could not reach Gold. Now you can.

Do you need to do anything?

Almost certainly not. No check is added, none is removed, the spine stays at 34 and the Standard stays at 0.15. Five plugins were graded before and after this change and not one moved.

The exception is if you were chasing Gold and G2 kept failing. Nothing to change on your side: re-run your pipeline, and a CI file that was already correct should now pass.

The bug

G2 asks for CI that runs the conformance gate. It recognised one way of writing that: node scripts/check.mjs, a path that exists only if you cloned this repository.

Our own install instructions tell you to use npm or the plugin marketplace. Do that, and you have no scripts/ folder at all. The command you can run was the one G2 refused. So Gold was unreachable for anyone who followed the documentation.

G2 now accepts five ways of running the same gate:

• npx agent-skills-toolkit .
• the installed command on its own, if you added the package as a dependency
• an agent-skills-toolkit GitHub Action
• node scripts/check.mjs, if you do vendor the gate
• an npm script that runs any of the above

Installing the package still does not count. Running it is the point.

Nothing about the rules changed. The Standard already asked for CI that runs the suite via the portable scripts, and npx runs exactly those from the published package. Only the checker disagreed with it.

Three more fixes, all in our own guards

• A vendor-claim watcher reported a clean run on a claim nothing could ever check. One mistyped character in a claim's source made it permanently unverifiable while the gate said everything was fine. It is one of five gates that block a release here.
• A parity check treated a corrupt file and a missing file as the same event. They are not: one is a defect, the other is nothing to compare.
• A worked example labelled a rewritten sentence as a direct quote. The page it came from carries a list; the example had flattened it into prose and still called it verbatim.

The documentation got a plain-language pass

Eighty-eight commands across 37 pages did not work for the reader they were written for. They all said node scripts/..., which needs a clone, while the install guide sends you to npm. They now use a command you can actually run.

One page had been false for three months: it told readers to wait for something that had already shipped. And the glossary is now reachable from every section rather than buried in one.

The rules behind those fixes are now built into the skill that writes our documentation, so new pages start from them.

v1.16.0

1.16.0 - 2026-08-22

The evidence this Standard rests on gets an address - and the release found that some of it was resting on nothing.

Do you need to do anything?

No. No check was added, none was removed, the spine stays at 34, and the Standard stays at 0.15. All six reference-family plugins were graded before and after. Every one came back byte-identical.

Installing changes nothing either way. Files moved inside the repository. The npm tarball ships the gate and STANDARD.md; the plugin install carries the whole tree. Both paths carry them as before.

One exception, if you pin the GitHub Action to a tag. action.yml's example now reads @v1.16.0. Pin a released tag or a commit sha - the example is an example, not a recommendation to track.

One thing worth re-reading

If you used the README's tier model to decide what Bronze requires, read it again. It described the Universal tier as U1-U9, U11-U13, 12 checks. The tier actually ships 16: U1-U9 and U11-U17. Six lines above it, the same section stated the spine correctly, which is how the error survived - the wrong count and its wrong list agreed with each other perfectly.

Four Universal checks therefore had no description anywhere in the README:

• U14 agent-restricted-fields - a plugin-shipped agent declares none of hooks, mcpServers or permissionMode; Claude Code refuses those on plugin-shipped agents for security reasons, so an author who writes one gets no signal it was ignored.
• U15 agents-dir-registerable - every .md under agents/ is a registered subagent, because the runtime loads every file it finds there. A stray README.md ships as a live phantom subagent.
• U16 metadata-placement - a governance key sits under metadata, not at the frontmatter top level where nothing reads it. The vocabulary itself stays open; only placement is checked.
• U17 catalogue-manifest-shape - a marketplace.json you ship parses, carries a plugins array, and does not mix skill sources with plugin sources.

If your standard pin is 0.15, all four already apply to you as errors. Nothing about the gate changed in this release; only what the README told you about it.

Eight public files carried a stale version of that list. All are corrected, and scripts/check-doc-enumerations.mjs now expands every check range in the documentation and compares it against the registry, so prose and gate cannot drift apart again without the suite failing.

Why this release exists

The tier ladder is defined by what Claude Code and Codex support. That makes every tier boundary a claim about software this project does not control.

Those claims used to live scattered across one skill's private folder and three separate directories. No artifact recorded which vendor fact any boundary actually depended on.

What is new

A foundation/ folder holding what the Standard rests on, in three layers: verified first-party sources, the machine-checkable claims, and the conclusions drawn from them. Every source record carries what was read, which version, when, and by what method - because "confirmed on the 19th" describes a page-read and a live experiment identically while distinguishing neither.

tier-basis.md, which records, per tier boundary, the vendor fact it depends on and whether that fact is pinned anywhere. A boundary with no evidence gets a row reading unverified, never an omitted row. An absent row reads as "no boundary here"; an unverified row reads as "a boundary nobody has grounded", which is the finding.

What it found, stated plainly

Every pinned claim in this repository sources from a Claude Code page. There is no pinned claim for any Codex fact and none for any Cowork fact - so the Convergent tier, which is defined as what both agents support in different formats, has pinned evidence for one of them.

The Codex hook event list in our capability matrix was missing an event. The vendor documents eleven; this repository recorded ten. Found by opening the reference and counting.

Two shipped checks accommodate Cowork behaviour the vendor documents nowhere. They are almost certainly correct and they have no expiry, so if that behaviour changed, nothing here would notice.

None of these is fixed in this release. Each is filed, because a boundary resting on nothing is a finding to record, and moving a tier is its own decision with its own migration window.

On the review

Two adversarial waves, a four-lens panel, and a direct probe of the panel's own fixes returned more than thirty findings between them. Several were defects in the fixes for earlier findings - including one that would have blocked every future release the moment a vendor re-rendered a documentation page.

That is recorded in full rather than summarized away, in the release packet's findings ledger, and it is the reason this release took the shape it did.

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.

v1.14.0

1.14.0 - 2026-08-16

Four things the grader was telling you that were not true, and three files it was never looking at.

Do you need to do anything?

No. Nothing here changes your grade until you raise the standard line in your own library.json. If you change nothing, nothing changes.

Unless you have no standard line at all - then you are graded against the newest rules the moment they ship. Add one and pick a version.

One thing is worth checking even if you do nothing: if your plugin has an agents/ folder, read the third section below. It describes files that were shipping and being loaded without anyone noticing.

Four wrong answers, now fixed

Each of these was the grader reporting a problem that did not exist. A false alarm is worse than a missed defect - it costs you time and teaches you to ignore the report.

• "That workflow doesn't exist" - when it did. A command saying maps-to: my-workflow was reported as pointing at nothing.
• "That agent file isn't on disk" - when it was. Honestly declaring agents/_helper.md got you told it was missing.
• "Your description doesn't say when to use it" - said to descriptions that said exactly that, in French. The scorer awarded more than a third of its points for English phrasing.
• "Your command's description is too weak" - it would have been, if we had shipped what we planned. We measured first: 0 of 14 commands in our own reference set would have met the bar we were about to impose. We did not ship it.

Three files your runtime loads and the grader never read

Claude Code registers every .md file under agents/. Not the ones you declared - every one. A folder README.md sitting there becomes a subagent named README, with no description and no purpose, silently.

Check your own agents/ folder. If it holds a README, a template, or a scratch file, your plugin is shipping a phantom subagent right now. The grader now reports these; it never did before.

What deliberately did not change

Your frontmatter can carry whatever keys you like. We considered restricting the vocabulary, and measured before deciding: 44.9 percent of 2342 skills across the ecosystem carry a key our Standard does not name. Restricting would have failed nearly half of everything. We did not.

A marketplace-level problem will never become a requirement on your plugin. If two plugins in a catalogue collide on a skill name, neither author can fix it alone - it depends on who they were listed beside. A requirement you cannot discharge by yourself is not a requirement.

How this was checked before shipping

• Codex was actually run. codex-cli 0.144.5 ingested the emitted .codex-plugin/plugin.json and discovered the skills it points at. Listing is not ingestion, and a test that only checks the file parses has proved nothing.
• 1252 tests, no failures, on Windows and Linux, on Node 22.12 and 24.
• Six plugins in our reference set graded before and after every change. No grade moved.

Where this release came from

Seven decisions were written and measured before any code was written. Three of those measurements overturned the decision they were testing - including the command-description bar that would have failed all fourteen of our own commands.

That is the whole method: write down what you intend, measure it against something real, and let the measurement win. Three times out of seven it did.

v1.13.0

1.13.0 - 2026-08-13

You are now graded against the ruleset you pinned - in both directions.

That was already true for a brand-new check: if your library.json says "standard": "0.12", a check
introduced at 0.13 was reported as a warning, never a gate failure. It was quietly NOT true for a rule
that already existed and was being made stricter. Those took effect for everyone the day the tooling
shipped them.

It also was not true if you had an askit.config.json. Your own per-rule override was applied after the
pin, so it beat the pin - which sounds like a feature until you notice it works in the harmful direction
too: a rule you turned up to error would gate you on a check that did not exist when you pinned.

Both are fixed. There is now one ceiling, it is computed from the version you declared, and it is applied
last - after your profile, your overrides and your suppressions. If you change nothing, nothing about your
grade changes.

What this costs you, and when

Nothing, until you raise your own standard pin. When you do, four things become effective. The full list
with remediation for each is in
Adopting Standard 0.13:

• U13 - every skill directory you ship must be registered in your manifest, and every registered
  skill must exist on disk. This was scheduled for 0.13 when it was introduced at 0.12.
• S4 - a chain declaration written as a string is held to the same bar as one written as an array.
  Also scheduled.
• U14 (new) - an agent shipped inside a plugin may not declare hooks, mcpServers or
  permissionMode. Claude Code refuses these three, in its own words "for security reasons". The field is
  refused rather than ignored, and nothing tells you - so an agent carrying one has configured something
  that is simply not in effect. The toolkit already detected this when grading a catalogue; now it tells
  you when you grade your own plugin, which is how almost everyone runs it.
• selfValidation - a new optional library.json field. You almost certainly want to omit it.

If you have no standard pin at all, none of this protects you. An unpinned plugin is graded against
the current ruleset immediately, because a plugin that never declared which contract it adopted cannot be
graded against the one it adopted. Adding one line fixes it, and the page above leads with this.

Two things that can now fail where they passed

Said plainly, because a guarantee whose exceptions are buried is not a guarantee:

• --strict ignores your pin, by definition, and now ignores the ceilings too. If you run --strict
  in your own CI at an older pin, the newly graduated checks will fail there. That is the flag doing what
  it has always said it does.
• A published verdict can now fail where it passed. In published-verdict mode - the mode for
  publishing a conformance verdict about someone else's plugin - a setting the graded subject wrote
  about itself can no longer weaken an objective or vendor-cited finding. Previously such a setting was
  merely clamped up to a warning, which meant turning the mode on could never fail a passing gate. A
  subject can still be stricter about itself, and any setting you supply as the grader is honoured in
  full. What changed is that a subject cannot grade itself leniently in the one mode built to publish a
  verdict about it.

One thing we fixed that was our fault

gen-index wrote Self-validating: node scripts/check.mjs into every INDEX.md it generated - including
for plugins that consume this toolkit rather than vendoring it, and therefore have no such file. That is a
false instruction shipped inside your repository, over your signature. It now writes
npx agent-skills-toolkit . unless your library.json declares "selfValidation": "vendored".

Regenerating your index is the fix. Until Standard 0.14, an INDEX.md that matches the old rendering
exactly is reported as a warning, not an error, so you are not gated on a defect we caused.

How this release was verified

Cutting a release here means running a checklist where every item is a gated check rather than a
reminder. Two of them are worth stating in public, because they are the ones a reader cannot confirm
for themselves.

The Codex round-trip was run for this tag. The manifest this toolkit emits was installed into a
throwaway local marketplace against the real codex CLI, and the skills were confirmed INGESTED rather
than merely listed - the distinction matters, because a manifest can appear in a listing while the
runtime quietly loads nothing from it. Run against Codex CLI 0.144.5 on 2026-08-14: passing. The
previously recorded verification was against 0.135.0, so this also re-confirms the emission against a
newer CLI.

The branch was adversarially reviewed seven times, not once. Each round reviewed the code the
PREVIOUS round's fixes produced, because that code is otherwise unreviewed - and this project has the
receipts for why that matters: v1.12.0 shipped after a single round and needed v1.12.1 for four more
problems, every one of them inside round-one fix code. The rounds found, among other things, a way to
bypass this release's own new check by putting a restricted field in a file the runtime loads but the
gate was not reading, and a stale count on the front page of the README. Every fix carries a test that
was proved capable of failing before it was trusted.