What platform or feature?
A new opt-in command, reap route, that organizes the skills surviving a prune into category routers — but with hierarchy driven by real firing data from transcripts, not by static text similarity. This brings the “lazy-load by category” idea into skillreaper while keeping its evidence-based identity.
Why is this useful?
skillreaper today is subtractive: it tells you what to cut. But after pruning, users with hundreds of legitimately-used skills still pay a context cost that grows linearly with library size. Pruning alone doesn’t solve that long tail.
The category-router pattern (see Prior art below) does solve it — constant resident-context cost instead of linear — but it organizes skills “blind”: it ranks by BM25 / token overlap and an agent’s judgment, with no knowledge of what’s actually used. That’s exactly the data skillreaper already has. We’re the only tool positioned to route based on evidence rather than guesswork.
This closes the natural two-stage gap: prune the dead weight → organize what remains.
Describe the solution
-
reap route consumes the same transcript firing data used for verdicts.
-
Frequently-fired skills stay exposed / top-level; rarely-fired ones get pushed into deeper leaf routers loaded on demand.
-
Output a routing plan (text / --json / --md) — proposed, never auto-applied, consistent with skillreaper’s reversible philosophy.
-
Extend the existing MUTE concept: instead of only stripping a description, optionally move MUTE’d skills behind a category router.
-
Keep it strictly opt-in and secondary. Pruning stays the primary action; routing is the next step only for users who still have too many skills after reap prune.
Explicitly out of scope (to protect focus): replicating a full multi-agent routing engine or the per-host adapters (Codex / Gemini / Cursor). That’s another project’s surface area.
Additional context
Prior art / where these ideas came from:
- AnamKwon/agent-skill-router — https://github.com/AnamKwon/agent-skill-router — the category-router / lazy-load pattern that inspired this. Its own README is candid about the limits this proposal is designed to avoid: routing is “a token trade, not an accuracy win” (flat selection beat routing 100% vs 85% at 600 skills), and below a few hundred skills on a lazy-loading host “the native skill system is usually enough.” That’s precisely why routing here should be opt-in and informed by usage evidence — to avoid trading away accuracy.
The key differentiator: agent-skill-router routes by static similarity (BM25 + overlap). skillreaper would route by actual usage from transcripts — the one signal it has that the router lacks.
What platform or feature?
A new opt-in command,
reap route, that organizes the skills surviving a prune into category routers — but with hierarchy driven by real firing data from transcripts, not by static text similarity. This brings the “lazy-load by category” idea into skillreaper while keeping its evidence-based identity.Why is this useful?
skillreaper today is subtractive: it tells you what to cut. But after pruning, users with hundreds of legitimately-used skills still pay a context cost that grows linearly with library size. Pruning alone doesn’t solve that long tail.
The category-router pattern (see Prior art below) does solve it — constant resident-context cost instead of linear — but it organizes skills “blind”: it ranks by BM25 / token overlap and an agent’s judgment, with no knowledge of what’s actually used. That’s exactly the data skillreaper already has. We’re the only tool positioned to route based on evidence rather than guesswork.
This closes the natural two-stage gap: prune the dead weight → organize what remains.
Describe the solution
reap routeconsumes the same transcript firing data used for verdicts.Frequently-fired skills stay exposed / top-level; rarely-fired ones get pushed into deeper leaf routers loaded on demand.
Output a routing plan (text /
--json/ --md) — proposed, never auto-applied, consistent with skillreaper’s reversible philosophy.Extend the existing
MUTEconcept: instead of only stripping a description, optionally move MUTE’d skills behind a category router.Keep it strictly opt-in and secondary. Pruning stays the primary action; routing is the next step only for users who still have too many skills after
reap prune.Explicitly out of scope (to protect focus): replicating a full multi-agent routing engine or the per-host adapters (Codex / Gemini / Cursor). That’s another project’s surface area.
Additional context
Prior art / where these ideas came from:
The key differentiator: agent-skill-router routes by static similarity (BM25 + overlap). skillreaper would route by actual usage from transcripts — the one signal it has that the router lacks.