Odin Skill Manager

odin-skill-manager

A skill's provenance is not a fact about its content. It is a fact about what may be done to it — and the only place that fact can live is somewhere a gate can read.

What this owns, and what it does not

Four skills already own parts of skill work. This one owns what none of them does: where a skill came from, whether it may be overwritten, whether it is published, and how far it has drifted.

Creating a skill is therefore always two steps: skill-creator writes it, and this registers it. A skill that exists but is not registered is invisible to the gate that decides what a refresh may destroy.

The four classes

The class is derived on every run by .claude/scripts/lib/skill-provenance.sh from four inputs — the vend map, the FROZEN list, an UPSTREAM.md, and mirror membership.

A fifth answer exists and is not a class: undetermined, rc 3. Nothing claims the skill and nothing declares it. It is never folded into authored, because a skill installed by a provisioner looks identical on disk to one written here, and guessing either way protects or exposes the wrong thing. sp_protected_set refuses entirely while any skill is undetermined — a partial protect list is the shape that overwrites exactly the skill nobody could classify.

Precedence, and the one line of it that matters: fork evidence outranks the vend map, because a forked skill is usually still in the map. rules-distill is vended from ECC and forked here.

The commands

bash .claude/scripts/skill-provenance-check.sh                # every skill has a class
bash .claude/scripts/skill-provenance-check.sh --membership   # every owned skill is published
bash .claude/scripts/skill-freshness.sh --quick               # did any upstream move (17 ls-remote)
bash .claude/scripts/skill-freshness.sh --deep                # which skills differ, and by how much
bash .claude/scripts/skill-freshness.sh --deep --only <name>  # one skill
bash .claude/scripts/vendor-skills.sh --print-map             # the upstream map, TSV, no network
bash .claude/scripts/vendor-skills.sh --refresh               # replace vendored skills only
bash projects/Odin-Skills/scripts/sync-from-odin.sh --check   # mirror drift
bash projects/Odin-Skills/scripts/validate-skills.sh          # the mirror's own gate

Exit codes are the interface. skill-freshness separates 1 (a vendored skill is behind) from 3 (an upstream could not be read) on purpose: "it moved" and "nobody could tell" are different sentences, and only one of them is a finding about a skill.

The five operations

1. A new skill

1. skill-creator writes it. This skill does not author bodies.
2. Register it: skill-provenance-check.sh must pass. An Odin-authored skill classifies as authored only once it is a mirror member — until then it is undetermined and needs a declared row, which is a debt, not a record.
3. Publish it: references/membership-runbook.md.
4. Route it. A skill nothing names is a skill nothing fires — skill-registry-coverage.sh and skill-routing-check.sh hold that.

2. Forking a vendored skill

Full procedure: references/fork-runbook.md. The short form — the edit is the last step, never the first:

1. Decide fork vs freeze. A freeze says "stop re-pulling this"; a fork says "Odin maintains this now and republishes it". Publishing someone else's skill has a licensing story; freezing does not.
2. Write UPSTREAM.md before editing the body: upstream, the sha forked from, and what a porter must read first.
3. Verify the class flipped: sp_class must report forked, and the protect list must contain it.
4. Publish, with the upstream LICENSE beside the UPSTREAM.md — or, where upstream published none, the literal declaration no LICENSE file accompanied plus a NOTICE.

3. Refreshing vendored skills

references/refresh-runbook.md. Never hand-edit a vendored body: the next refresh reverts it, silently, and the finding closes while the cost comes back. Two edits are applied mechanically by vend() for exactly that reason — the frontmatter name: rewrite, and stripping disable-model-invocation: true.

4. Publishing to the mirror

projects/Odin-Skills/ is a one-way publication of .claude/skills/; the harness is authoritative. A change made in the mirror is destroyed by the next sync. Membership is a rule, not a list (odin-skills:ADR-0003), and --membership is its predicate.

5. Retiring a skill

Deletion is not enough. Remove it from the vend list with the reason inline, or the next run re-vendors it — grill-me was re-created on every run for weeks after being retired. Then: mirror member removed, registries updated, CHANGELOG.md records it.

Red flags

Reference