Skip to content

7.4 The Skill Library

One Skill is a convenience. A library of them is an asset — the kind that compounds, travels, and eventually earns. This lesson is about the collection: how libraries grow without rotting, how they spread across projects and teams, and why yours might be worth money.

What you will learn

  • Organize Skills across the personal/project/team layers.
  • Maintain a library: the review rhythm that prevents Skill rot.
  • Evaluate whether a Skill supports a repeatable service or deliverable.

Builder principle

Your Skill library is the most you thing in your entire stack — it's your taste and process, executable. Build it like it's going in your will.

The library layers

Same layering logic as memory (5.3) and commands (6.1) — by now this should feel like the house style of the whole stack:

~/.claude/skills/            ← PERSONAL: your craft, every project
  ├── research-with-sources/     (your 6.4 method, packaged)
  ├── ship-check/                (your 4.4 verification pass)
  └── weekly-review/             (your planning cadence)

project/.claude/skills/      ← PROJECT: this work's specialties
  ├── newsletter-prep/
  └── client-site-checklist/

The filing question is the familiar one — where is this true? Your verification pass is you-everywhere: personal. The newsletter process belongs to the newsletter: project. When a personal Skill starts accumulating project-specific exceptions ("except for the bakery client, where…"), that's the signal to split it — the general core stays personal, the exception becomes a thin project Skill.

Growing without rotting

Libraries fail two ways: they stop growing (the packaging habit dies) or they rot (Skills drift out of sync with reality and quietly poison sessions). The countermeasures are small and scheduled:

The growth trigger — you already have it from 6.1's earn-a-command rule, one level up: when a command's file keeps growing, it's a Skill embryo; when you correct the same behavior in two different sessions, that correction wants packaging. Capture-when-it-happens beats build-sessions-you'll-never-schedule.

The rot audit — quarterly, 20 minutes, and it's just 5.3's memory hygiene extended to its natural conclusion:

Read every skill in this project and my user level. For each, flag:
steps that contradict how we currently work (check docs/decisions.md
and recent docs/log.md entries), references to files that no longer
exist, and overlaps between skills. Report — don't fix yet.

An agent auditing its own instruction set against the second brain — the stack maintaining the stack. Review the report, ratchet what's real, delete what's dead. Deleting is library maintenance too: a Skill nobody's used in six months is context-catalog clutter with a folder.

The team library

"Team" might mean your business partner, your VA, or future-you-plus-help — the mechanics are identical: Skills in a shared repo mean your standards run even when you're not in the chair. The scenario worth building toward: you eventually hand off newsletter production, and the handoff is "clone the repo, run /monday, review with fresh eyes" — because the know-how lives in the Skill, not in your availability. That's what turning labor into an asset literally looks like.

A reviewed team Skill can make a procedure visible and repeatable across a shared repository. Treat it like maintained code: owner, pull-request review, tests, version notes, and a retirement path. Start with one authorized, frequently repeated process and measure whether the Skill reduces re-explanation or defects before expanding the library.

The business angle

Three ways libraries become money — file under Chapter 11 foreshadowing:

  1. Speed as a hypothesis. Compare repeated work with and without the Skill. Record elapsed time, corrections, and review effort; do not assume reuse creates margin.
  2. Skills as deliverables. A maintained content-operations Skill may be useful alongside a site project when the client can inspect, run, and own it. Scope support, compatibility, data handling, and handoff explicitly.
  3. Accumulated procedure. A library can preserve reviewed choices and edge cases that matter to your work. Its value depends on continued use, measured outcomes, and maintenance; age or size alone proves nothing.

Try it now

Founding ceremony for your library:

  1. Sort your current Skills (you have at least one real one now, plus commands that are embryos) into personal vs. project. Move anything misfiled.
  2. Promote one command-embryo into your second full Skill — the 7.3 cycle, faster this time.
  3. Run the rot audit now to set the baseline (it'll be short — that's fine, it's a founding document).
  4. Journal the maintenance question: which Skill has repeat-use evidence strong enough to justify another year of ownership?

Check your understanding

  • What's the filing question for Skill placement, and what's the split signal?
  • Name the growth trigger and the rot audit's cadence. Why is deleting part of maintenance?
  • What does a shared Skill library do to bus factor, and which team process should go first?
  • Of the three business angles, which is available to you this month?