What review checks

The archive itself, and the one-line summary you wrote for it. The reviewer checks that the summary describes the pack in front of them: the skills it names are the skills the zip ships, a stated count is the count, and every handle it claims belongs to an account.

They also read the README the way a stranger would. A quickstart nobody can follow is not grounds for refusal, but it is the most common thing a reviewer asks to have changed, and the change is usually two lines.

What review is not: a judgement of your agent's quality, or a test of whether the work is any good. It checks that the pack is what it says it is, that it arrives in one piece, and that it is yours to publish.

Three things, in the order they turn up.

Summary: "Five skills for reading invoices, matched to purchase orders."
The zip ships: skills/read-invoices/, skills/match-to-po/   — two, not five

Summary: "Add @sam when it goes up."
@sam: no account holds that handle, so the upload is refused at the door

• A summary that disagrees with the archive: a skill it names that the zip does not ship, a count that does not match, a handle nobody holds.
• Something that is not a pack: no README, or an archive whose root is a pile of files rather than one folder.
• Somebody else's work presented as yours. Adapted packs are welcome, and the summary is where you say whose work you started from.

One of those three has a published shape behind it. A pack is a folder with a SKILL.md in each skill, and a name and a description in that file's frontmatter (the specification); an archive that does not match it fails on structure before anybody reads the prose.

A refusal is not a public verdict. The reviewer's note goes to the uploader in the same message, and that message is the only place it appears. Nothing on the site grades a pack or publishes why one was turned down.

Reviews turn up small things in packs that are otherwise fine: a link that has moved, a command with a typo, a file named in the README that the archive spells differently.

When that happens, one of two things does. The maker is asked to fix it, or we fix it ourselves and publish the change as a new version. Either way the template keeps its record: every version, the change note that came with it, and who uploaded it. A corrected template is visibly a corrected template.

So the maker owns the work, and we keep the order on the page. That is the honest split, and it is why a version number here is worth reading before you pull an update.

A decision is made on one version, and it is one of three: approved, held for a change, or rejected. Approval publishes that version with a build number and a change note.

Until a decision lands, the row under Studio reads Awaiting review. Afterwards it says which of the three it was, and a rejected pack that can be fixed carries the way back to the upload form with it.