Create and publish a skill

Before you start

You need an account role with access to agency settings, and a plan with the managed_skills feature. The catalog lives at Settings → Skills.

Create the skill's identity

Click New skill. Three fields define the skill's identity, and two of them are permanent:

• Name — the display name. You can rename freely; installed clients see the new name on their next fetch.
• Slug (permanent) — the identifier installed clients reference forever. It can never change, so pick it the way you'd pick an API name: lowercase, hyphenated, specific (weekly-pipeline-digest, not digest2).
• Description (frozen once granted) — what a client's model reads to decide whether to use the skill. Once any client holds a grant, the description is frozen: editing it would strand every installed artifact.

Write the first draft

The skill detail page opens with a New draft form:

• Instructions (markdown) — the procedure the client's assistant follows after fetching the skill. Write it the way you'd brief a careful colleague: numbered steps, exact expectations, what to do when something is blocked.
• Bound workflow slugs — if the procedure calls your workflow tools, reference them in the instructions by their taskjuice_<slug> names and list those base slugs here. Bound slugs become the licensed surface: those tools are gated so only workspaces granted this skill can call them.
• Changelog note — one line describing what this version changes. Clients' assistants can read the changelog; write it for them, not for your git history.
• Procedure builds or edits workflows — enable only if the procedure drives workflow authoring (creating or editing workflows over MCP). Authoring is available to agency operators only, never to client principals.

Create draft saves version 1 as a draft. You can keep editing a draft with Save draft; drafts are invisible to clients.

Publish

Each draft in the Versions list has a Publish button. Publishing makes that version active — the one every install fetches — and immutable from that point on. To change the procedure, write a new draft and publish it. To undo a bad release, publish a rollback: rolling back re-activates the old version, it never edits one. The version list is your audit record of exactly what clients' assistants were told, and when.

Publishing may attach two non-blocking advisories:

• Description frozen — you published into existing grants, so the identity your clients installed can't follow any scope change in this version. If the skill's job genuinely changed, that's the signal to consider a new slug.
• Ungated tool copies — a workflow bound by this skill has MCP-enabled copies in workspaces that don't hold a grant. Those copies remain callable outside the skill's license. The toast names the workspaces so you can grant them or disable the copies.

Archive

Archiving a skill (the Archive action in the catalog) frees a plan slot and removes it from every catalog surface. It is refused while any client grant is active or suspended — revoke grants first, deliberately, so no client loses a skill as a side effect.

If the skill's bound workflows still have MCP-enabled copies, the archive dialog shows a widening report: with the skill gone, those tools stop being licensed and become plainly callable in their workspaces. The one-click Disable tools action flips the named copies off before you archive.

Plan slots

Non-archived skills count against a per-account ceiling (Growth 25, Scale 100). Archived skills cost nothing and keep their version history.