The Lab reviewer

When someone in the network writes a skill and sends it in, something has to check it before it reaches everyone else. That job used to be a person reading the file. Now most of it runs by itself, including the fixing. A person is asked only when the answer is a judgement rather than a rule.

You do not need to read any code to follow this page.

The important part: a failing check is not a rejection

Almost everyone who sends a skill has never written one before. Their first attempt will have the wrong kind of name, no routing lines, and missing metadata. That is not a mistake to correct them on. That is what a first skill looks like.

So the reviewer's job is repair, not triage. It reads what failed, fixes it, and pushes the fix to your branch. A reviewer that replied "your skill fails check G3" would be handing the work back to the one person who could not do it, and the contribution would die there. That is the failure mode this design exists to avoid.

You do not have to get it right. You have to send it.

Two layers, and why they are separate

Layer	What it does	When	Cost
Automated checks	Everything mechanical: names, metadata, safety, the catalogue, broken links, whether the plugin still loads	Every contribution, and every change to the main branch	Nothing. It is scripts
The reviewer	Fixes what the checks found, then judges what a script cannot: does it work, is it a good idea	Once per contribution	One agent run

The rule between them: the reviewer never re-runs a check. It reads the result and spends its attention on the questions a script cannot answer. Two things measuring the same property will eventually disagree, and then nobody knows which to believe.

What happens after you open a pull request

1. The checks run. Eight of them, in about a minute. Several will probably fail. Expected.
2. The reviewer wakes and waits for them to finish, then reads exactly which ones failed and why.
3. It repairs. Renames the skill to the house pattern and updates every reference. Adds the routing lines that tell it apart from its neighbours. Fills in the metadata. Restructures the body into the standard shape. Regenerates the catalogue so the skill appears in the right place.
4. The checks run again, on the repaired version. If something still fails it repairs again, up to three rounds. Three rounds on the same check means it has misunderstood something, and it asks you instead of trying a fourth time.
5. It uses the skill. Not "does it look right": it runs the skill on a real question and compares the answer against not having the skill at all. This is the part that produces a claim worth reading.
6. It writes to #ai-lab. Five lines, ending in a link to the thing to merge.

What it will not do

It will not merge your contribution. Repairing and pushing is authorised; merging is not. You press merge, and that is what keeps the repair reviewable. An agent that both rewrote the work and shipped it would have nobody checking either half.

Some changes do land without a person, and none of them is your contribution. The nightly audit fixes its own dead links and stale pointers, where nothing can break. And a bug reported as an issue can go all the way through when it is provably safe — a typo, a dead link, or a chart and diagram bug with an automatic test — but always through two agents, never one. The issue reviewer traces the bug, writes the fix, renders every affected chart type, and opens a pull request with the measurements attached; it is not allowed to merge. The pull-request reviewer — a separate agent that never saw the fix being written — reads that evidence and merges only if the proof holds, cleaning up the branch as it goes. If anything is unproven, it stays open for you. Every change that lands this way is announced in #ai-lab the same day — an unannounced automatic change does not exist here.

It will not recommend merging a broken contribution. If the checks are still failing, or have not finished, it does not say "ready". That one output would destroy the whole thing's usefulness in a single message.

It will not change what your skill is for. It fixes how a skill is written, never what it does. If the scope looks wrong, that is a question for you.

It will not touch a credential quietly. A password or API key inside a contributed file is public the moment the contribution exists. That stops the pass immediately, and the key has to be replaced, not deleted. Deleting it from the file does not remove it from the history.

It will not decide whether your skill is a good idea. No checker will ever have that, and it is the most common reason a technically clean contribution should not land.

What reaches you

Two things, written for two readers.

On your pull request itself, a note written for you: whether your skill works, with one concrete thing the reviewer saw when it ran it; what it fixed for you, and that needing those fixes is normal; the one thing worth knowing, if there is one; and that nothing more is needed from you. Usually it reads like: "Your skill works — I ran it and it pulled the 2024 tariffs with sources. I fixed the name and the formatting; every first skill needs that. One thing: it only covers France and Germany, so I said so in the description. Nothing more needed from you — a person presses merge." The technical detail sits folded underneath for anyone who wants it; you can ignore it entirely.

And one message in #ai-lab per contribution, for whoever presses merge. Five lines, no jargon, no check names. Almost always this shape:

Ludovic sent a skill that pulls national grid-fee data for a brief. It works. I ran it and it returned the 2024 French and German network tariffs with sources; without it the same question came back with unsourced estimates. I renamed it to search-grid-fees, added the routing lines and the metadata, and tidied the body into the house structure. It only covers France and Germany, and says so in its description now. Nothing to check. Just merge it: link to the pull request

When a real decision is needed, the last line becomes a question with both sides of the trade-off named, rather than a recommendation. That shape is rarer, which is what makes it worth reading when it appears.

The other two routines

Nightly audit. Checks whether the repo has drifted — a document nobody references any more, a pointer to a file that moved, a skill whose description no longer matches what it does. Mechanical fixes arrive as a pull request with no announcement. It posts to #ai-lab only when something needs a person, so most nights you hear nothing. That silence is the feature.

Issue reviewer. Wakes the moment an issue is opened, plus one morning sweep on weekdays for follow-up replies it would otherwise miss. It tests whether the problem is real and comments what it found; for the provably safe bugs it also writes the fix and hands it to the pull-request reviewer, as described above. It never closes or edits an issue, and it never merges anything.

What this does not promise

The automated checks catch mechanical faults. The reviewer catches whether the skill works, and repairs what the checks found. Neither catches whether the skill should exist, whether its method is sound for your field, or whether it quietly duplicates something you already use. Those stay with the Lab, and they are the reason a human still presses merge.

If you contribute

Write the skill however you can. Use skill-builder if you want a starting shape, or write it badly and send it anyway — the reviewer expects that. Do not polish it to pass the checks; that is the reviewer's job, and it is better at the conventions than any of us are at remembering them.

The one thing worth your care is the description: the trigger phrases are how the assistant knows when to fire your skill, and no automated pass can guess what you meant it for.