Reviewing submissions
The people who know a workflow best are usually not the people with admin rights. Employee authoring closes that gap: anyone with manage_own_skills can write a skill and submit it, and an admin with manage_skills decides whether it gets published.
Use it when your library should grow faster than your admin team can write it, and you still want one gate before agents read anything.
Submitting a skill
An author uploads a skill exactly as an admin does, then chooses Submit for review instead of publishing. The skill lands in review and stays invisible to agents.
Authors see their own drafts and submissions in the dashboard, alongside the published skills everyone can see. They do not see other people’s in-flight submissions.
Review is only for skills that reach other people. An author who scopes a skill to Only me publishes it directly, because there is nobody else to protect. Everything wider, org-wide or group-scoped, goes through an admin. See Who a skill reaches.
Reviewing
Admins see pending submissions under Review. Open one and you get the submitted version’s full SKILL.md, its file list, and who submitted it.
Approving publishes the skill at the reach its author chose, not org-wide by default. A submission scoped to two groups goes live to those two groups. Check the Visibility row in the drawer before you approve, because approval does not let you change the reach, and neither does a later version.
Write a reason when you reject. It is the only thing the author gets back, and it is the difference between a fixed resubmission and a repeat.
Rejection and resubmit
A rejected submission stays with its author, who sees it in the dashboard with your reason attached. They fix the skill and submit a new version, which arrives back in your Review queue.
Rejection is not deletion. The rejected version stays in the skill’s history, so the trail of what was proposed and turned down survives.
Revisions over a live skill
An author can submit a revision to a skill that is already published. That submission does not disturb the live skill: agents keep reading the published version for as long as the revision sits in review.
A skill in that state appears under both Publish and Review, because both facts are true. Approving swaps the live version to the reviewed one. Rejecting leaves the published version exactly where it was.
Who does what
An author with manage_own_skills can add a version only to a skill they created. Attempting it on someone else’s skill returns not found rather than a permission error, so one author cannot probe for another’s work by slug.
What gets audited
These sit alongside the publishing events on the Audit Trail, each attributed to the user who acted.
Next: How agents load skills