Publish, archive, and restore skill versions
Move a skill version through publication, archival, and restoration without losing track of the released revision.
Publish a tested draft, archive a skill that should no longer be active, and restore it when work needs to resume. This guide uses the authenticated skill lifecycle endpoints so you can identify the exact version affected by each change.
Before you begin
You need to be signed in and have access to the skill. Obtain the skill ID and the draft version ID from your skill workflow before you publish; these are different identifiers. Complete your review before publication because a skill version is the release unit, while archive and restore operate on the skill.
fetch requests and your existing signed-in session. They do not imply that an API key works for these routes.Understand the lifecycle
Publication identifies a specific version to release. Archival changes the containing skill's availability, and restoration returns that archived skill for further use. Restoring a skill does not select or publish a different version.
The arrows show which identifier each operation consumes. If you need to revise released content, make the change in a draft and publish that draft as the next version rather than treating archive and restore as version-editing operations.
Move through the states
Review the draft's instructions, input and output schemas, allowed tools, and approval actions. Record its version ID only after you have chosen the exact draft to release.
This prevents a similarly named or older draft from becoming the published version. If two candidates need a field-by-field review, compare the skill versions before continuing.
Send the skill ID in the route and the selected version ID in the JSON body:
const response = await fetch("/api/skills/skill_example/publish", {
method: "POST",
credentials: "include",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ versionId: "version_draft_example" }),
});
const result = await response.json();
if (!response.ok || !result.success) {
throw new Error("The skill version was not published");
}Replace both example identifiers with IDs from your environment. A successful response has success: true and returns the published version in data.
Refresh the skill's version history and match the published entry to the version you selected. Check the version identifier rather than relying only on its display name or position in the history.
The intended revision should now be the published release. If it is not, stop before archiving or starting another release operation.
When the skill should no longer remain active, send an authenticated request using the skill ID:
const response = await fetch("/api/skills/skill_example/archive", {
method: "POST",
credentials: "include",
});
const result = await response.json();
if (!response.ok || !result.success) {
throw new Error("The skill was not archived");
}The response returns success: true with the archived skill in data. Archiving targets the skill, so the request does not include a version ID.
When work on the skill must resume, post to its restore route:
const response = await fetch("/api/skills/skill_example/restore", {
method: "POST",
credentials: "include",
});
const result = await response.json();
if (!response.ok || !result.success) {
throw new Error("The skill was not restored");
}A successful response has success: true and includes the restored skill in data. Reopen the skill and inspect its version history before making or publishing further changes.
Verify the lifecycle
Troubleshoot state changes
Next steps
Use Compare skill versions to review the released revision against the next candidate, or Manage skills to continue organizing the skill.