Headcount 把 Claude Code 装成一家公司：1 名 CEO + 16 个部门（CTO/CISO/CFO/CMO 等）+ 172 个技能，每个部门独立可装、独立可委派为子代理，技能按 department:skill 命名避免冲突。适合想用公司视角管理 Agent 团队、做企业级角色化编排的开发者与组织。
Headcount 是一套"把 Claude Code 装成一家公司"的代理组织方案：1 个 CEO 协调 16 个部门（CTO/CISO/CFO/CMO/法务/HR 等），共 172 个技能。每个部门是一个可独立安装的插件（plugin），所以一个项目只装它真正需要的部门，而不是把 172 个技能全部拉进来拖慢会话。技能统一用 `department:skill` 命名（如 `security:threat-modeling`、`finance:unit-economics`），名字天然不会撞车；每个部门还带一份"agent charter"放在 `.claude/agents/`，可以让部门被委派成"独占写面"的子代理，互不踩脚。
普通 Skills 仓库是一个扁平的技能列表，要靠用户自己挑、组合、命名；Headcount 的出发点是"组织结构"：先有部门边界，再有技能，避免一个会话里几百个技能互相抢触发。它把"什么时候哪个部门该介入"这件事做成默认行为——例如你说"这个落地页为什么没转化"，`demand-generation:landing-page-cro-expert` 自动上场；你说"这个设计能上吗"，`security:threat-modeling` 自动上场；你说"请得起这个人吗"，`finance:unit-economics` 自动上场。
先 `/plugin marketplace add cbrock84/headcount`，再按项目需要 `/plugin install security@headcount`、`/plugin install finance@headcount` 这样逐个装部门。新手推荐先看 `docs/GETTING-STARTED.md`，里面讲哪些部门先装、三种调用方式（自然语言触发 / `/department:skill` 显式调用 / 子代理委派），以及"reviewer-class 部门"（如 security、finance、legal）和其他部门有什么区别。`docs/USE-CASES.md` 给 11 个跨部门场景（SOC 2 客户审查、跨站点链路、自动续费无人 owner 等）做端到端走查，看完就能照搬到自己的项目里。
三个高频痛点：(1) 一个会话塞太多技能容易互相误触发，分部门让边界更清晰；(2) 跨部门场景（如"合规客户来审查 + 法务出条款 + 安全做威胁建模"）很难让一个 Agent 跑通，分部门 + 子代理委派就顺；(3) 团队想统一口径时，部门即角色，角色即 charter——新人按角色就能找到对应部门的入口。它的设计哲学"加一个部门，而不是加一个 prompt"，与一堆分散 skills 仓库形成鲜明对比。
(a) 想用公司视角管 Agent 的技术负责人；(b) 跨职能项目（既要工程又要法务、合规、财务）的独立开发者或小团队；(c) 想给非技术同事（运营、市场、销售）也开 Claude Code "部门账号"的组织；(d) 已经在用 Claude Code 但觉得 skills 太杂想分层的资深用户。MIT 开源，PR 欢迎，对接 Claude Code 原生生态。
普通 Skills 仓库是一个扁平的技能列表，要靠用户自己挑、组合、命名；Headcount 的出发点是"组织结构"：先有部门边界，再有技能，避免一个会话里几百个技能互相抢触发。它把"什么时候哪个部门该介入"这件事做成默认行为——例如你说"这个落地页为什么没转化"，`demand-generation:landing-page-cro-expert` 自动上场；你说"这个设计能上吗"，`security:threat-modeling` 自动上场；你说"请得起这个人吗"，`finance:unit-economics` 自动上场。
先 `/plugin marketplace add cbrock84/headcount`，再按项目需要 `/plugin install security@headcount`、`/plugin install finance@headcount` 这样逐个装部门。新手推荐先看 `docs/GETTING-STARTED.md`，里面讲哪些部门先装、三种调用方式（自然语言触发 / `/department:skill` 显式调用 / 子代理委派），以及"reviewer-class 部门"（如 security、finance、legal）和其他部门有什么区别。`docs/USE-CASES.md` 给 11 个跨部门场景（SOC 2 客户审查、跨站点链路、自动续费无人 owner 等）做端到端走查，看完就能照搬到自己的项目里。
三个高频痛点：(1) 一个会话塞太多技能容易互相误触发，分部门让边界更清晰；(2) 跨部门场景（如"合规客户来审查 + 法务出条款 + 安全做威胁建模"）很难让一个 Agent 跑通，分部门 + 子代理委派就顺；(3) 团队想统一口径时，部门即角色，角色即 charter——新人按角色就能找到对应部门的入口。它的设计哲学"加一个部门，而不是加一个 prompt"，与一堆分散 skills 仓库形成鲜明对比。
(a) 想用公司视角管 Agent 的技术负责人；(b) 跨职能项目（既要工程又要法务、合规、财务）的独立开发者或小团队；(c) 想给非技术同事（运营、市场、销售）也开 Claude Code "部门账号"的组织；(d) 已经在用 Claude Code 但觉得 skills 太杂想分层的资深用户。MIT 开源，PR 欢迎，对接 Claude Code 原生生态。