—
type: article
name: article-s4-1
created: 2026-08-04
updated: 2026-08-04
status: drafted
series: “S4 (The Skills Canvas)”
series_number: 1
series_name: “The Skills Canvas”
grounding:
– “HERMES-SKILLS-LIBRARY”
– “LOCAL-CUSTOM-SKILLS-INVENTORY”
tags:
– “skills-management”
– “capability-library”
– “skill-authoring”
– “knowledge-as-content”
– “three-layer-stack”
wiki_concepts:
– “skill-lifecycle-management”
– “hermes-skills-library”
– “skills-alignment-map”
– “local-custom-skills-inventory”
skills:
– “hermes-agent-skill-authoring”
– “curator-docs”
– “kanban-orchestrator”
– “memory”
– “obsidian”
—
# The 71-Skill Canvas: Capability Library as Both Tool and Content
## Introduction: The library that reads itself
Every autonomous system eventually confronts a paradox: the thing that makes it capable is also the thing it must maintain. In the Hermes ecosystem, this paradox lives in the skills library — a collection of SKILL.md files that serve simultaneously as operational tooling and as documented knowledge. The library is both the wrench and the manual. This dual nature is not a bug; it is the defining feature of the Skills Canvas.
When an agent loads a skill, it pays for that skill’s description in every subsequent turn. The frontmatter, the trigger conditions, the numbered steps — they consume context window, shape behavior, and alter output quality. A skill that does nothing useful wastes tokens. A skill that does everything poorly wastes attention. The 71-skill canvas (our local custom library — 160 SKILL.md across 37 categories, with roughly 71 actively deployed in production workflows) forces a reckoning with this reality: every skill is a bet on what matters.
## The three-layer architecture
The Hermes skills ecosystem operates across three distinct layers, each with different provenance, maintenance models, and content density:
| Layer | Source | Count | Maintained by |
|——-|——–|——-|—————|
| Bundled | Ships with Hermes, repo catalog | ~110 skills / 13 categories | Hermes core team |
| Hub | Live registry, browse + install | 90,612 skills | Community + agentskills.io |
| Local custom | Built for KOT-OS specifically | 160 SKILL.md / 37 categories | Council agents |
The bundled catalog is regenerated from the repo by `generate-skill-docs.py`. The hub is a living surface — agentskills.io plus GitHub taps — that we treat as a lookup-then-install layer. Local deletions and edits of bundled skills are respected by `hermes update`, which means built-ins degrade to reference-only if we modify them.
This three-layer structure is not just an organizational convenience. It creates a content hierarchy: bundled skills are canonical reference, hub skills are community knowledge, and local customs are institutional memory. The library is not one thing; it is three things at once.
## Skills as tool: what the library enables
The operational value of the skills library is straightforward: when an agent loads a skill, it gains a specific capability it did not have before. The `moses-governance` skill gives an agent constitutional authority over agent hierarchies. The `kanban-orchestrator` skill teaches decomposition patterns. The `hermes-agent-skill-authoring` skill itself is a meta-capability — the ability to create new skills.
But the tool value is deeper than individual capabilities. The library creates a **combinatorial space** of possible agent behaviors. An agent with 5 skills can operate in 32 distinct capability configurations (2^5). An agent with 71 skills faces a combinatorial explosion that no human planner could reason about manually. The canvas is not a list of tools; it is a landscape of possible agent identities.
This is where the three-layer architecture becomes operationally critical. The bundled layer provides stable, well-tested primitives. The hub layer provides experimental capabilities. The local custom layer provides the merge bases — the skills that define what KOT-OS can do that stock Hermes cannot. When we curate the local library, we are not just organizing files; we are defining the operational identity of the system.
## Skills as content: what the library documents
Here is the insight that most skill authors miss: a SKILL.md file is not just an instruction set for an agent. It is also a document that humans read, other agents reference, and future systems inherit. The library is a knowledge base disguised as a tool collection.
Consider the `LOCAL-CUSTOM-SKILLS-INVENTORY.md` document. It tracks not just what skills exist, but why they exist, what gap they fill, and what the bundled library does not provide. This is content about content — metadata about the tool layer. The document itself becomes a skill (it is referenced by S4.1 articles, loaded by orchestrators, used by curators) even as it describes other skills.
The `HERMES-SKILLS-LIBRARY.md` reference goes further. It documents the three-layer architecture, the authority and drift policy, the bundled catalog structure. It is a systems document that happens to live inside the skills library. When an agent loads it, the agent gains not a capability but a **map** — a way to reason about the library itself.
This dual nature creates a feedback loop:
1. Skills enable agent behavior (tool function)
2. Skill documentation captures knowledge about that behavior (content function)
3. That knowledge informs curation decisions (governance function)
4. Governance produces better skills (improvement function)
The canvas is not static. It is a self-referential system where the content about the tools shapes the tools themselves.
## The curation problem
If every skill is both tool and content, then curation is not optional — it is architectural. The `curator-docs` skill defines the maintenance protocol: skills that are unused for 30 days get flagged, skills with broken triggers get deprecated, and new skills must pass a quality gate before entering the local library.
But curation is also a content problem. When you deprecate a skill, you do not just remove a capability; you remove a document. You lose the knowledge encoded in that SKILL.md — the pitfalls section, the trigger conditions, the integration patterns. A good curation process preserves the content even when it removes the tool.
The `kanban-done-gate` skill illustrates this. It was built as a validation gate for kanban_complete calls — a tool that ensures agents do not mark tasks done prematurely. But the skill also documents the failure modes it catches: phantom artifact paths, unverified external writes, missing metadata. That documentation is valuable even if the gate itself is eventually replaced by a different mechanism.
## The 71-skill threshold
Why 71? Not because 71 is a magic number, but because it represents the point where the library becomes too large for any single agent to hold in context. At 71 active skills, you cannot load them all and still have room for the actual task. You must choose. And choosing requires understanding what each skill does, what it costs, and what it enables.
This is the canvas metaphor. A painter’s palette has a fixed set of colors, but the number of possible paintings is infinite. The skills library has a fixed set of capabilities, but the number of possible agent configurations is combinatorial. The 71-skill canvas is not a constraint; it is a creative surface.
The three-layer architecture supports this by providing different levels of commitment:
– **Bundled skills** are always available, always loaded, always cost context tokens
– **Hub skills** are installed on demand, loaded when needed, removed when done
– **Local customs** are the permanent palette — the 71 colors you have chosen to keep
## What comes next
The Skills Canvas series will explore this territory in depth. S4.2 examines the alignment map — how skills connect to systems. S4.3 covers the curator — who maintains the library and how. S4.5 introduces the three-layer knowledge stack — how skills, memory, and vault interact. S4.7 teaches skill authoring — the mechanics of writing SKILL.md files. And S4.10 asks whether skills can be products — sold, not just used.
But every subsequent article rests on this foundation: the library is both tool and content. The canvas is both palette and painting. The skills are both what we do and what we know.
The 71-skill canvas is not a catalog. It is a mirror.
—
*This article is the opening of the Skills Canvas series (S4). For the full series map, see [[concepts/skills-alignment-map]]. For the operational library, see [[HERMES-SKILLS-LIBRARY]] and [[LOCAL-CUSTOM-SKILLS-INVENTORY]].*
## Semantic Relationships
|→ [[skills-management]] — orchestrates
|→ [[skill-authoring]] — orchestrates
|→ [[skills-alignment-map]] — orchestrates
|→ [[hermes-skills-library]] — orchestrates
|→ [[local-custom-skills-inventory]] — orchestrates
|→ [[skill-lifecycle-management]] — orchestrates
