headcount

一个按公司的方式组织的技能库。一位首席执行官之下是十六个部门——安全、法务与风险、财务、人事、市场、IT 运维、项目管理办公室等等——每个部门都是一个可以单独安装的插件，于是一个项目只加载它需要的职能。部门里共有 172 个技能，以 department:skill 寻址，名字因此永不冲突；每个技能是一个目录，里面的 SKILL.md 在请求与它的描述匹配时加载。其中两个部门是评审类：安全和法务与风险审查其他部门做出来的东西，自己不持有任何写入面，向首席执行官汇报而不向它们所审查的职能汇报，而且它们提出的阻塞性发现不能被被审查的部门推翻。同一棵树既能通过插件市场装进 Claude Code，也能通过另一套清单装进 ChatGPT 与 Codex，因为技能文件完全一样，只有清单不同。凡是答案由外部权威裁决的地方，技能就在自己的 references/ 里带上要对照的来源——150 个技能共 184 条，每条都标着可以拿它做什么。MIT 许可，全部文字都是为这个仓库写的。

谁做的按账号资料，他是亚特兰大的一位 CIO，公司一栏写着 Drummond IT、Keel GRC 和 vibld；账号 2015 年注册，57 个公开仓库，62 个关注者。他是这个仓库唯一的人类作者：87 次提交里有 44 次出自他，分散在两个身份下——39 次用 cbrock84@gmail.com，5 次用 chris.brock@drummond.com，后者在 GitHub 上归属另一个账号 chris-brock；另有 42 次由 Claude 以 noreply@anthropic.com 署名提交。剩下的 1 次来自一位外部贡献者；36 次提交带共同作者尾注，其中 33 条写的是 Claude Opus 5。

1. 01

   技能库先于仓库存在，而它的大部分必须重写

   仓库建于 2026-08-28，而它最早的几次提交搬进来的是已经存在的东西：在作者自己名下的仓库里找到五个 MIT 许可的技能合集，共 106 个技能，取用其中 84 个——其余 22 个作为重复、被取代的版本或带作者个人色彩的内容跳过——另有 12 个来自一个共享 Drive 文件夹，既没有许可证也没有任何条款说明。这两批后来都得处理掉。这个仓库是要被安装的插件市场，安装就是分发，所以受影响的技能全部重写，原件、它们的 references、打包进来的数据集、字体二进制和许可证文件一并删除——77 个 vendored 技能，然后是那 12 个 Drive 技能，再然后是第一轮重写取代掉的那些。代价被写下来而不是含糊过去：被删掉的一部分是数据而不是文字，包括一个样式与配色数据库和一批授权字体；它们无法重新撰写，于是替代的设计类技能改为教方法、不再附带数据集，日志把这称为「a real capability reduction, accepted knowingly」。同一次事故还留下一条常设规则：在替换品与原件比对过之前，绝不删除原件——第一次执行时是先删原件、再照着一份名称与描述清单写替代品，覆盖度从未与真实内容核对。后来那 100 个被取代的技能从 git 历史里恢复出来逐个与后继者比对，六个丢了实际内容被补回，还有一个无处安放的能力单独成了一个技能。仓库现在有 1,745 个星、263 个 fork、11 个 watcher 和 3 个未关闭条目。

2. 02

   十六个部门，以及把每一对之间的边界写进技能里

   形状很早就定了，之后又被自己质疑了三周。所有技能描述都会加载进上下文，所以在技能数过百之后，作者选了把部门做成各自独立的插件，而不是一个扁平的技能目录，随后又把它扩展成一套 C 级高管层级。接下来的过程就是一部「线画在哪里」的记录。安全独立成部、拥有自己的 CISO 章程，而不是作为一组技能挂在技术部下，理由是：把 CISO 建模在 CTO 之下，恰好复刻了这个角色本来要防止的冲突。一个空壳的行政部被拆进法务与风险和首席执行官办公室，然后被删掉，而不是留作占位。没人主动要求的三个部门——客户体验、数据与分析、公司战略——在一次覆盖度检查指出「支持」是目录里最显眼的缺失之后，一起以各五个技能建成。项目管理从运营部里拿出来，变成向首席运营官汇报的项目管理办公室，因为仓库的立身规则是按独占写入面切分，而项目管理是一个横跨全部十六个部门的主题。公司 IT 从产品工程里拆出来，而促成这次提问的四处重叠被写进了技能本身：访问策略归谁、入职转岗离职流程的执行归谁、恢复目标归谁、技术性恢复归谁。覆盖度随后不再靠人看，而是拿 BLS 标准职业分类对照，查出八处缺口——其中六项是分类法点名而目录里确实没有的职能，包括税务与采购。

3. 03

   按写入面切分 agent，以及在第一条轴不够用之后加上的第二条

   executive:agent-hierarchy 就是这套方法：它取自一个约二十四个 agent、跨 1,500 个文件的 monorepo 实现，在这里以一个技能的形式发布，带一份 415 行的 playbook、三份起始花名册、一段填空式引导提示词，以及一个可执行的守卫。它的立身规则是按独占写入面切分，而不是按主题切分——按主题切分没有可校验的边界：一个管 SEO、一个管 UI，最后两个都改同一个 token 文件，而且谁都没错。两个类别是：builder，只在自己那一块写入面里编辑、永不提交；reviewer，永久只读、可以始终并行。编排者两者都不是，它是唯一的提交者。这张地图放在一个文件里，即 docs/AGENT-SURFACES.md：每个 agent 一行，每块写入面一段 glob，每条路径只有一个主人；agent-guard.mjs check 会在一条路径被认领两次或无人认领时让 CI 失败。.claude/agents/ 下有二十一份章程，每个已安装的行一份；有行无章程、或有章程无行，同样会让这个检查失败。第二条轴之所以存在，是因为第一条只回答了 agent 可以在哪里写，从来没回答这次写能不能不经决定就落地——而在实践里，那件事一直是每次派活时凭记忆决定的。authority 有三个取值：派出去直接收结果，落地前先把 diff 摆出来，或者根本不要主动派。二十一行里有十九行取第一个值，作者为此辩护而不是拿它装点门面，因为一个部门只会在自己的插件目录里写东西；两个例外，一个是掌握检查脚本与生成器的 agent，一个是掌握行业包的 agent——后者的产出会发到别人的仓库里。

