06-reference/research

claude skill count degradation skill packs

2026-07-07·research-brief·source: deep-research
skillsagent-harnessprogressive-disclosurecafcontext-management

The 20-50 Skill Threshold Is a Heuristic, Not a Measurement — And the Real Constraint at 60 Skills Is Trigger Collision, Not Token Budget

The question

Anthropic's Complete Guide to Building Skills warns that enabling more than 20-50 skills simultaneously degrades response quality. Andrew's phData/CAF departmental target is ~60 skills. Is 20-50 empirically grounded or a rule of thumb? What published patterns exist for selective enablement, "skill packs" (grouped by role/task type), and per-session context pruning for large deployments — so CAF skills can be packaged correctly before shipping?

What we already know (from the vault)

What the web says

Convergences and contradictions

Synthesis for RDCO

Verdict on 20-50: it is a heuristic, not an empirical skills threshold. The measured degradation in the literature is for tools (full schema always in context): recommended <20, accuracy degrading past ~10, hard cliff at high counts, GitHub's 40→13 real-world win. Anthropic's guide borrows that guardrail and restates it for skills, but skills do not carry the same cost — progressive disclosure means 40 skills ≈ 1,500 tokens and Anthropic itself runs hundreds. So 20-50 is a conservative rule of thumb worth respecting for the simultaneously-active set, but it is not a measured skills-specific cliff, and it is not a reason to fear a 60-skill library.

The skills-vs-tools context cost, stated cleanly:

Packaging recommendation for the ~60-skill CAF deployment (shippable to Andrew's team):

  1. Install broad, enable narrow. Ship all ~60 as a library, but never enable all 60 in one session. Target a simultaneously-active surface under ~15-20 skills — the empirically-supported comfortable range from the tool literature, applied conservatively to skills.
  2. Define skill packs by role AND by CAF phase. Two grouping axes both already exist in the vault:
    • Role packs (maps to the Ch4 two-rail distribution): a pre-sales/use-case pack for the ~60 sales users (Cowork org-admin rail), a build/delivery pack for the ~12 engineers (Code plugin rail). A sales seat should never load engineering skills into its selection menu.
    • Phase packs: the CAF 8-phase pipeline ([[2026-06-28-caf-8-phase-structure-and-skill-pipeline-mapping]]) gives natural cut lines — Phases 1-4 "half-CAF" (learn customer → use cases → C4 Build Manifest) is one pack; the delivery/skills-pipeline half is another. Enable the phase-pack for the phase the user is in.
  3. Ship a master router / entry-point skill per pack. Fix the gap [[2026-06-10-caf-current-state-teardown]] flagged (no /catalyst entry point). A single top-level dispatcher keeps the first-level selection surface tiny and routes to sub-skills on demand — the same lazy-pointer move CLAUDE.md uses for CAPABILITIES.md. This is the highest-leverage single fix.
  4. Invest in description quality as the routing lever, and lint for trigger collision. Because selection is "pure reasoning over descriptions," disambiguated, non-overlapping when-to-use lines are what actually protect quality at 60 skills. The brigade's triggering critic already scores this; add a cross-skill collision check (no two enabled skills share a trigger phrase) to the deterministic lint axis alongside Reference A's mechanical rules.
  5. Add a composability/portability critic axis (the guide's candidate) so "works alongside the other skills in its pack" becomes a tested property, not an assumption.
  6. Per-session pruning is a secondary lever, not the fix. /clear, /compact, and subagent routing (Thariq) manage conversation context; they do not shrink the skill menu. The menu is shrunk by pack scoping (step 2), not by pruning. Keep them for long delivery sessions, but don't rely on them to solve the 60-skill selection problem.

One-line packaging rule for the team: A CAF user should only ever see the skills for their role and current phase — install 60, expose ~15.

Open follow-ups

  1. Does Anthropic's Skills API (/v1/skills) or Cowork org-admin expose native per-role/per-workspace enablement scoping, or must packs be enforced by shipping separate plugin bundles per rail? (Determines whether "install broad, enable narrow" is a config toggle or a distribution-build decision.)
  2. Is there a measured skills-specific degradation curve anywhere (vs the tool-count curve)? All hard numbers found are tool measurements; a skills-native A/B (10 vs 30 vs 60 active skills, selection accuracy) is exactly the kind of test the brigade's execution-eval station could run and would be a publishable RDCO artifact.
  3. What is the actual token cost of the CAF skill descriptions specifically (they may be longer/heavier than Anthropic's 80-token median), and does any single CAF skill bundle an MCP/tool surface that reintroduces the expensive tool-schema cost?
  4. Does a master-router entry-point skill measurably improve selection accuracy over a flat 60-skill menu, and by how much? (Cheap to test; would validate step 3 of the recommendation.)

Related

Sources