Stale project-scoped install silently suppresses datum-platform in every other repo

[ecv]

What needs to happen

Every teammate should get the datum-platform skills in every Datum repo. Most do — repo config auto-installs the plugin on a clean machine. But anyone who installed it by hand earlier is silently broken, and nothing tells them.

Why this matters

datum-cloud/infra enables the plugin in its tracked .claude/settings.json, and its CLAUDE.md makes the skills mandatory — "Follow the datum-platform:pr-conventions skill for all PRs, issues, and comments" — with releases routed through datum-platform:release.

An install recorded once as scope: project bound to datum/engineering suppressed the auto-install everywhere else. In datum/infra the plugin was enabled in settings, listed by claude plugin list, and absent from the session. That session followed CLAUDE.md, found no skill, and wrote a day of issues and PRs against a reconstructed guess at the conventions.

The people most likely affected are the ones who adopted the plugin earliest, and there is no signal either way. Test confirming the mechanism.

Desired outcome

Opening any Datum repo gets the plugin regardless of install history, and a required-but-missing skill is detectable rather than silent.

• Re-pin existing installs at user scope — --scope user binds to no project, so nothing can shadow it — and document it where teammates will see it. Note that claude plugin uninstall --scope project strips the plugin from the repo's tracked settings.json; check git status after.
• Report the shadowing upstream to Claude Code. A stale project entry suppressing auto-install for a different project looks like a bug, and the silence is the harmful part.
• Decide whether a CLAUDE.md-required skill that isn't loaded can be detected at all.

Observed in datum-cloud/infra; every repo copies the same pattern, so the fix belongs here.

[ecv]

Tested the open question, and it changes the shape of this issue: enabledPlugins does auto-install on a clean machine. The per-repo mechanism works. The bug is narrower and worse.

Test: a scratch project declaring the marketplace plus "enabledPlugins": {"milo-activity@datum-claude-code-plugins": true} — a plugin with no prior install record anywhere. One non-interactive claude -p run in that directory installed it silently, no trust prompt, recorded as scope: project bound to that directory. Uninstalled and removed after.

So a teammate starting clean gets the plugin from the repo config alone. What breaks is the case that actually happened here: an existing install bound to a different project silently suppresses the auto-install. datum-platform was recorded once as scope: project → datum/engineering. In datum/infra the auto-install saw the plugin id already present and skipped, but the binding pointed elsewhere, so the skills never loaded. Enabled in settings, listed by claude plugin list, absent from the session.

That inverts the usual expectation — the people most likely to be broken are the ones who installed the plugin earliest, and they get no signal at all. Anyone who never installed it by hand is fine.

Proposed way forward, cheapest first:

1. Tell existing teammates to re-pin at user scope. claude plugin install datum-platform@datum-claude-code-plugins --scope user — user scope binds to no project, so nothing can shadow it. One command, fixes everyone already broken. Worth a note in onboarding rather than word of mouth.
2. Keep enabledPlugins in each repo. It demonstrably works for clean machines; no change needed.
3. Report the shadowing upstream to Claude Code. A stale project-scoped entry suppressing auto-install for a different project looks like a bug, not intent — and the silence is the harmful part.

Caution

claude plugin uninstall --scope project edits the project's .claude/settings.json and strips the plugin from enabledPlugins. In these repos that file is tracked, so the "cleanup" removes the declaration for every teammate. Hit this while removing the stale entry from datum/engineering and had to restore the file. Anyone doing step 1 should check git status afterwards.

Still open: whether a CLAUDE.md that names a required skill should be able to detect that the skill isn't loaded. Nothing surfaced this for weeks.