Headcount: Claude Code as an Org Chart

Somebody finally answered the question that every large skills repository dodges: once you have 143 of these things, who's in charge of them? A headcount Claude Code install answers it with an org chart. Sixteen departments, each one an independently installable plugin, each headed by a role you'd recognise off a real leadership page (CTO, CISO, CFO, CMO), and every skill addressed as department:skill so two of them can share a name without colliding.

Chris Brock put the repository up on 28 August 2026. It hit 290 stars and 39 forks in its first two days, as of 30 August 2026, with no tags and no releases cut yet. The whole thing is Markdown; there's no runtime to install and nothing compiles.

What headcount actually installs

A headcount Claude Code setup is two commands, and neither of them installs the whole thing:

/plugin marketplace add cbrock84/headcount
/plugin install security@headcount

Each department is its own plugin. Pull in security and you get six skills; skip marketing and its eighteen never enter your context. That constraint is the reason the project is worth a look at all, because the failure mode of every mega-repo of prompts is that you load 400KB of instructions into a session that needed four of them.

Skills load themselves when a request matches. Ask "why isn't this landing page converting?" and demand-generation:landing-page-cro-expert engages; ask "can we afford this hire?" and finance:unit-economics does. You can also call one by name when you want a specific lens rather than whatever the matcher decides: /finance:financial-modeling.

The naming scheme does real work here. Skill collisions across large installs are a genuine nuisance, with three different repositories all shipping something called code-review, and namespacing by department kills that class of problem outright without a registry.

Sixteen departments, 143 skills, counted

The GitHub description says "15+ departments, 125+ skills." The README badges say 16 and 143. Those aren't in conflict, but they're not the same number either, so I added up the department tables in the README myself: 6 + 18 + 6 + 8 + 9 + 18 + 11 + 8 + 10 + 10 + 7 + 5 + 6 + 5 + 10 + 6. That's 143 across 16 departments, matching the badges. The description on the repo page is just behind.

Technology and Marketing are the biggest at 18 skills each. Customer Experience and Corporate Strategy are the smallest at five. Office of the CEO carries six, including saas-idea-validator, which the README describes as returning a verdict rather than encouragement. That's a small line, and it tells you something about the author's taste.

There's an interactive org chart on GitHub Pages that's searchable across every skill and links each one back to its source file. Open that before you install anything; it's a faster read than the README.

The idea worth stealing: split agents by write surface

Buried under "How it is organized" is the sentence that justifies the whole company metaphor:

Agents split by exclusive write surface, not by topic. The README's argument is that a topic split has no checkable boundary, and two agents assigned to "SEO" and "UI" will both end up editing the same file. Ownership of a path is checkable. Ownership of a subject is a vibe.

So docs/AGENT-SURFACES.md maps every path to exactly one owner, and CI enforces it. ./scripts/check-all.sh verifies the surface map is coherent, that every skill's frontmatter is valid and unique, that no third-party licence text has crept in, that every department:skill reference in the docs resolves, and that spelling is US English. Adding a department requires a roster row, a surface block, a charter in .claude/agents/, and a marketplace entry, all in one change, or the check fails.

That's a lot more discipline than most skills repositories bother with, and it's the part you can take even if you never install a headcount Claude Code plugin. If you're already running several agents at once, the pattern we've covered in running Claude Code agents in parallel, then the write-surface rule is the cheapest way to stop them from stepping on each other.

Departments that can stop the work

Security and Legal & Risk are marked reviewer-class, and the README is specific about what that buys you: their blocking findings can't be overruled by the department under review, which is why both report to the chief executive rather than into the function they audit.

Read that as a prompt-engineering trick rather than as governance. Nothing here is enforced by software; a skill can't actually stop Claude from writing a file. What it does is give the model a reason, in its own instructions, to refuse a change it would otherwise wave through; models are noticeably better at holding a line when the line is written down as somebody else's job. docs/USE-CASES.md walks seven cross-department situations end to end (a SOC 2 demand from an enterprise prospect, a security incident, a stalled funnel), including the points where a reviewer department halts the work instead of adding an opinion.

Whether it holds under pressure is exactly the kind of thing you'd want to run for an hour and read the transcript of, which is where the practical problem shows up. A review gate only means something if the run lasts long enough to reach it, and a session tied to an open terminal doesn't. That's the gap MoClaw covers: a hosted cloud AI computer that stays up, so a multi-department run has somewhere to finish rather than dying with your SSH connection.

