spine-rigc 1.0.2 → 1.2.0

package/README.md

@@ -146,8 +146,9 @@ to do with it, and it is the one instrument here that can see a wrong animation.
 
 The guides under [Documentation](#documentation) also ship as
 [Agent Skills](https://agentskills.io) — `skills/<name>/SKILL.md`, in this
-repository and in the npm package — so an agent finds rigc the way it finds its
-other tools. Each skill is a router and nothing more: when to load it, the
+repository and in the npm package — which a host reads once they are where it
+looks: Claude Code through the plugin below, Codex, Gemini CLI and Antigravity
+through `rigc skills install`. Each skill is a router and nothing more: when to load it, the
 non-negotiables in a line apiece, and a link to the guide that owns every rule, so
 a rule keeps living in exactly one place. The repository is also a Claude Code
 plugin marketplace:
@@ -162,6 +163,35 @@ loads the same skills without a marketplace. The plugin carries no version of it
 own — `/plugin update` follows `main` commit by commit, and the only version on
 disk stays the one in `package.json`.
 
+Codex, Gemini CLI and Antigravity read skills from one directory in the workspace,
+`.agents/skills/` ([Codex](https://learn.chatgpt.com/docs/build-skills),
+[Gemini CLI](https://github.com/google-gemini/gemini-cli/blob/main/docs/cli/skills.md),
+[Antigravity](https://antigravity.google/docs/skills/)), and none of them reads
+`node_modules`. With the package installed, one command puts every skill there:
+
+```shell
+bun add -d spine-rigc
+bun rigc skills install          # relative links: .agents/skills/rigc -> ../../node_modules/spine-rigc/skills/rigc
+bun rigc skills install --copy   # the folders themselves, for a host that does not follow a link
+```
+
+Run it through the project's own install, as above: `bunx spine-rigc skills install`
+in a project that has the package was measured running the registry's copy instead
+of the project's. A link reaches every upgrade of the package with no second run,
+and a second run has nothing to do; an entry already there that this command did not
+make is refused by name and nothing is written. Gemini CLI 0.41.1 was measured
+listing a linked skill from both its workspace and its user directory — the
+workspace one only in a folder it trusts. Codex's documentation says it follows a
+symlinked skill folder, which is not measured here, and Antigravity CLI 1.1.9 has no
+way to list skills without starting a session, so what it does with a link is not
+measured either; `--copy` is the shape that asks nothing of a host. Gemini CLI can
+also fetch a skill itself, one folder at a time:
+`gemini skills install https://github.com/firejune/rigc.git --path skills/rigc --scope workspace`.
+The routers are named `rigc-rigging`, `rigc-motion`, `rigc-face` and `rigc-ingest`
+because that directory is flat — beside another tool's `motion`, a bare name is
+whichever one the host picked — and under the Claude Code plugin they read
+`rigc:rigc-motion` and so on.
+
 ## First rig in ten minutes
 
 A whole rig, end to end, in a scratch directory: three tiny plates, two JSON
@@ -293,6 +323,7 @@ the two files:
   ..    pages=3 regions=3 bones=4 slots=3 animations=1 version=4.3.13 regionAttachments=3 meshAttachments=0 physicsConstraints=0 rig=buoy profile=spine
 rigc: wrote …/buoy/spine/skeleton.json
 rigc: wrote …/buoy/spine/skeleton.atlas
+rigc: look at it: rigc preview --candidate …/buoy/spine
 ```
 
 `profile=spine` is the rulebook that judged it: *is this valid Spine 4.3 that any
@@ -502,15 +533,16 @@ commands take it and what its default is.
 | `validate <dir>` | re-gates artifacts already on disk |
 | `ingest <skeleton.json> --out <dir>` | `build` run backwards: reads a Spine 4.3 skeleton and writes the rig spec and motion spec that **rebuild it**, plus a findings report naming everything it could not carry. a skeleton that declares no stage is carried as declaring none, `--stage x,y,w,h` adds a box to one — and is refused, rather than ignored, beside one that declares a box — and `--images <dir>` writes the spec's own images directory — the opposite direction from `build --images`, which overrides it — so the rebuild carries no flag at all |
 | `explain --rig … --motion …` | the compiled rig as a table — every bone with its resolved parent, the slots in draw order, every timeline key by key. Writes nothing. What to reach for when a rig compiles and still looks wrong |
-| `render --candidate <dir>` | PNG frames plus a contact sheet, in `render/` |
-| `preview --candidate <dir>` | one self-contained `.html` that plays it |
+| `render --candidate <dir>` | PNG frames plus a contact sheet, in `render/`. `--hide <slot,…>` or `--slot <slot,…>` draws part of the rig on the **same grid** as the whole, so the two frames overlay and the difference is the part; `frames.json` records the subset and `check` refuses such a set as a reference |
+| `preview --candidate <dir>` | one self-contained `.html` that plays it, headed by the line `validate <dir>` prints for it and the rigc version — a refused candidate is still previewed, and its header says so in the gate's words. Repeat `--candidate` for one page with a pane per candidate, in the order given; a green `build` ends by naming this command for its own `--out` |
 | `vote --candidate a --candidate b` | one `.html` that asks a human which; `vote --record <file>` checks the answer into `votes.jsonl` |
 | `pose --images <dir> --frame <png>` | reads part placements **out of** a picture |
 | `chainfit --candidate <dir> --images <dir> --frame <png>` | reads the parts `pose` refuses, through the candidate's own draw order and hierarchy: masked residuals over **visible** pixels, one hinge per child instead of four degrees of freedom, and the `rotate` key value each answer implies. A bone with two or more anchored descendants is **determined** rather than searched, and the residual that over-determination leaves is reported |
 | `diff <candidate.json> <reference.json>` | structural comparison of two skeletons, one ratio per measure and deliberately no combined score |
 | `bonedist --candidate … --reference … --bones …` | per-frame, per-bone world-transform distance against another skeleton — the ladder's stage 3, run on its own. `--bones <correspondence.json \| identity>` is required rather than defaulted: a candidate is entitled to its own bone names, so the pairing is stated |
-| `check --candidate <dir> --frames <dir>` | the candidate against reference pictures — the only instrument here that can see a *wrong animation* |
+| `check --candidate <dir> --frames <dir> [--out <dir>]` | the candidate against reference pictures — the only instrument here that can see a *wrong animation*. `--out` also writes, for every frame the table lists, the picture its figures came from: reference, candidate, difference and overlay at native size |
 | `bench <rung> --candidate <dir>` | one rung of the benchmark ladder |
+| `skills install [--dir …] [--copy]` | links every agent skill the package ships into `.agents/skills` (or `--dir`) as relative symlinks, or copies them with `--copy` — where Codex, Gemini CLI and Antigravity look. A second run has nothing to do; an entry already there that is not this command's is refused by name and nothing is written |
 
 `diff`, `bonedist`, `check` and `bench` measure against something you were given; the
 first three work on any reference you have, and `bench` is a repository workflow that needs a clone