> This page is for Agent Handler.

> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.merge.dev/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.merge.dev/_mcp/server.

# Reviewing submissions

> How employee-authored skills work in Agent Handler: submitting for review, approving or rejecting a submission, and the resubmit loop.

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](/merge-agent-handler/build/skills/publishing-skills#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.

| Decision | What happens                                                                                                                                  |
| -------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| Approve  | The submitted version is published, gets the next version number, and goes live for agents. The reviewer and time are recorded on the version |
| Reject   | The version is marked rejected with your optional reason. Nothing goes live                                                                   |

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

| Permission          | Can submit     | Can publish                  | Can review |
| ------------------- | -------------- | ---------------------------- | ---------- |
| `manage_own_skills` | Yes, their own | Personal skills only         | No         |
| `manage_skills`     | Yes            | Yes, to the org or any group | Yes        |

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

| Event             | Fires when                                       |
| ----------------- | ------------------------------------------------ |
| `SKILL_SUBMITTED` | An author submits a skill or revision for review |
| `SKILL_APPROVED`  | An admin approves a submission, publishing it    |
| `SKILL_REJECTED`  | An admin rejects a submission                    |

These sit alongside the publishing events on the [Audit Trail](/merge-agent-handler/observe/audit-trail), each attributed to the user who acted.

Next: [How agents load skills](/merge-agent-handler/build/skills/how-agents-load-skills)