Context
Follow-up to repo-scoped skill installation. Once curated skills install into their origin repo only (no global leak), some skills are still genuinely useful across more than one repo — e.g. the kai-* family (kai-agent-new / kai-backend / kai-frontend are separate repos but one product), or general-purpose skills that aren't really project-specific at all. Strict per-repo install would hide those from the repos that could use them.
Idea
A separate watchmen pass that scans all curated skills across bundles and distributes the cross-repo-useful ones into the relevant repos' scoped skill dirs — optionally polishing/generalizing them for shared usage first.
Roughly:
- Scan every curated skill across all bundles.
- Decide which skills are relevant to which other repos (candidate signals: semantic match of
when_to_use against the target repo's intent/corpus, shared product/group, or explicit user opt-in).
- For each (skill, target repo) match, either clone the skill into the target repo's
.claude/skills/ or produce a polished/generalized variant tuned for shared usage.
- Keep it reviewable — propose, let the user approve, don't auto-spray skills everywhere (we just spent effort reducing skill noise; this must not reintroduce it).
Open questions
- Relevance decision: semantic similarity vs explicit repo-group config vs user opt-in per skill? (model2vec similarity is too coarse for fine calls per the adoption findings — likely needs an LLM judge or a manual group map.)
- Polish vs clone: when do we generalize a project-specific skill for shared use vs just symlink it as-is?
- Dedup / drift: if the source skill changes later, how do the cloned/polished copies stay in sync (or do they intentionally fork)?
- Avoid re-creating the firehose / global-pollution problem this whole line of work is trying to fix.
Depends on
Repo-scoped skill installation (the scope=project default + migration). This issue only makes sense once skills are repo-scoped by default.
Context
Follow-up to repo-scoped skill installation. Once curated skills install into their origin repo only (no global leak), some skills are still genuinely useful across more than one repo — e.g. the kai-* family (kai-agent-new / kai-backend / kai-frontend are separate repos but one product), or general-purpose skills that aren't really project-specific at all. Strict per-repo install would hide those from the repos that could use them.
Idea
A separate watchmen pass that scans all curated skills across bundles and distributes the cross-repo-useful ones into the relevant repos' scoped skill dirs — optionally polishing/generalizing them for shared usage first.
Roughly:
when_to_useagainst the target repo's intent/corpus, shared product/group, or explicit user opt-in)..claude/skills/or produce a polished/generalized variant tuned for shared usage.Open questions
Depends on
Repo-scoped skill installation (the scope=project default + migration). This issue only makes sense once skills are repo-scoped by default.