system-of-skills
The systems layer for agent skills

Writing one skill is easy.
Organizing ten
is where agents break.

A methodology to organize agent skills as a coherent system. Resolve skill trigger conflicts, decide when to build a new skill, and stop the failures that no single skill can explain.

v2026 · 6 principles · 1 eval loop · MIT

system state · one turnconflict detected
commit-workflow trigger: "fix ... bug" ▶ firing
debug-loop trigger: "fix ... bug" ▶ firing
write-tests trigger: "add test ..." ○ idle
"run the tests?" no owner ∅ no skill matches
Every piece looks right in isolation. The assembled system is wrong, and no single skill can tell you why.

More skills made your agent worse, not better.

Not edge cases. The documented failure mode of any skill collection that grows without a system behind it. If you have shipped a few skills, you have met at least one of these.

skill trigger conflict

Two skills both fire on the same request. The agent silently picks the wrong one and you cannot tell why.

context bloat

Duplicate skills loading on every turn, wasting your context window before the agent has done anything useful.

skill shadowing

Adding more skills degraded accuracy. The new one shadowed an existing one instead of helping it.

cascading breakage

You edit one skill and something completely unrelated breaks elsewhere. No isolation between skills.

These symptoms recur across Cursor and Claude Code communities. Skill shadowing, where adding skills degrades performance, is a measured effect in agent-skills research. The bug is never in one skill. It is in the system.

Writing one skill is a craft. Architecting fifty is engineering.

Every guide on the planet teaches the first half. Nobody teaches the second. That gap is where agents quietly break.

Existing guides

How to write a single skill well. Progressive disclosure, description fields, degrees of freedom. Necessary, but it is teaching you to write one good function.

↓
→

System of Skills

How to architect the whole collection. When skills conflict, when to merge instead of build, how to verify the system holds. The systems-engineering layer that was missing.

Codebase conceptWhat it becomes in a skill system
modulea unit of code with one jobskilla unit of agent behavior with one trigger
interfacehow callers address the moduletriggerthe observable yes/no condition that loads the skill
contractwhat the module promises to returnoutput shapewhat the skill leaves behind for the next skill or turn
kernel / core libshared primitives every module relies oncore promptthe stable principles every skill traces back to
regression testdoes this piece still work after a changeeval loopdoes the whole collection still trigger cleanly and run end-to-end

A skill collection is a codebase. Treat it like one.

The methodology, in seven moves

Seven principles to keep a skill collection coherent.

Each one solves a specific failure mode of an unmanaged collection. Together they form a system you can actually reason about.

01

Persistence Gradient

Decide what stays loaded across turns versus what loads per task. Stops context bloat from duplicate skills.

02

System Coherence

Skills must agree on shared state, naming, and authority. The collection behaves as one agent, not a committee.

03

Regime Gating

Only one skill owns a request at a time. The first line of defense against trigger conflicts.

04

Orthogonal Coverage

Two skills should not overlap in scope. Forces the merge-or-split decision before you build.

05

Flow

Skills hand off cleanly along the real task path. No dead ends, no circular delegation between subagents.

06

Granularity

Right-size each skill. Kill god-skills that try to handle everything and whose trigger means nothing.

07

Self-Contained Verification

Every skill ships an executable self-check — script, fixture, or output invariant. Prose self-assessment doesn't count; a check that can't run can't block a silent failure.

+ 08 · eval loop

Single-skill eval asks "does this piece work?" System-level eval asks "do all pieces together cover the space, trigger unambiguously, survive changes, and run end-to-end?" Baseline without the skill first. No reproducible failure, no justification to build it.

Apply it from inside your agent.

One command. Then your agent applies these principles the moment you ask "should I build a new skill?" or "why is my agent behaving unpredictably?". Works in Claude Code, Cursor, and any agent that reads ~/.claude/skills/.

$ cp -r skill/ ~/.claude/skills/system-of-skills/
# ask your agent:
> should I build a new skill, or merge into an existing one?
✓ system-of-skills loaded · 7 principles active

No build step, no dependencies. The skill itself is plain Markdown.