125个Claude Code Skills聚合仓库：一站式安装与治理

Claude Code 的 Skills 生态正在快速膨胀，但一个现实问题也随之而来：当你手头积累了十几个独立仓库、几十个插件时，光是记住哪个 skill 在哪、怎么装，就已经消耗掉大量注意力。开发者 Basit Ali Sandhu 的做法是把分散在 11 个仓库里的 125 个 skills 收敛到一个仓库中，让安装和管理回归简单。

为什么要合并到一个仓库

据原作者在文章中描述，他日常工作里反复让 Claude Code 处理的其实就是那么几类任务：审计 AWS 账户、检查 Conditional Access 配置、对 agent 做威胁建模、为审计师整理证据包、清理代码仓库。每类任务逐渐沉淀成 skill，skill 又各自长成了独立仓库，最终分散到 11 个地方。

这种分散带来的直接代价是安装体验的碎片化：用户需要执行 11 次 /plugin marketplace add 和 16 次 /plugin install，才能把全部能力装齐。社区里不断有人要求提供"一个 clone 就够"的方案，claude-skills 仓库正是对这个需求的回应。它把 11 个源仓库的内容同步过来，包含 16 个插件、125 个 skills，并配套了一个目录站点，每个 skill 一页说明，安装前可以先读懂它做什么。

需要说明的是，源仓库仍然是 skill 被编写、测试和修复的地方，聚合仓库的角色是分发入口，而非开发主场。

Claude Code 的 Skill 与插件市场机制

Claude Code 是 Anthropic 推出的命令行编程助手，它通过 "Skill" 这一机制把可复用的操作流程、检查清单和脚本封装成模型可按需调用的能力单元。每个 Skill 通常以一个 SKILL.md 为核心，附带若干辅助脚本，模型通过读取其中的名称、触发条件和描述来判断何时使用。为了分发和版本管理这些 Skill，Claude Code 引入了 "插件市场"（plugin marketplace）的概念：一个仓库或仓库的某个路径可以作为市场源，用户通过 /plugin marketplace add <repo> 注册市场，再用 /plugin install <plugin>@<marketplace> 安装其中的具体插件。一个市场可以包含多个插件，一个插件可以打包多个 Skill。正是这种 "市场—插件—Skill" 的三层结构，导致能力分散在多个独立仓库时，用户必须逐个注册市场和安装插件，安装成本随仓库数量线性增长，这也是本文聚合方案要解决的核心痛点。

仓库里装了什么

这个仓库按安全与治理场景做了清晰的插件划分，对做企业级 AI 落地的团队尤其有参考价值：

Agent 安全（9 个 skills）：面向构建 LLM agent 的团队，包含 agent-threat-model、prompt-injection-review、mcp-server-review、agent-session-log-review，覆盖提示注入审查和 MCP server 安全评估。

Agent 身份治理（8 个 skills）：针对 agent 运行时依赖的非人类身份做清点、再认证、凭证过期管理，并提供快速停用某个身份的 runbook。

AWS 安全（10 个 skills）：aws-account-audit 基于只读清单离线评估账户，scp-guardrails 构建并检查 SCP，aws-agent-session-audit 从 CloudTrail 还原 agent 在账户里做了什么。

Microsoft 365 治理（10 个 skills）：graph-permission-preflight、conditional-access-gap-analysis、copilot-oversharing-readiness，均基于只读 Graph 导出数据工作。

合规证据（7 个 skills）：evidence-pack-builder、security-questionnaire-drafter、essential-eight-evidence-map，服务于 ISO 27001、SOC 2 和 Essential Eight 相关工作。

日常开发是体量最大的一块，42 个 skills 分在 code-quality、data、debugging、devops、docs、security-basics 六个插件下，例如 dead-code-finder、flaky-test-hunter、terraform-apply-gate、diff-security-review。

此外还有仓库工程（12 个）、工作方式（12 个）、Claude Code 自身配置（8 个）、GitHub 管理（4 个）和 Mac 维护（3 个）等插件。

非人类身份（NHI）与 agent 身份治理

传统身份治理主要围绕人类用户账号展开，而 agent 系统在运行时往往以服务账号、应用注册、API key、托管标识或工作负载身份等形式访问资源，这类身份统称为 "非人类身份"（Non-Human Identity，NHI）。NHI 的风险特征与人类账号不同：数量庞大且增长快、常缺少多因素认证、凭证容易长期不过期、生命周期难以人工追踪，一旦泄露往往不会触发异常登录告警。因此 NHI 治理的关键动作包括全面清点、周期性再认证、凭证轮换与过期管理，以及为可疑身份准备快速停用的 runbook。文中 "Agent 身份治理" 插件包正是针对这一场景，帮助团队回答"我们有哪些非人类身份、它们还能访问什么、如何一键止损"这几个问题。

