Guides
Skills
Personal, Workspace, and Explore skills; who can create, publish, and moderate them; and how skills reach Spec, the API, and Developer MCP.
A skill is reusable instructions written in Markdown. Spec loads the skills that apply to what you are doing, so you stop re-explaining the same procedure.
Skills live in one place in the product. There is a single Skills destination in the sidebar, and no duplicate under Settings.
Three scopes
| Scope | Who sees it | Who can change it |
|---|---|---|
| Personal | only you | only you |
| Workspace | every member of the workspace | the creator, any maintainer, and workspace admins |
| Explore | everyone, read only | Parcel |
A Personal skill is genuinely private. Another member cannot read it, cannot list it, and cannot reach it by guessing its id: the answer is the same “not found” they would get for a skill that does not exist, so its existence is not leaked by the shape of the refusal.
Writing a skill
Two ways, and one of them costs nothing.
- Write it yourself. Editing Markdown directly uses no model credits at all. Create, edit, save, publish: none of it calls a model.
- Ask Spec. Create with Spec and Improve with Spec draft or revise a skill for you. These DO use credits, because they are model work like any other.
Either way the result is a draft. A draft is yours until you publish it: it is never discoverable, never loaded into anyone’s run, and never visible to another member.
Publishing
Publishing is a confirmed act. Spec cannot publish a skill on your behalf as a side effect of a conversation. The confirmation names the skill and the scope you are publishing into, and you accept it.
Each publish creates an immutable revision. Revisions are never rewritten, which is what makes the next section possible.
Revisions, conflicts, and run pins
- Conflict. If someone else revised the skill while you were editing, your save is refused with a conflict rather than overwriting theirs. Re-read and reapply.
- Restore to draft. A published revision can be brought back as a draft and worked on again. The published revision is untouched until you publish a new one.
- Run pins. A conversation that loaded a skill keeps the exact revision it loaded, for its whole life. Publishing a new revision never changes what an older conversation was working from.
Moderation and transfer
A workspace admin can unpublish or delete a Workspace skill, and can transfer maintainership to another member. The creator is recorded separately from the maintainer, so a transfer does not rewrite who wrote it.
Official skills
Parcel publishes skills with recorded provenance: a release tag, a commit, and a checksum for the exact bytes. When a skill is installed or forked from the official source, that provenance travels with it, so you can always answer where a skill came from and whether it has been changed since.
If Parcel’s published catalog cannot be verified, the official source reports itself unavailable rather than serving different bytes than the ones it promised.
Skills on other surfaces
Skills are not a web-only feature. The same lifecycle is available through the Workspace API and through a Developer MCP grant:
- 25 Workspace API routes under
/workspace/skills, covering five reads (including revision history) and ten writes, each with a single-record and a batch form. - 14 Developer MCP tools covering the same lifecycle.
Both surfaces enforce the same authorization as the web app. A grant issued before skill support existed offers no skill tools at all until it is reauthorized, and reads and writes split exactly on the two skill scopes, so a read-only grant cannot write.
Skills and privacy
Skill content is content. It is never sent to analytics, never written into an error message, and never included in an audit record. Deleting a skill deletes its body; the metadata that proves a run happened remains, because a usage record that could be erased is not a usage record.
Hidden system skills that Parcel uses internally never appear in discovery.