From three skills to a department

One skill does one task. Three skills that know about each other, share the same rules and run in a fixed order are a department. This guide shows how I build that, using a social media department as the example.

The problem with loose skills

Say you have three skills: a hook writer, a caption writer and a post reviewer. Each one works. But you’re the glue between them. You copy the hook into the caption request. You remember to run the reviewer. You explain your rules again in every chat.

A department takes the glue work off your plate. The employees know the order, read the same rules and hand work to each other. You come in at the two moments that matter: approving the text and approving the result.

Three building blocks

Claude Code gives you three kinds of files. They look alike, but they have different jobs.

Block	What it is	Where it lives	Think of it as
Skill	Instructions for one task	`.claude/skills/<name>/SKILL.md`	A procedure
Subagent	A separate AI worker with its own role, tools and memory	`.claude/agents/<name>.md`	An employee
Command	A task you start yourself with `/name`	`.claude/skills/<name>/SKILL.md` (or the older `.claude/commands/<name>.md`)	A button

Skills

A skill is one task, written as instructions. The anatomy of a skill guide covers it in full. In a department, skills are the procedures: “write five hooks”, “write a caption”, “review a post”.

Subagents

A subagent is a separate AI worker. Claude hands it a task, it does the work in its own context window (its own working memory, separate from your main conversation) and only sends back the result. That keeps your main chat clean. It also lets you give each employee only the tools it needs.

A subagent is a markdown file in .claude/agents/ with frontmatter at the top. Frontmatter is the block between two --- lines with settings in key: value form. Two fields are required:

Field	Required	What it does
`name`	Yes	The employee’s name, lowercase with hyphens
`description`	Yes	When Claude should hand work to this employee
`tools`	No	Which tools it may use. Leave it out and it gets all of them.
`model`	No	Which model it runs on, for example `sonnet`, `opus`, `haiku`, or `inherit` for the same model as your main chat
`skills`	No	Skills loaded into its memory from the start
`permissionMode`	No	How it handles permission prompts

The docs list more optional fields. These are the ones I use most.

An example lead employee for a social department:

---
name: social-lead
description: Plans, writes and reviews the social posts for the week. Use for planning a content week, writing hooks and captions, or reviewing a post before approval.
tools: Read, Write, Edit, Glob, Grep
skills:
  - hook-writer
  - caption-writer
  - post-reviewer
---

You are the content editor of this business. You write in the founder's
voice, first person.

Read first: CLAUDE.md, .claude/rules/, then the brain folder
(company, audience, voice).

How you work: plan the week, write each post (hooks, then caption),
run the reviewer, then stop and wait for the founder's approval.

Rules: every claim comes from the brain folder. No invented numbers.
You never publish.

Example: a simplified, fictional version of a real employee file.

Notice what’s not in the tools list: Bash, the tool that runs shell commands. This employee writes files and nothing else. It can’t publish even if it tried.

Claude decides when to hand work to a subagent by reading its description. You can also ask for it by name: “Use the social-lead subagent to plan next week.”

Commands

Commands and skills have merged in Claude Code. A file at .claude/commands/plan-week.md and a skill at .claude/skills/plan-week/SKILL.md both give you /plan-week, and they work the same way. Older command files keep working, but the docs recommend skills for new work.

What makes something a “command” is how you use it: a step you start yourself, on purpose. For those, add disable-model-invocation: true to the frontmatter. Then Claude never starts it by itself. That’s what you want for “plan the week” or “ship the week”: things with timing you control.

CLAUDE.md: the job description of the folder

Every department folder has a CLAUDE.md at the top. Claude Code loads it at the start of every session in that folder. It’s the job description of the department: what it does, who works there, in which order, and what it never does.

What I put in it:

One paragraph on what this department is for.
What to read first: the brain folder, the rules, the strategy.
The employees: a table with each subagent, its role and the command to start it.
The flow: the steps of a normal week, in order, with the approval gates marked.
The gates: what never happens without a human.
Settings: language, paths, how many posts per week.

The docs suggest keeping each CLAUDE.md under 200 lines. Longer files use more memory and Claude follows them less well. So I keep it to the facts every session needs, and move the rest out.

Rules files