安装方式与更新机制

安装有两条路径。在 Claude Code 内直接添加插件市场并安装指定插件：

/plugin marketplace add basitalisandhu/claude-skills
/plugin install aws-security@claude-skills

或者克隆后运行安装脚本：

git clone https://github.com/basitalisandhu/claude-skills
cd claude-skills
python3 install.py --user

--user 会把所有 skill 复制到 ~/.claude/skills，--project 使用当前项目的 .claude/skills，--only <plugin> 收窄复制范围，--list 打印目录。安装器是纯标准库 Python，没有外部依赖。其他支持 Agent Skills 格式的 agent 也可以用 npx skills add basitalisandhu/claude-skills 安装。

同步机制上，一个每日运行的 workflow 会拉取每个源仓库，一旦有变动就开一个 PR，所有更新都以可读的 diff 形式抵达。SOURCES.json 记录了每个 skill 来自哪个仓库、哪个 commit，方便溯源和定位 bug。skill 描述在每次同步时都会被校验：使用双引号以兼容严格的 YAML 解析器、长度不超过 600 字符、必须包含 "Use when" 和 "Not for" 句子以及 Limits 段落。测试代码留在源仓库，问题也应在源仓库提 issue，修复会通过下一次同步进入聚合仓库。

Agent Skills 开放格式与跨工具兼容

SKILL.md 并非 Claude Code 独有，它正逐步成为一种跨 agent 的开放约定（常被称为 Agent Skills 格式）。其思路是：用一份带 YAML front matter 的 Markdown 文件描述能力的元信息（名称、描述、触发条件、限制），正文则用自然语言写清操作步骤，辅助脚本放在同目录下。任何支持该格式的 agent 都能读取并调用这些 Skill，从而避免为每个工具重写一遍能力包。本文中提到的 npx skills add basitalisandhu/claude-skills 即是通过社区 CLI 安装这类通用格式 Skill 的方式。正因为是开放格式，对 SKILL.md 的字段约束（双引号以兼容严格 YAML 解析器、描述长度上限、必须包含 Use when / Not for 与 Limits）才有现实意义——它既要让人看懂，也要让不同实现稳定解析，并让模型准确判断调用时机与边界。

它明确不做什么

作者在边界说明上写得相当克制：这些 skills 运行在离线状态，基于保存的导出数据或你的工作树；内置脚本是标准库 Python，不发网络请求，也不上报遥测。如果某个 skill 需要实时数据，它会告诉你该执行哪些只读命令，然后基于保存的输出工作。

每个 SKILL.md 都会声明该 skill 不做什么。作者特别提醒：secrets-hygiene 或 iam-least-privilege-review 报告干净只是一个信号，不等于拿到了安全放行。项目采用 MIT 许可证，遇到错误答案或过度声明，可以直接在源仓库提 issue 或 PR，部分插件还挂着适合 Hacktoberfest 的新手任务。

离线优先、只读取证与上下文预算

这套 Skill 的设计哲学可以概括为 "离线优先 + 只读模式"：不主动联网、不发遥测，而是要求用户先运行仓库中指定的只读命令（如列出账户资源、导出配置），再把输出交给 Skill 分析。这样做的好处是可审计、可复现、不会因自动化动作误伤生产环境，也符合合规取证对证据链可追溯的要求。与之配套的概念是 "上下文预算"（context budget）：模型一次能处理的 token 数量有限，把 125 个 Skill 的描述全部载入会挤占推理空间并稀释相关性，因此实际使用中应只安装当前任务需要的插件，并借助仓库自带的审计工具评估每个 Skill 占用的上下文，从而在能力覆盖与调用效率之间取得平衡。

值得关注的几点

对重度使用 Claude Code 的团队来说，这个仓库的价值不只在于省下几十条安装命令。它示范了一种把 AI 能力沉淀为可治理资产的思路：插件化分类、描述格式约束、来源可追溯、更新走 diff 审查、能力边界写进 SKILL.md。这套做法与当前企业关注的 agent 安全、非人类身份治理、合规取证高度吻合。当然，把 125 个 skills 装进环境也意味着需要认真评估权限与上下文预算——仓库里恰好也提供了审计 context budget 和构建最小权限的工具。