4. 04

   一份引用目录，以及一个决定 agent 能做什么的许可类别

   目录里的每条外部权威都是一个条目：id、标题、发布者、https 链接、许可类别、司法辖区、一句说明它裁决的是什么问题、它服务哪些技能、可选的机器可读形式，以及链接最后一次核验的日期。sources/security.toml 的第一条是 NIST SP 800-53 Rev. 5——美国联邦系统据以评估的控制目录，也是 FedRAMP 和许多私有框架继承的词汇表——按美国政府作品归为公有领域，于是 agent 可以引用它，条目旁边还记着 OSCAL 内容仓库，一条来源同时服务三个安全技能。同一个文件里，ISO/IEC 27001 被标成需要购买，后面跟着由此而来的指令：只引条款号，绝不引原文。这个区分就是整个功能的意义。允许的许可类别有十种，检查器强制这份清单；其中三种——可免费阅读、需账号登录、需购买——存在的唯一目的，就是标记那些最常被误以为可以自由使用的来源，而两种类别之间拿不准时的取舍规则是取更严格的那个。184 条来源里，125 条可引用，其余只能读和标注。收录标准比听起来更严：一条来源只有在它能裁决两位有能力的从业者之间的分歧时才算数，于是相当多的技能刻意不带任何来源——因为「怎么写出好文案」「怎么做一次发现访谈」并没有谁在裁决。带来源的技能必须带 ## Sources 小节，带这个小节的技能必须有来源，双向都会检查；链接按自己的排期每周抓取一次，而不是每次推送都抓——发布方短暂宕机，不该成为让一个不相干的 pull request 失败的理由。目录同样对「没有技能可服务」的来源关闭：一个 issue 里存着以 HIPAA 隐私规则为首的医疗行业候选权威，等着一个还不存在的技能。

5. 05

   四十二次由模型署名的提交，以及一次改动一个 pull request

   仓库的 87 次提交里，42 次由 Claude 署名——用的是 Anthropic 的邮箱，归属一个名为 claude 的 GitHub 账号；作者自己的 44 次分散在两个身份下，而每一次合并提交都由他署名。内容提交的分支名直接说明自己在做什么——claude/source-curation、claude/c-level-depth、claude/never-and-tools、claude/demo-videos——而其中一个长命分支名 claude/import-agents-drive-gmci3h 被八次合并复用，作者在一条 pull request 正文里解释了原因：那一次会话的分支策略只允许一条开发分支，于是两次本可分开评审的提交走同一条分支，而不是去推第二条。记录的单位是 pull request 而不是提交，它们的正文读起来像工程报告——按文件说明改了什么、验证了什么、留下什么没做，以及这项工作引出了哪一条编号决策。最清楚的例子来自外部：一位读完全部 172 个技能的贡献者按行号、对着一个指名提交报出九处缺陷，作者逐条对着树核实后给出处置——两处作为机械修复合并，其余用一个新的检查来回答：凡是 ## Never 区块内的多条规则在句末标点上不一致，就让构建失败；此前他否掉了别人建议的检查方式，因为那会在当前树上报出 59 处命中，而其中几乎全是刻意的行文风格。第二个外部 pull request 是把一位独立的安全评审员装进可安装的安全部门，自 2026-09-21 起一直开着，其作者在 2026-09-28 留言请求评审。第三个用 358 个文件把目录打包给另一种 agent 工具、还配了图形安装器，换来的是一份详细回复，逐条列出落地前必须改掉的东西。

6. 06

   既没有 release 也没有 tag：版本号住在十六份清单里

   这个仓库没有 release、没有 tag，也没有 changelog。分发方式是让插件市场指向 main，而树里仅有的版本号是按部门给的：十六个插件在 Claude Code 与 Codex 两份清单里都写着 1.0.0，市场自己也是 1.0.0。在整份记录里，唯一一次版本变动是别人提出来的——那个外部安全评审 pull request 把这个部门从 1.0.0 提到 1.1.0，并重新生成旁边的 Codex 清单。日志里还留着早期那种「到底验证了什么」的诚实：2026-08-29 把仓库公开，补上的是「文档里写的安装命令除了作者本人谁都装不上」这个缺口；同一条记录也写明，那次会话里没有任何办法对一台干净客户端跑一遍市场安装，所以清单只验证到「能解析、且引用的每条路径都存在」为止。之后的节奏是一波冲刺加一段停顿。87 次提交集中在二十一天里——8 月 36 次、9 月 51 次，最新一次在 2026-09-17——然后 main 安静了两周，那个外部 pull request 一直等着。仓库没有归档，队列在提交停下之后仍在动，所以本记录把项目定成 active 而不是 maintained。唯一还在动的那部分机器，是它自己分发的形状：工业和基础教育两个行业包，从一份配置加核心生成独立仓库，当一个行业包要求带来一个新部门时连部门一起生成；而且这套输出的验证方式，是写进一个临时目录、再跑生成出来的那个仓库自己的检查，而不是把产物提交进仓库。