Versions and lifecycle

You need a Semogram account with membership in the target workspace and access to a project in it. The Skills screen is opened from a project, while standalone skills belong to the workspace.

A standalone skill has a stable asset ID, branches, immutable saved package revisions and an active version. The editor's unsaved files are different from its saved package. Plugin skills instead follow their parent plugin and are read-only in this workflow.

Saving changes makes them active

Creating a skill establishes a saved version. The current standalone update flow commits the package and sets that new revision as active by default. Do not use Save changes as though it only stages an inactive proposal; review changes before saving, especially when other projects share the skill.

A commit message explains the change and is not part of the skill body. The saved result includes the skill/asset ID, version ID and parsed package summary. Reopen it and check that the active content is what you intended.

Compare before changing guidance

Open the standalone skill, inspect History, and use the version's compare control. Comparison identifies added, removed and modified paths; read the actual content on both sides. Supporting-file changes matter even when SKILL.md is unchanged.

For example, adding a rule to distinguish observations after the prediction cutoff should produce a visible instruction or checklist change. Merely changing a skill name does not establish that reviews improved.

Restore an older version

Open a historical version to inspect it. Historical tabs are read-only. Activate the selected older version through History when its package is the intended guidance. Activation updates the active package and summary, without deleting newer history or rerunning prior tasks.

Record the version IDs before and after the change. Repeat the fictional pump-17 review from your first skill: the 2 October observation must be distinguished from the 1 October cutoff, and probability 0.70 must not become a claimed observed failure.

Branches

Standalone assets support branch history and comparisons. Branch names use lowercase letters/numbers/hyphens and can start from a chosen saved version. Branch creation is not a clone of an entire workspace. The exposed UI may offer history/compare without a complete branch-management surface; do not assume every underlying session route is a public API.

Remove a skill

Inspect consumers and dependencies before using Delete skill. Governed deletion can reject removal, and plugin skills must be managed through their parent plugin. Confirm the actual deletion result; closing an editor tab only closes a view.

MCP exposes skill_delete with org:manage, confirmation and an idempotency key. Use interfaces for its exact request and workspace/project context. There are no public skill version or deletion HTTP routes under /api/v1.