Two-way sync

A skill you install is a skill you can improve. This release closes the loop between consuming one and shipping a change back to it.

Highlights

• Edit a skill where it lives. Every install records a content baseline for the directory it writes, so a skill in the store reads as either clean or modified. skillhub list and skillhub doctor report which. A run that would replace or delete a modified skill asks first, and answers STORE_MODIFIED when it has no way to ask, so skillhub sync, --prune and skillhub remove leave your work where it is. Pass --discard-modified to take the published version back.

• Publish without retyping where it came from. skillhub publish resolves the target registry from that skill's own lockfile entry, so a managed directory needs no --to. The version advances on its own: --bump defaults to a patch derived from the lockfile, with --bump minor and --bump major when the change earns one. Your SKILL.md stays as you wrote it, since the version and the target are recorded in the lockfile.

• Sync in both directions. A terminal run lists the skills whose content you have changed and asks which to publish. --publish takes all of them. A scripted or piped run publishes nothing, so a sync in CI converges your tree and never writes to a registry. Per-skill outcomes arrive in the --json payload, and one skill failing to publish leaves the rest to go.

• On a registry that requires review. Your publish is accepted and held: the version lands untagged and waits for a registry admin to move the tag onto it, which is the approval. Later runs report the skill as awaiting review rather than offering it again, and the notice clears once the tag moves.

• Publish flags apply wherever a skill lives. --version takes a semver in either spelling, --version 2.0.0 or --version=2.0.0. --tag and --type reach a managed directory as they do an authoring one, so a channel publish lands on the channel you name.

• Frozen mode reads the store. --frozen fails when the lockfile would change or when a skill in the store carries local edits, so a green CI check describes a tree that still matches what was published. It reads the store on the machine running it, so on a fresh checkout there is nothing to compare.