Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/org-quicko/skillset/llms.txt

Use this file to discover all available pages before exploring further.

A Submission is created when a signed-in User runs skillset install <url> — the CLI clones the repository, installs the Skill locally, and simultaneously forwards it to the Registry for admin review. Any authenticated User (even a reader) can submit, because submitting publishes nothing. The Skill only enters the Registry catalog — and becomes discoverable and installable by the whole team — when an Admin approves it. This page covers the full Submission lifecycle from initial install to catalog entry.

​
What a Submission Is

Not a Resource

A Submission is held separately from the catalog. No one can browse, search, or install it until an Admin approves it. It is pending — not published.

Carries a future identity

Every Submission records the (kind, namespace, name) it would have as a Resource. The Namespace is derived from its source repository URL — the same way a direct publish derives it — so the final Resource lands exactly where a manual publish of the same source would have.

Idempotent by identity

Submitting the same URL again replaces the existing pending Submission. Only the latest copy is reviewed; earlier submissions don’t accumulate.

Credited to the submitter

On approval, the new Resource is credited to whoever submitted it. The submitter’s email and display name are recorded as the publisher.

​
The Submission Lifecycle

skillset install <url>
        │
        ▼
  CLI clones repo
  Skill written to .agents/skills/<name>
  Submission sent to Registry
        │
        ▼
  Lockfile records:
    source = <repo url>
    no Registry revision (pending)
        │
        ├─── Admin rejects ──→ Submission deleted
        │                      Local install unaffected
        │
        └─── Admin approves ──→ Resource created in catalog
                                submitted_by = submitter
                                │
                                ▼
                          skillset update reports:
                            status = outdated
                          Run `skillset update` to switch
                          local copy to Registry's copy

​
Status during the Submission workflow

skillset update reports the status of every installed Skill by comparing the local copy against the Lockfile and the Registry. For a URL-installed Skill that has been submitted but not yet approved:
StateWhat skillset update reports
Submitted, awaiting reviewpending — no Registry revision to compare against
Approvedoutdated — Registry revision now exists and local copy predates it
Rejectedpending — the Submission is gone but the local install is unchanged
Once the status is outdated, running skillset update replaces the locally-cloned copy with the Registry’s canonical copy, and the Lockfile is updated to point to the Registry revision.
Rejection does not remove the Skill from the submitter’s machine. The local copy remains installed and functional. The submitter can re-submit it, or keep using it as a URL-installed Skill indefinitely.

​
Reviewing Submissions

Admins review pending Submissions from Settings → Submissions. Each Submission shows:
  • The Skill’s name, description, and body content
  • The source repository URL it was cloned from
  • The Namespace and (kind, namespace, name) it would occupy as a Resource
  • Who submitted it and when

​
Approving a Submission

1

Open the Submission

Go to Settings → Submissions and select the Submission you want to review.
2

Review the content

Read the Skill’s description and body. Check the source URL — it records where the bytes came from. Verify that the (kind, namespace, name) identity is appropriate for your Registry.
3

Approve

Click Approve. The Submission’s files are copied into the new Resource’s storage prefix, the Resource row is created, and the Submission is deleted.
4

Notify the submitter (optional)

The Registry sends no email. If you want the submitter to know their Skill was approved, notify them through your own channels. They will see the status change to outdated the next time they run skillset update.

​
Rejecting a Submission

Click Reject on the Submission. This deletes the Submission and its uploaded files. The submitter’s locally-installed copy is unaffected — they can continue using it or re-submit it.

​
API

curl https://your-registry.example.com/api/submissions \
  -H "Authorization: Bearer <token>"

curl -X POST https://your-registry.example.com/api/submissions/<id>/approve \
  -H "Authorization: Bearer <token>"
Reject a Submission
curl -X DELETE https://your-registry.example.com/api/submissions/<id> \
  -H "Authorization: Bearer <token>"
A successful rejection returns 204 No Content.

​
Response fields

​
id
string
The Submission’s unique identifier (UUID).
​
kind
string
Always skill — only Skills can be submitted via URL install.
​
namespace
string
The Namespace the Resource would occupy, derived from the source repository URL.
​
name
string
The Skill’s name, as parsed from the SKILL.md frontmatter.
​
description
string
The Skill’s description, as parsed from the SKILL.md frontmatter.
​
source
string
The repository URL the Skill was cloned from. Always a repository URL — a Submission can only exist because the bytes came from somewhere other than this Registry.
​
allowed_tools
string | null
The allowed-tools value parsed from the Skill’s SKILL.md frontmatter, or null if none was declared.
​
submitted_by_email
string
The email address of the User who submitted the Skill.
​
submitted_by_name
string
The display name of the User who submitted the Skill.
​
submitted_at
string
ISO 8601 timestamp of when the Submission was created or last replaced.

​
Constraints and Edge Cases

Approval is refused with a conflict error if a Resource of the same (kind, namespace, name) already exists at the time of approval. The Submission is left in place — an Admin can reject it manually once the conflict is resolved or understood.
Approval is refused if none of the Skill’s files were uploaded to object storage. The CLI uploads files as part of skillset install, so this should not occur in normal use — but a Submission created via direct API call may be in this state. Re-submit with the correct files to resolve it.
No. Only Skills can be submitted via skillset install <url>. Plugins and MCP Servers are published directly by Writers using the CLI or web interface.

​
API Reference

All Submission management endpoints require an admin role.
MethodPathRole requiredDescription
GET/api/submissionsadminList all pending Submissions
PUT/api/submissions/:kind/:nameany authenticatedSubmit a URL-installed Skill for review
POST/api/submissions/:id/approveadminApprove a Submission, creating a Resource
DELETE/api/submissions/:idadminReject and delete a Submission

Build docs developers (and LLMs) love

Get started for freeTalk to us