Claude Code customization lives in plain files under ~/.claude/. Skills are markdown folders. Rules are markdown files. Hooks are shell scripts. Subagents are markdown with frontmatter. Slash commands map to any of the above. No build step, no plugin runtime, no manifest registry. Just files the binary reads on startup.

That simplicity hides how powerful the pattern actually is. A good customization 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 the customizations I have built and use almost every day: skills, hooks, rules, subagent definitions, and the patterns that connect them. 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.

The series URL slug stays claude-skills-toolkit for backwards compatibility, but the scope is the full set of Claude Code artifacts, not just skills.

Why share customizations

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.

These artifacts 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 an artifact 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 artifact solves, framed by an actual situation where the lack of it cost me time or caused a mistake.
  2. The structure: what triggers it (for skills and hooks), how it loads (for rules), what it owns (for subagents).
  3. The patterns inside that are worth stealing even if you do not use the exact same artifact (decision matrices, pre-flight checks, prompt templates, exit-code semantics).
  4. The lessons baked into it (the “why we do it this way” that comes from a past failure).

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

Categories

Posts are grouped by what the customization is for, not by what kind of artifact it is. A category usually mixes skills, rules, and hooks because real workflows do too.

CategoryExamples
Spawning and agentsnf-agents, subagent definitions for fullstack engineer and UI designer, the cooperative shutdown protocol.
Git workflowCommit format rule, branch naming convention, the cross-branch merge rule that forbids checkout for merges.
Config syncnf-cc-sync for branch-per-machine ~/.claude/, the memory submodule pattern.
Memory and contextnf-memory to wire autoMemoryDirectory, nf-dream for memory consolidation, MEMORY.md index conventions.
Editor and environmentnf-direnv for repo-scoped env vars, nf-ignore for AI-tool gitignore patterns, the .local/ folder convention.
Safety and conventionPermission deny rules from real incidents, agent-safety rules for worktree isolation, no-em-dash convention for AI-detection.
Authoring toolsclaude-authoring for writing new skills and rules, claude-changelog for tracking CC version changes.
Subagent personasfullstack-engineer (backward-compat-first), svg-diagram-specialist (inline SVG diagrams), ui-ux-designer (design-first, code-second).

A reader who wants “everything for git workflow” can pick that category. A reader who wants “every skill no matter the topic” can filter by the skills tag.

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 post is nf-agents, a skill that manages spawning Claude Code teams and standalone agents safely. I reach for it 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.
  • Customizations too tightly coupled to one company or vendor (CRM-specific, internal-API-specific). They tend not to translate.
  • Skills or rules that are basically “a list of bash commands I always forget.” Those belong in a personal cheatsheet.
  • Anything that requires sharing credentials, internal URLs, or proprietary tooling to be useful.

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

Status

Series is in active publishing. Expect roughly one artifact every couple of weeks, ordered by how often I use it, not by how exotic it is. Tier S customizations (rules and skills I use daily) come first.

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