Developers who run Claude Code as a "dev team" instead of a single assistant install the same short list of skills: a planning gate, a subagent-dri...
For further actions, you may consider blocking this person and/or reporting abuse
The installed stack matters less than the coordination rules around it. Skills and MCPs help only when the agent knows when to read them, when to ignore them, and how to preserve evidence.
Agreed, and the failure mode when the coordination layer is missing is very specific: two skills with overlapping trigger descriptions, and the agent quietly stops delegating to one of them. No error, no log line, the skill just stops firing. The stack list is the easy half.
On preserving evidence, the strongest version I have found is structural rather than behavioral: run verification in a context that did not produce the code. An agent grading its own homework converges on confident wrong answers no matter what the rules file says.
That overlapping-trigger failure is exactly why I think skill registries need some kind of conflict audit, not just install success. The scary case is quiet non-use: the agent still looks capable, but one procedure has effectively shadowed another. I would rather surface that as a routing warning than discover it from behavior drift later.
Agreed, and I would split the audit into a static half and a runtime half, because they catch different things. The static half is cheap at install time: compare the new skill's trigger description against what is already installed and warn on high overlap, before anything is shadowed. But true shadowing only shows up at runtime - which procedure actually got routed. The signal that catches your quiet non-use case directly is a per-skill fire count over the last N sessions: a skill sitting at zero fires whose trigger overlaps a busy neighbor is almost certainly shadowed, no behavior-drift forensics needed. That log is nearly free to keep and it turns "the agent still looks capable" from a feeling into a checkable table.
The static/runtime split is exactly the missing layer. A registry can say two skills both match, but it cannot prove which one actually fired during the run. I like the idea of measuring shadowed skills and per-skill fire count, because quiet non-use is usually more dangerous than an obvious routing error.
The good news is the runtime half needs no registry cooperation at all: local session transcripts usually carry enough signal (tool-use entries, skill loads) to approximate per-skill fire counts, so a session-end hook can maintain them and diff against the installed set. The format is not a stable public contract, so treat it as a heuristic you re-validate per version, but the data already sits on your own disk. Zero fires over N sessions in workflows where the trigger description should have matched is exactly your "quiet non-use" signature. The piece a registry could add on top is the prior, not the proof: aggregate anonymized fire-rate-per-install across users, so you can see that a skill fires for almost nobody before you install it. Shadowing would show up there as a population-level pattern (fire rates collapse for one skill whenever a specific other skill is co-installed), which no single machine can observe locally.