/skill-overlap — flag content-redundant SKILL.md pairs (never merge)
SkillDev toolsFlag content-redundant SKILL.md pairs as merge candidates — pairwise body cosine similarity over the skill pack, sorted highest-first. Use when the pack feels bloated or two skills seem to overlap, to find "skills A and B are N% token-similar — consider merging" candidates before a skill-lifecycle archive pass. Proposal only — never merges, edits, or deletes a skill.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the /skill-overlap — flag content-redundant SKILL.md pairs (never merge) skill
What this skill tells your AI
The instructions your AI receives, as published by anthony-chaudhary/fak in .agents/skills/skill-overlap/SKILL.md and read by ahel’s review.
The one context-cost technique from the Comet/Perplexity writeup that fak did
not already cover (#3930): skill-to-skill content redundancy.
skill-lifecycle archives dead skills and
skill-score audits over-budget ones — neither measures
whether two live skills say the same thing. With 55+ SKILL.md files (many
*-score scorecards), that overlap is where the pack quietly bloats.
This skill measures it and stops. Max action is to PRINT candidates for a
human to judge — like skill-lifecycle's dry-run archive verdicts, it proposes,
it never merges. Deciding two skills are genuinely one is a semantic call the
detector deliberately does not make; there is no --apply.
The witnessed helper
skill_overlap.py runs a pairwise token-similarity primitive over every
.claude/skills/*/SKILL.md body and emits the pairs above a threshold,
sorted by similarity:
python .claude/skills/skill-overlap/skill_overlap.py [--threshold T] [--top N] [--json]
- Front-matter is stripped first — the shared
name:/description:YAML skeleton is structural, not redundant, so it must not inflate the score. - Similarity is body cosine over token frequency with a small function-word
stoplist — "skills A and B are N% token-similar" in the issue's own words. Same
posture as
fak dup/fak traj(block- and query-level near-dup detection), self-contained so the witness runs with no builtfakbinary. - Default threshold 0.5; drop to
--threshold 0.4to see the long tail. shared_topnames the highest-weight tokens both bodies carry — the why behind each score, so a human can judge the merge without re-reading both.
Exit code is always 0: this is advisory, and "no candidates" is a clean answer.
How to read a candidate
A high score means lexical overlap, not that a merge is correct. Two *-score
scorecards may share vocabulary (debt, scorecard, commit) yet tend
genuinely different surfaces. Before proposing a merge:
- Read both
SKILL.mdbodies. Do they tend the same surface, or just share the scorecard idiom? - If genuinely redundant → open an issue proposing the merge, or route the
weaker one through
skill-lifecycleto archive (reversible), never a raw delete. - If distinct-but-similar → the overlap is a discoverability smell; sharpen
each
description:'s "Use when…" trigger viaskill-scoreso the two stop colliding in recall.
Witness
python .claude/skills/skill-overlap/skill_overlap_test.py — a fixture skill
pack with one deliberately-overlapping pair asserts that pair is surfaced above
the threshold while two unrelated skills are not, plus the front-matter-stripped,
proposal-only, deterministic, and archived-skip invariants. This is the skill's
proof-of-correctness; run it after any change to the detector.
Signals
- GitHub stars
- 38
- Forks
- 15
- Last commit
- Sep 2026
Advanced
- Catalog kind
- skill
- Gateway key
skill-overlap- Source
- github.com/anthony-chaudhary/fak