A Claude Code skill is just a folder under ~/.claude/skills/<name>/ with a SKILL.md file. The frontmatter declares when the skill should trigger, the body tells the model what to do once it has triggered. That is it. No build step, no plugin runtime, no manifest registry.

That simplicity hides how powerful the pattern actually is. A good skill captures a workflow you have refined over weeks (the questions you ask yourself, the steps you do not skip, the mistakes you have already paid for) and re-runs it deterministically every time. It is the difference between “I will do my best to remember” and “the system enforces the procedure.”

This series collects skills I have built and use almost every day. Each post is white-labeled (no client names, no company-internal references) so you can lift the patterns into your own setup with minimal editing.

Why share skills

Most Claude Code tutorials show you what the model can do. Few of them show you the scaffolding people put around the model to make it dependable, the small files that turn ad-hoc prompting into a stable workflow.

Skills are exactly that scaffolding. They live in plain markdown, they are version-controllable, and they encode hard-won lessons (mostly the result of incidents). Sharing them is high-leverage because the format is portable: copy the folder, edit the parts that mention your tools, and the skill works in your environment too.

I am also writing this for myself. Forcing myself to white-label and explain a skill is the cleanest way to find the parts that are crufty, the parts that only worked because of one specific project, and the parts that deserve to be promoted into a global rule.

What you will get from each post

Every post in the series follows the same shape:

  1. The problem the skill solves, framed by an actual situation where the lack of a skill cost me time or caused a mistake.
  2. The skill structure: what triggers it, what arguments it takes, what files it expects.
  3. The patterns inside that are worth stealing even if you do not use the exact same skill (the decision matrices, the pre-flight checks, the prompt templates).
  4. The lessons baked into the skill (the “why we do it this way” that comes from a past failure).

One skill, one post. If a skill is large enough that splitting helps the reader, I will say so explicitly, but the default is a single self-contained write-up per skill.

Reading order

I publish out of order. The series page lists every part with its seriesOrder, so you can read sequentially or jump to the one that is closest to your current pain point.

The first skill I am publishing is nf-agents, which manages spawning Claude Code teams and standalone agents safely. It is the skill I reach for whenever I have parallel work I want to delegate while keeping the main session as the coordinator. The post covers the five modes, the four design decisions inside the skill (backend choice, worktree base branch, standby vs tasks, the cooperative shutdown protocol), and the mistakes the skill exists to prevent.

A few conventions you will see throughout the series

  • ~/.claude/ is the standard Claude Code config directory. Skills live in ~/.claude/skills/, rules in ~/.claude/rules/, settings in ~/.claude/settings.json.
  • disable-model-invocation: true in a skill’s frontmatter means the skill is user-invoked only (you have to type /skill-name for it to run). I use that for skills that take real actions or spend time, where I do not want auto-trigger.
  • isolation: "worktree" when spawning agents puts each agent in its own git worktree. That is how I let agents commit and push without stepping on my live working copy.
  • No em-dashes or en-dashes in any post body. Plain ASCII punctuation only. (Aesthetic choice, partly to keep the prose readable in monospace and on terminals.)

What is not in this series

  • Setup tutorials for Claude Code itself. The official docs cover that better than I would.
  • Skills that are too tightly coupled to one company or vendor (CRM-specific, internal-API-specific). They tend not to translate.
  • Skills that are basically “a list of bash commands I always forget.” Those belong in a personal cheatsheet, not in a shared skill.

If a skill survives white-labeling without losing the core insight, it gets a post. If it does not, it stays private.

Status

Series is just starting. Expect roughly one skill every couple of weeks, ordered by how often I use the skill, not by how exotic it is.

Subscribe via the claude-code tag if you want updates whenever a new part lands.