Pin the npx skills install command to the stable tag

[178inaba]

Why

README.md documents two ways to install this repository's Agent Skill. #72 pinned the Claude Code plugin path through the stable tag and #78 implemented it; the npx skills line a few lines below was left naming no ref, so the installer clones the default branch.

That is the same silent drift #72 closed, still open on a channel the README advertises — and running the other way. Merging to main ships the current skills/rdsh/SKILL.md to anyone installing or updating through that path, while the binary they have from brew install is still the last released tag. The skill describes flags their binary does not have, and nothing goes red anywhere.

stable itself already moves correctly: the release workflow force-pushes it onto the new tag once the archives are published and attested. Nothing about the release pipeline changes here. What was missing is that this one install command did not ask for it.

What

• README.md — the npx skills command now names the tag in URL form, npx skills add https://github.com/178inaba/rdsh/tree/stable, with a short comment recording why the shorthand is not used.
• .github/workflows/ci.yml — a fifth assertion in the existing Assert the plugin distribution wiring step, matching the whole install command and emitting its own ::error:: line. Folded into that step rather than added beside it: it is the same class the step already guards, where a break reddens nothing and the first signal is a user running a skill their binary does not match. The step's comment previously described the symptom in one direction only (updates that stop arriving) and now covers both.
• CLAUDE.md — the existing stable is moved only by the release workflow bullet names the README install line as a third consumer of the tag. No new bullet: this is one more consumer of a rule that already exists.

The shorthand, and a correction to the Issue

The Issue asks for the URL form over 178inaba/rdsh@stable on the grounds that both resolve stable at install time but only the URL form records the ref in the lockfile. Probing with a ref that cannot exist shows the first half of that is not what happens:

npx skills add 178inaba/rdsh@definitely-not-a-ref   → installs fine, from the default branch
npx skills add 178inaba/rdsh#definitely-not-a-ref   → fatal: Remote branch ... not found in upstream origin

skills reads the suffix in owner/repo@suffix as a skill-name filter, not a git ref — @stable never reaches git and does not pin anything. The Source: ... .git @stable line the installer prints is the shorthand echoed back, not a resolved ref; a real ref prints with a space (@ stable). Separately, the # fragment form (178inaba/rdsh#stable) does record "ref": "stable", so the URL form is not the only spelling that works.

Neither correction changes the requested command, but the rationale committed to README.md and CLAUDE.md states the measured behaviour rather than the Issue's reading — a guard rail arguing from a false premise stops guarding the moment someone checks it. Details and full output are in a comment on the Issue, which is worth carrying over to the sibling Issues 178inaba/cflio#76 and 178inaba/slio#56 that repeat the same table.

Verification

The new assertion was written before the README edit and run as-is against the still-unpinned README, so its red state is the one CI would produce:

::error::README.md's npx skills install command must pin the stable tag
exit=1        # against `npx skills add 178inaba/rdsh`
exit=0        # after the edit

Installing with the new command on macOS, project scope, in an empty temp directory records "ref": "stable" and npx skills update preserves it — recorded on the Issue. go test -race ./... and golangci-lint both pass (no Go code changes).

Considered and not done

• Asserting the complement — "no unpinned npx skills add line exists" rather than "the pinned line exists". It is the stricter form and would catch a second, unpinned install snippet added later. Not taken: the Issue prescribes this shape with its reasoning, the same Issue is open on both sibling repositories, and the README has exactly one npx skills add occurrence with the rule now recorded in CLAUDE.md for the next editor. A divergence across the three lint jobs costs more than the case it covers.
• Widening the step name past "plugin distribution wiring" now that it also asserts the non-plugin install path. It is still this skill's distribution wiring, and renaming drifts further from the sibling repositories' step names.

Closes #81