> This page is for Workforce.

> 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 Workforce: submitting for review, approving or rejecting a submission, and the resubmit loop.

The people who know a procedure 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.

Skill submissions also show up as a tab on [Requests](/merge-workforce/requests), next to the tool access requests employees file. Review them wherever you already work.

## Submitting a skill

An employee 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 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-workforce/skills/publishing-skills#who-a-skill-reaches).

## Reviewing

Pending submissions sit under the **Review** tab, badged **Pending**. Open one and you get the submitted version's full `SKILL.md`, its file list, and who submitted it. Decide from the drawer, or from the card's menu without opening it.

| Decision            | What happens                                                                                                                                   |
| ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| Approve and publish | 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 and stays in the **Review** tab badged **Rejected**, with your reason on a banner at the top of the drawer. The author uses **Edit and resubmit** to file a corrected version, which arrives back in your 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 **Published** and **Review**, because both facts are true. Opening it from **Review** shows the version awaiting your decision rather than the one agents are reading. 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-workforce/logs/audit-trail), each attributed to the user who acted.

## Next

See what an employee's AI client actually does with a published skill in [How agents load skills](/merge-workforce/skills/how-agents-load-skills).