Ongoing

Agent Skills and MCP Servers by Area

Maintainer · 2026 · 8 min read

A running map of the skills, subagents and MCP servers I run, split by the work they do: product management, design, code review, business operations and codebase search.

Impeccable Agent Skills spec

Overview

Three mechanisms extend a coding agent and they are not interchangeable. A skill is markdown loaded on demand. A subagent is a separate context with its own model and instructions. An MCP server is a live connection to a system that already exists. This project maps which of each I run, in which area, and what the recorded usage counts say about which ones earn their place. Claude records a use count per skill, so the map is measured rather than aspirational.

Problem

Skills and MCP tools are cheap to install and expensive to keep. Every installed skill spends prompt budget through its description on every message whether or not it fires, and every MCP server adds its whole tool schema to the context. Installing across several marketplaces leaves no single place to audit what is loaded, and no way to tell an unused skill from a load-bearing one.

Constraints

Every skill in a shared directory is pinned by content hash in a lockfile, so it cannot change between sessions
Tools I have not run are reported from their own documentation and labelled as such
Descriptions cost resident prompt tokens on every message, so the installed count is kept deliberately small
Anything mirrored for a second agent runtime is generated, so the two copies cannot drift

Approach

Install skills at the level the work happens: personal ones in the home directory, area skills at the code root where every repository inherits them, and library-specific ones inside the repository that needs them. Pin each shared set in a lockfile with a computed SHA-256. Prefer an MCP server when the answer lives in a system that already has an API, and a skill when the answer is a way of working. Use the recorded use counts to decide what to remove.

Key Decisions

Pin shared skills by content hash, and install from as few sources as possible

The 14 skills in the code-root lockfile come from two sources, 13 from Leonxlnx/taste-skill and one from ilo-lang/ilo, each with a computedHash. One lockfile means the whole shared set can be audited by reading one file, and a skill cannot change under me mid-project. Impeccable is installed alongside them and is not in the lockfile, which is a gap rather than a decision.

Split by where the work happens, not by topic

Personal skills live in ~/.claude/skills, 31 of them. Area skills live at /Users/dan/code, 15 of them, so every repository under it inherits the design and output rules. Library skills live in the repository that needs them: career-record-app carries 9 Prisma skills and its own lockfile, and no other repository pays for them.

MCP for systems that exist, skills for ways of working

Four MCP servers are registered globally and each fronts a system with its own API: jcodemunch and Ahrefs over HTTP, plus a Cubitts server exposing the order, support and reporting estate. A skill cannot query a production database, and an MCP server is a poor way to carry a house style. The mistake is using one for the other's job.

Use a subagent when the review has to be independent

write-as-dan is the only subagent in the site repository. It reviews prose against the styleguide in a separate context, because a reviewer that shares the writer's context agrees with the writer. It runs the mechanical check script first and then reads for the failures a wordlist cannot see.

Tech Stack

Claude Code MCP Agent Skills Plane Impeccable Python

Result & Impact

58

Skills with a recorded use
document-task, 314 runs

Most-used skill
14 from two sources

Shared skills pinned by hash
4

MCP servers registered globally

The map is now measured rather than assumed: Claude records a use count per skill, which separates the ones doing daily work from the ones installed and forgotten. The most-used skill is a documentation-discipline skill rather than a coding one, and the design set is the largest installed group with some of the lowest counts.

Learnings

The use counts do not match the install counts. The design and taste group is the largest thing installed at the code root and Impeccable records 3 runs, while document-task records 314 without being a coding skill at all.
A skill you never invoke still costs you, because its description is in the prompt on every message. That makes an unused skill a recurring bill rather than a dormant file.
MCP tool schemas dominate context in the same way. A server exposing a large estate can cost more resident tokens than the conversation, which is the same accounting problem as skill descriptions one layer up.
Mirroring a skill directory for a second agent runtime only stays honest if the copy is generated. Two hand-maintained trees diverge on the first edit.

Three mechanisms, and the difference matters. A skill is markdown loaded when its description matches the task. A subagent is a separate context with its own instructions, used when the work has to be independent of the caller. An MCP server is a live connection to a system that already exists.

