fix(orca-skills): return orca-cli to revision 37

[UnbreakableMJ]

What Orca reported

All three vendored Orca skills came back as Skipped — the copy here doesn't match the official version — it may be modified, or a different skill with the same name.

What was actually true

Two of the three were neither modified nor different. The installed app ships resources/skills/snapshot-registry.json, which carries every historical revision with per-file hashes — not just the current one. Hashing each vendored SKILL.md against it identifies exactly which revision a copy holds:

Skill	Vendored revision	Latest	Verdict
computer-use	8	8	already current, byte-identical
orchestration	28	28	already current, byte-identical
orca-cli	36	37	one release behind — the deliberate pin from a46c108

Nothing was hand-edited. That distinction — "one release behind" vs "someone edited it" — is one the Orca dialog does not draw.

Why the pin is released

a46c108 pinned orca-cli to 36 on 2026-08-19 because revision 37 advertised share skills while the installed binary's orca skills offered only list, get, install and update — the skill described a command that did not exist.

The app has since been rebuilt (AppImage dated 2026-08-22):

$ orca skills --help
  installed          List installed skill selectors
  share              Publish explicitly selected installed skills behind one unlisted link
  ...

Its manifest now lists orca-cli at revision 37. Both halves of the 2026-08-19 reasoning have reversed — staying at 36 is now what produces the warning and the inaccuracy. The pin was always a hold, not a destination.

Revision 37 differs from 36 by exactly two lines (skill sharing and share skills added to the description). Rendered description is 813 chars, inside the §5.6 cap. Vendored verbatim and hash-verified against exactSha256 cdd5d9c8… / 3944 bytes, so this stays a verbatim vendoring rather than an adaptation (§4.2).

A documented claim this disproved

CREDITS.md said a hash match "means Orca will leave the tree alone". It does not — computer-use and orchestration matched exactly and were skipped anyway.

The cause is the install location, not the bytes. orca skills installed attributes all three to Codex home — ~/.agents/skills, a symlink into /nix/store, a read-only filesystem Orca never wrote to and cannot write to. Orca skips what it does not own and reports it with the only message it has.

Two consequences now recorded in CREDITS.md:

1. The dialog's advice must not be followed. "Remove it if you want Orca to update this skill" is not actionable — nothing can be removed from a store path, and a Home-Manager switch would restore it.
2. This tree will report Skipped on every Orca update, permanently, by design — the accepted cost of the flake.nix vendoring rationale (Orca resolves skills by exact leaf name, so they must sit wherever agents read skills from). The hash check is the thing to run; the dialog is not evidence of damage.

Verification

nix build .#skills produces a tree whose three Orca leaves all match the installed app's manifest:

computer-use     rev 8   MATCH
orca-cli         rev 37  MATCH
orchestration    rev 28  MATCH

reuse lint, check-license-files.py and generate-steelbore-scm.py --check pass. validate-configs.py passes with pyyaml present.

check-skill-refs.py exits 1 identically with and without this change — seven pre-existing findings, all in chat/*.texi, untouched here.

🤖 Generated with Claude Code

https://claude.ai/code/session_017hj64PwFDDJsNdAJoEuYpB