Reviewing submissions
The /admin queue, a check-before-approve rubric, decision mechanics, and per-version re-review semantics.
This page describes the moderator workflow. It's public so authors know what reviewers are looking for, but only operators with admin permission can act on the queue. See Admin access for how admin is granted.
The queue
Open /admin when signed in as an admin. The left pane shows
every listing with status = pending_review, oldest at top. Click a
row to inspect it on the right — title, slug, kind, publisher GitHub
login, summary, tags, full README (collapsed by default), and every
submitted version with its semver, changelog, and full payload JSON.
What to check before approving
A short rubric — adjust per your deployment's risk appetite:
| Check | Why |
|---|---|
| Manifest schema is valid | The SDK validates on publish, but an out-of-band POST could bypass. Re-validate via enclaw-mp validate if anything looks off. |
| Payload matches the kind | A skill listing whose payload shape looks like an agent template is a bug or a smoke test. Reject with notes. |
| No secrets in the payload | Skills sometimes accidentally bake an API key into the entrypoint or the toolSchema description. Search the payload + readme for things that look like sk-…, Bearer …, AKIA… etc. before approving. |
| README has install instructions | Especially for integrations that need OAuth setup — without instructions, every install support-tickets you. |
| License is compatible | Inline-bundled code (skills with embedded npm modules in the payload) needs a license callout in the README. Reject anything that looks like GPL-only code with no carve-out. |
| Tags are sensible | Bad tags ruin search. Five tags max, all lowercase, no #hashtag-style, no marketing fluff. |
| Required integrations exist | If an agent template lists requiredIntegrations: ["pagerduty"] and PagerDuty isn't on this deployment's catalog, installs will silently fail. Cross-check. |
Decisions
Two buttons on the inspector pane:
- Approve & publish → status flips to
approved, listing appears in the public catalog immediately, version becomes installable. The publisher sees green on their My Listings dashboard. - Reject → status flips back to
rejected. Publisher can edit and resubmit; goes back topending_reviewand reappears in your queue.
Reviewer notes
The textarea on the inspector pane is visible to the publisher on their My Listings page. Use it liberally:
- On rejection: explain why and what to change. Without this, the publisher just resubmits the same broken thing.
- On approval: occasional positive notes ("nice README", "useful test cases in payload") set the bar for future authors.
Versioning + re-review
Every submitted version gets its own pending-review pass — approving
v1.0.0 doesn't auto-approve v1.1.0. The listing itself stays
visible the whole time (still at v1.0.0 for installers) while the
new version sits in the queue. When you approve the new version, it
becomes the default for new installs; existing installs on the old
version keep working unless they opt in to update — see
Updates + uninstall.
Backlog hygiene
- Aim for < 48h queue depth. A submission queued for a week trains authors to give up. If you can't review within 48h, drop a comment on the GitHub issue tracker (or your team's chat) and ping another admin.
- Inbox zero is the target. The queue is small enough on day-1 that you should empty it at the start of each operator shift.
- Rejected ≠ dead. A rejected listing is editable by the publisher and can be resubmitted. The reject button isn't "delete".