The counts below come from Claude’s own skillUsage record, not from memory.

Project and product management

The single most-used skill I have is not a coding one. document-task records 314 runs, and its job is to write a dated task document to code/docs/tasks/ after work lands, capturing the problem, the solution and the verification. It exists because the reasoning behind a fix evaporates faster than the fix does.

Around it: product-manager-toolkit for RICE prioritisation and discovery frameworks, linear for issue work, and loop at 32 runs. Issue tracking itself moved off Linear onto a self-hosted Plane, which changed this area from an MCP question into a hosting one, and Plane’s REST API takes an X-API-Key and does the rest.

Design

The largest installed group, and not the most used. Fifteen skills sit at /Users/dan/code/.claude/skills, mirrored into .agents/skills for a second agent runtime, covering brand kits, minimalist and industrial-brutalist directions, image-to-code, mobile and web image generation, and two generations of a frontend taste skill.

Fourteen are pinned:

"brandkit": {
  "source": "Leonxlnx/taste-skill",
  "sourceType": "github",
  "skillPath": "skills/brandkit/SKILL.md",
  "computedHash": "b63012f3c3d21197e0185d3e9cc7ec40c589fb10e0b5a32a561739de31aa3f20"
}

Thirteen of those come from Leonxlnx/taste-skill and one from ilo-lang/ilo. Impeccable is the fifteenth directory and the one absent from the lockfile.

Impeccable is the design-system layer rather than a taste direction: it writes PRODUCT.md, DESIGN.md and a machine-readable .impeccable/design.json into the repository, so a fresh session reads the visual rules without opening a prototype. On Lightning CV that is a 310-line DESIGN.md with 20 named colours, a typography scale and 11 components. It records 3 runs, which is the honest number for a thing used once per product rather than once per task.

Code review

Four skills, all with real counts, and they split by language. typescript-code-review at 93 runs and typescript-jsdoc at 40 carry the TypeScript work. rust-review at 30 and unsafe-checker at 5 carry the Rust side, the latter aimed squarely at FFI and raw pointers. comprehensive-code-review at 10 is the six-pass version reserved for a branch about to merge.

The site repository takes a different route for prose. write-as-dan is a subagent, not a skill, because a reviewer sharing the writer’s context agrees with the writer.

Business operations

This is where MCP earns its place over any skill. A Cubitts server fronts the order, support, lab and reporting estate: order lookup and progress, Gorgias ticket triage, Redshift queries, Metabase, store sales, paid-media spend. The matching skills are the workflows on top, and their counts are the highest outside documentation: check-orders 112, check-services 48, check-pay-links 44.

Nothing in that list could be a skill. A skill cannot read a production order state.

Codebase search and context

Two servers do the same job differently. jcodemunch runs as a local stdio process over a prebuilt symbol index, and graft answers “how does X work” from a repo graph with source inlined. Both replace several file reads with one call, which is the point.

headroom sits at a right angle to all of it: it compresses large tool output and hands back a hash to retrieve the original, so a big search result stops occupying the window. Ahrefs covers SEO over HTTP.

Registered globally, four servers:

jcodemunch   stdio   ~/.local/bin/jcodemunch-mcp serve
headroom     stdio   headroom mcp serve
ahrefs       http    https://api.ahrefs.com/mcp/mcp
cubitts      http    mcp.cubittsadmin.com/mcp

No project defines its own, deliberately. Claude Desktop carries three more for shadcn, Drive and a workshop dashboard.

Where the upstream sets live

code/ai-agent-skills/ holds seven upstream repositories read rather than installed: Anthropic’s own set, Microsoft’s, LangChain’s, addyosmani’s, badlogic’s pi skills, svssdeva’s, and the Agent Skills spec itself. Keeping them checked out and unlinked is how a skill gets evaluated without joining the resident prompt cost.

What I have not run

The Figma plugin is registered with a usage count of zero, so anything I write about the Figma path is reporting rather than review. Same for variate, whose README describes the agent writing four real versions of one file and a local sidecar flipping between them with arrow keys.