Rules that every employee must follow go in .claude/rules/, one topic per file: voice.md, no-fiction.md, hooks.md. Claude Code loads these at the start of the session, just like CLAUDE.md. A rules file can also be limited to certain files with a paths field in its frontmatter. Then it only loads when Claude works on those files.

Why separate files and not one big CLAUDE.md? Because you can share them. My hook rule lives in one place and is copied into every department that writes hooks.

How a department folder is laid out

A real-shaped social department:

social/
├── CLAUDE.md                  job description of the department
├── .claude/
│   ├── settings.json          permissions, hooks, locks
│   ├── agents/
│   │   ├── social-lead.md     plans, writes, reviews
│   │   └── producer.md        turns approved text into video and images
│   ├── skills/
│   │   ├── plan-week/         command: plan the week
│   │   ├── hook-writer/       five hook options per post
│   │   ├── caption-writer/    the full caption
│   │   ├── post-reviewer/     PASS or FIX per rule
│   │   └── ship-week/         command: package approved posts
│   ├── rules/
│   │   ├── voice.md
│   │   ├── hooks.md
│   │   └── no-fiction.md
│   └── hooks/
│       └── block-publish.py   stops any publish command
├── context/
│   ├── strategy.md            pillars, formats, rhythm
│   └── idea-bank.md           ideas waiting for a slot
└── output/
    └── weeks/
        └── 2026-W44/
            ├── plan.md
            └── posts/

Three zones, each with one job:

.claude/ is how the department works: employees, procedures, rules, safety.
context/ is what only this department needs to know: its strategy, its ideas.
output/ is where finished work lands. Nothing leaves this folder by itself.

A weekly flow

Here’s how one week runs in the social department. The approval steps are yours.

Plan. You run /plan-week. The lead employee picks ideas from the idea bank, spreads them over the week and creates one empty file per post with the brief filled in.
Write hooks. For each post, the hook writer (BX-003, keyword HOOKS) writes five hook options.
Write the caption. The caption writer (BX-018) takes the chosen hook and writes the full caption.
Review. The post reviewer (BX-004, keyword CHECK) checks each post against the rules and gives PASS or FIX per rule.
You approve the text. Gate 1. You read every post, fix or send back what’s not right, and approve the rest.
Produce. Only approved posts go to the producer, who turns them into video or carousel images.
You approve the result. Gate 2. You watch and read the final output.
Ship. You run /ship-week. The approved files are packaged in one folder. You post them yourself or schedule them in your own tool.

The employees do steps 1 to 4, 6 and the packaging in 8. You do 5, 7 and the actual posting. The human in the loop guide shows how to make sure it stays that way.

Tip: start each week by reading last week’s notes. If you sent posts back for the same reason twice, turn that reason into a rule in .claude/rules/. The department gets better because your feedback becomes part of it.

One brain for all departments

Once you have a second department, say email, you hit a new problem. Both need to know who you are, what you sell and how you write. If each one keeps its own copy, they drift apart.

So the business knowledge lives in one place, outside the departments:

my-company/
├── brain/                 one source: company, offer, audience, voice, proof
│   └── proposals/         changes waiting for your approval
├── social/                reads brain/, writes to social/output/
└── email/                 reads brain/, writes to email/output/

Every department reads the brain.
No department writes to it directly. New knowledge becomes a proposal in brain/proposals/, and you decide.
Each department keeps its own context/ for things only it needs.

Change your offer once in the brain, and every department uses the new version the next time it runs.

When a department is worth it

Not every task needs a department. Single skills are often the better choice.

Use single skills when	Build a department when
You do the task now and then	You do it every week
One step, one output	Several steps that depend on each other
You’re happy to be the glue	You keep repeating the same instructions
One person, one chat	You want the same quality every time, also when you’re tired
You’re still finding out what works	You know the process and want to fix it in place

My advice: start with one skill. Use it for a few weeks. Add the second when you notice you always run it right after the first. When you have three skills that always run together and you keep explaining the same rules, it’s time for a folder with a CLAUDE.md.

Common mistake: building the whole department on day one. You end up with ten employees and no idea which one is weak. Build it one employee at a time, and test each one on real work before you add the next.

The whole company

A department is one folder. Put several next to each other (social, email, sales, finance), give them one shared brain and one lead who sends the right task to the right department, and you have a whole AI company. That’s what I’m building in public, one employee per post. I call it Founder AI OS.

Back to all guides.