Skills are loadable capability modules (SKILL.md files with name + description frontmatter and a body the worker follows). Loading one injects its procedure into context; the discipline is invoke and follow — naming a skill is not using it.

Where skills live

Skills are discovered from several roots (the files are the source of truth):

• ~/.claude/skills — user skills.
• ~/.claude/plugins/cache/**/skills — plugin skills (superpowers, context-mode, figma, chrome-devtools, etc.).
• E:\99--skills — work-in-progress / authoring area.
• <repo>/.claude/skills — per-repo local skills (scoped to that repo).

Curated catalog vs. full index

Two things, deliberately different in size:

• E:\hooks\skills-catalog.md — the curated allowlist (~59 skills), grouped by tier and working intent. This is what the worker routes against.
• The on-disk set — ~201 discoverable skills across all roots. The full set is indexed but only the curated allowlist is surfaced as suggestions, to keep routing signal high.

The searchable index

E:\hooks\index-skills.py (stdlib-only) builds a queryable mirror in the shared memory DB (skills + skills_fts tables):

• Scans the roots above, skips *.backup*, dedups by frontmatter name.
• Rebuilds from disk every run — the table is a derived mirror, never hand-edited, so removed skills disappear and nothing drifts stale.
• Flags curated = 1 for names in skills-catalog.md. Current state: 201 indexed / 59 curated.

Run it after adding, editing, or removing a skill.

How skills reach the worker

The UserPromptSubmit hook FTS-matches each prompt against the curated index (name-weighted, scope-aware, relevance-floored) and injects the top 2 as suggestions.

Suggestions are advisory today — nothing forces a load. The planned PreToolUse skill-gate converts them from suggested to required.