headcount: a department-store approach to Claude Code skills
An agent organization for Claude Code, structured as a company — 15+ departments, 125+ skills, each independently installable.
At a glance
- What is it?
- headcount packages 172 Claude Code skills into 16 independently installable departments under a chief executive layer. The design is coherent and the install path is short, but the README itself flags a real failure mode: skills that load when you did not want them.
- Who is it for?
- Adopt headcount if you want a named, scoped set of Claude Code skills you can install one department at a time and address as department:skill without collisions. Do not adopt it if your work is narrow enough that a handful of hand-written skills would do, or if you cannot tolerate a skill loading on a request you did not intend to route there.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 13 days ago.
- What is it written in?
- Mainly Markdown, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What headcount is trying to fix about Claude Code skills
The problem is distribution and scope, not capability. A Claude Code skill is a folder of instructions that loads when a request matches it, and the usual way to get a good one is to copy it from somewhere and drop it in. Do that ten times and you have ten skills with no shared vocabulary, no naming convention, and no way to tell which ones are relevant to the project in front of you. headcount's answer is to organize skills the way a company is organized: a chief executive over 16 departments, with 172 skills in total, each department shipped as an independently installable plugin. The tagline is "Add a department, not a prompt." The audience is anyone running Claude Code across more than one kind of work (security review, finance modeling, demand generation) who wants the skill set to be selectable rather than ambient. If you only ever do one thing with Claude Code, the structure is overhead you will not use.
The mechanism: plugins, namespaced skill names, and charters
Three mechanisms are visible in the README. First, packaging: every department is its own plugin, so a project loads only the functions it needs rather than all 172. Second, addressing: skills are named department:skill, given as security:threat-modeling and finance:unit-economics, which is what prevents name collisions when you install several departments. Third, delegation: each department ships an agent charter in .claude/agents/, so a department can be handed to a subagent with its own exclusive write surface. That last detail is the most interesting design choice in the repository. An exclusive write surface means two agents are not editing the same files, which is the usual way parallel agent work falls apart. The README also mentions reviewer-class departments that stop work rather than adding an opinion, and says docs/USE-CASES.md works through eleven cross-department situations including where such a department halts the work. That distinction between a skill that produces output and a skill that gates output is the part worth reading the docs for.
Installing one department and invoking it three ways
The install path is two commands. Add the marketplace, then install a department:
/plugin marketplace add cbrock84/headcount /plugin install security@headcount
Repeat the second command for each department the project needs. Invocation has three routes according to the README. Skills load themselves when a request matches the department's territory, so "why isn't this landing page converting?" pulls in demand-generation:landing-page-cro-expert and "review this design before we build it" pulls in security:threat-modeling. You can also call one by name when you want a specific lens: /finance:financial-modeling. The third route is delegation to the department charter as a subagent. docs/GETTING-STARTED.md is described as covering which departments to install first and what reviewer-class departments do differently. Nothing in the material specifies a required Claude Code version, a config file, or any setting beyond the two plugin commands, so treat the plugin system itself as the only prerequisite you can verify from here.
The auto-trigger is the sharp edge
Automatic loading is convenient and it is also the failure mode. The README's own routing table shows the trigger is the text of your request, not an explicit opt-in: ask a question in a department's territory and the specialist engages. Install the executive department and a stray sentence about stalled growth can pull in executive:business-growth-consultant when you wanted a two-line answer. Install many departments and the surface area for an unwanted match grows with each one. The repository does not, in the material available here, document a way to disable auto-triggering per skill or to pin a department to explicit invocation only. That is a limitation you should confirm yourself before rolling this out across a team, because the mitigation (install fewer departments) is the same lever as the benefit (install only what you need). The second constraint is breadth. 172 skills across 16 departments means most departments will be irrelevant to any single project, and the README's own department list runs to skills like fundraising-and-investor-relations and saas-idea-validator that many engineering teams will never invoke. A large catalog is not a quality signal; it is a selection problem you now own.
Where a plain skill directory is the better tool
The alternative is not another agent framework. It is the default Claude Code arrangement: a small .claude/skills directory in the repository, holding the three or four skills your team actually uses, written by the people who will read the output. The difference in approach is ownership and trigger control. A local skill directory is versioned with your code, reviewed in the same pull request as the change it supports, and contains nothing you did not put there. headcount trades that for breadth, a naming convention, and a marketplace install that takes one command. The trade is reasonable when you need coverage across functions you do not have specialists for, and unreasonable when you have one recurring task and a clear idea of how it should be done. There is a middle position the repository supports: install one department, keep your local skills for everything else, and let the department:skill prefix keep the two namespaces apart.
Maintenance, licence, and what the material does not tell you
The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the licence text, not legal advice; if you are vendoring departments into a product, read LICENSE and your own counsel's view. On maintenance, the material shows a last push of 2026-09-03 and no retrieved releases, so there is no release cadence to judge upgrade cost against. The structure implies the cost model: departments are independent plugins, so upgrading one does not force an upgrade of the others, and a skill you have forked locally will drift from upstream the moment the upstream department changes. The README also lists CONTRIBUTING.md and a PRs-welcome badge, which suggests outside contributions are expected, but nothing here indicates how changes are reviewed or how often skills are revised. If you depend on a specific skill's wording, pin your own copy rather than tracking the marketplace.
Who should install this, and what to check first
Install headcount if your Claude Code use spans functions you do not staff (a solo founder doing security review and unit economics, a small team that needs a threat-modeling pass before a design is built) and you want those skills named, scoped, and installable one department at a time. Skip it if your work is narrow, if you already maintain a local skill set you trust, or if an unexpected skill firing mid-conversation would cost you more than the coverage is worth. The first thing to verify is the trigger behavior in your own repository: install a single department, ask a question just outside its territory, and see whether it engages anyway. The second is the reviewer-class distinction, which docs/USE-CASES.md is described as covering in detail; that is where the design either earns its structure or turns out to be a catalog with a hierarchy drawn on top.
Editorial conclusion
Adopt headcount if you want a named, scoped set of Claude Code skills you can install one department at a time and address as department:skill without collisions. Do not adopt it if your work is narrow enough that a handful of hand-written skills would do, or if you cannot tolerate a skill loading on a request you did not intend to route there. Before installing, open the interactive org chart, read the department you actually need, and check its skill list against the work you do; the README's own table shows the trigger is the request text, not an explicit opt-in.
Community notes