Where this sits in the multi-agent turn

Skills went from a niche Claude Code feature to a small economy in about four months, and the shape of the repositories keeps changing. First came single skills. Then collections. Then the marketplaces that index the collections, which we tracked in our roundup of the best Claude skills. Headcount is the next rung: not a list of capabilities but a structure imposed on them, with reporting lines and an escalation path built in.

The company metaphor earns its place for one reason. A flat folder of 143 skills has no answer to "which of you handles this, and who checks your work." An org chart does, and it happens to be a structure that both the model and the human reading the transcript already understand without being taught. If you want the background on how skills differ from tools and subagents in the first place, our explainer on agent skills covers the primitives.

Each department also ships an agent charter in .claude/agents/, so you can delegate to a department as a subagent with its own exclusive write surface rather than loading it into your main context. That's the version I'd actually run.

What it costs, and what it isn't

Free, MIT, and the LICENSE file is plain MIT text rather than something exotic. I checked the file directly rather than the API field, because GitHub's licence detection gets it wrong in both directions often enough to be useless: it has reported NOASSERTION for plain MIT, and it has also missed a non-commercial clause sitting in the file. Every skill in the repository was written for it, per the README, rather than vendored in from elsewhere.

What it isn't: software. The language is Markdown. Nothing here executes, nothing here calls an API on its own, and the value is entirely in whether the written instructions change what Claude does. A two-day-old repository at 290 stars is a distribution signal and not much else; there are no releases, no version tags, and no track record. Install a department, run it against work you already understand, and see whether the output differs from what you'd have got by asking plainly. Star counts on a two-day-old repository measure how well a launch post travelled, nothing more.

You'll also want Claude Code itself, which means an Anthropic subscription or API credits. Headcount doesn't change what you pay for inference; it changes what gets said to the model before your question does. And since a headcount Claude Code session can run long (sixteen departments arguing through a SOC 2 scenario is not a thirty-second task), the machine hosting it matters more than usual. MoClaw rents you that machine by the credit rather than by the hour of your attention.

Two things I'd check before trusting it

The first is whether a department's skills are actually distinct from what Claude does unprompted. A lot of skill content in this genre restates good practice the model already applies, and the honest test is boring: run a task twice, once with the department installed and once without, and diff the two transcripts. If the outputs are the same, you've spent context for nothing. I'd start with security:threat-modeling and finance:unit-economics, because both cover territory where a general-purpose answer tends to be vague and a structured one is obviously better.

The second is the read on docs/DECISION-LOG.md, which holds numbered decisions with their options and recommendations. It's the closest thing the repository has to a rationale trail, and it tells you whether the sixteen departments were designed or assembled. A project that writes down why it rejected an option is a different animal from one that ships a folder and a README.

Neither check takes long, and both are cheaper than discovering in month two that your agents are quoting a people:performance-management skill at each other. What they do need is somewhere to run that isn't fighting your editor for memory: a company of agents pegs a laptop fast, which is the axis MoClaw works on, giving the run its own machine so your own one stays free for the work you're doing by hand.

FAQ

Is headcount free?

Yes. MIT licensed, no paid tier, no account. You still need Claude Code and whatever Anthropic plan or API credits you use with it.

Do I need Claude Code to use headcount?

Effectively, yes. It ships as Claude Code plugins and installs through /plugin marketplace add cbrock84/headcount, and the department charters live in .claude/agents/. The skill files themselves are plain Markdown with frontmatter, so another agent that reads the same format could load them, but nothing about the install path is portable today.

How are the 143 skills installed?

One department at a time. /plugin install security@headcount gives you that department's six skills and nothing else. There's no single command that installs all sixteen, and that's deliberate: a project should load only the functions it needs.

Is it 125 skills or 143?

143, across 16 departments, if you add up the README's own tables. The "15+ departments, 125+ skills" phrasing in the GitHub repository description is stale.

Can a reviewer department really block a change?

Only in the sense that the instructions tell the model to treat a blocking finding as final. There's no runtime enforcement, no CI gate on your project, and no mechanism outside the conversation. Treat it as a strong default rather than a control.

Does a headcount Claude Code department slow down my sessions?

Every skill you install competes for the model's attention, which is the argument for the per-department split. Install the two or three departments the project actually needs and the overhead is small; install all sixteen and you've rebuilt the problem the design was avoiding.