Claude Code Skills, Subagents, Hooks: The Real Thing Is Files and Folders

Claude Code is a terminal tool you talk to while it reads files and runs commands. Once you start repeating the same explanations and the same procedures in the same project, you need somewhere outside the chat window to leave your rules and your ways of working.

Project rules, for instance, can be pinned to a file. A repeated procedure can be called up with a single command, and side work like research can be handed off to its own separate context. You can also make a command run automatically at a specific event or a specific time. CLAUDE.md, plugins, skills, subagents, and hooks each do a different job here.

At first, all of these sound like unfamiliar jargon. But in actual form, most of them are markdown files, folders, and config files. The official overview groups CLAUDE.md, skills, and hooks together under customization; subagents get their own separate section; and plugins are covered in a separate document about extending Claude Code. This lesson starts by sorting out each feature's role and form, then works out what order makes sense to learn them in.

If an earlier track had you open a terminal, install Claude Code, ask your first question, and connect an MCP server, it's time now to tell apart the role and form of the features that sit outside the chat window.

Customization

Customization is how you get Claude Code to follow project rules, call up repeated procedures, split off part of the work, and run commands at a set moment. CLAUDE.md and SKILL.md are markdown files, subagents are markdown files too, and a hook is the hooks entry inside settings.json. A plugin is a package that bundles these elements together for install.

Comparing customization features: roles and file forms

Rather than memorizing the names first, look at what each feature replaces and where it lives, and the distinctions get easier. The table below covers the role, actual form, usage signal, and the order this track handles them in, all at once.

In that table, plugins sit at a different tier from the rest. CLAUDE.md, skills, subagents, and hooks are all features where I set the rules and procedures myself, or split off work myself. A plugin is a package that bundles skills, hooks, subagents, and MCP servers into a single install unit, bringing in something someone else already built.

You don't need to build all of these from day one. Reach for CLAUDE.md when you miss the same rule twice, and reach for a skill when you repeat the same procedure. Move on to the next feature once your conversation fills up with search results, or once a human has to press start at some fixed point every time.

CLAUDE.md: pinning project rules

CLAUDE.md is the project or personal rule file Claude Code reads when a session starts. You hand it whatever needs to hold across multiple sessions: coding standards, how you like work done, review criteria.

In form, it's a markdown file: ./CLAUDE.md at the project root, .claude/CLAUDE.md inside the project, or ~/.claude/CLAUDE.md in your personal home folder. For scope and how to make Claude Code read AGENTS.md alongside it, see the CLAUDE.md writing lesson.

Plugins: installing what's already been built

A plugin is a package that bundles several extension elements someone else built into a single install unit. It brings in the pieces that widen what Claude Code can do: skills, subagents, hooks, MCP servers.

In form, it's a package you discover and install from a marketplace. For registering a marketplace and installing, disabling, or removing a plugin, see the plugin installation lesson.

Skills: saving repeated procedures as files

A skill is an extension unit that packs a repeated procedure and reference guidance into SKILL.md, which Claude Code loads whenever it needs it. It cuts down on re-explaining the same sequence of work.

In form, it's a named folder holding a SKILL.md file: .claude/skills/<name>/SKILL.md for a project skill, ~/.claude/skills/<name>/SKILL.md for a personal one. For how to write and call one, see the skill-building lesson.

Subagents: handing off side work separately

A subagent is an independent agent configuration that handles a specific task in its own separate context. It splits off side work so search results and logs don't pile up in your main conversation, and hands back only the result.

In form, it's a markdown file placed in .claude/agents/ or ~/.claude/agents/. For what to delegate and how context gets used, see the subagents lesson.

Hooks & scheduling: running on events and time

A hook is an automation feature that ties a shell command to a specific event, like a session starting or a file being edited right after. Scheduling runs a task once a set time arrives instead. Both keep a human from having to press start, but one reacts to an event and the other to a clock.

A hook's form is the hooks entry in settings.json. Scheduling is a separate setup: a cloud routine, a desktop scheduled task, or something like /loop. For which events and schedule conditions to use, and how to keep the scope safe, see the hooks and scheduling lesson.

Learning order: from CLAUDE.md to automation

This track runs in the order CLAUDE.md, plugins, skills, subagents, hooks and scheduling. You pin project rules to a file first, then install something someone else built, then turn your own procedure into a skill, hand off side work to a separate context, and finally hand off even the moment something starts to automation.

Judged purely by the burden of building it, installing a plugin is the lightest and automation the heaviest. But this track covers CLAUDE.md first, because the skills, subagents, and automation lessons that follow all reuse the rules written into that file. The learning order isn't set by weight alone; it also accounts for what the next lesson needs as an ingredient.

Checking the .claude folder: where the files actually live

The features covered above aren't just menus on a screen. They sit as files and folders in a project's .claude/ and in your computer's home folder ~/.claude/. A project's .claude/ can hold items like settings.json, settings.local.json, skills/, agents/, rules/, commands/, and a hook isn't a separate folder, it's the hooks entry inside settings.json. Home also has your personal CLAUDE.md and projects/, where automatic memory accumulates.

I didn't run this check myself until much later. The first time I opened .claude/, there was already something inside it, and I found that strange enough that I assumed it was being managed automatically. I kept building things project by project without ever looking inside.

Then one day I found that a project folder I'd been working out of for a while was empty, and a skill I thought I'd already set up hadn't actually been built right. I'd assumed everything was going fine just because it usually was, for me at least. That's when it first hit me that I needed to learn the folder structure. The two commands above make up for the check I wish I'd run back then.

MCP: connecting to external services

MCP (Model Context Protocol) is the shared standard that connects Claude Code to an outside service like a database or Slack(슬랙). Where the features above decide what rules Claude Code follows and what procedures it runs, MCP lets Claude Code reach an outside service's data and functionality.

That's why MCP isn't one of the customization features this lesson covers. Track 2 (Connect) already explained MCP as a shared standard, and Track 3 (the CLI track) had you make an actual connection with claude mcp add. Rather than repeat that here, this lesson just points back to those earlier tracks.