一个人把 Claude Code 用到了 182 个 Skill，我看完去数了数自己的

我看到这个仓库的第一反应是先打开自己的 .claude/skills/ 文件夹看了一下。71 个。然后再看他的，182 个 skill、48 个 agent、68 个 command。

数字上的差距是次要的，重点是把整套 Claude Code 用法工程化的能力。

这个项目是谁做的

仓库叫 everything-claude-code，作者 Alvaro Cintas，X 上叫 @dr_cintas。Anthropic x Forum Ventures 黑客松冠军，2025 年 9 月用 Claude Code 全程开发了 zenith.chat 拿了第一名。

他从那以后没停下来，把日常工作里沉淀的 agent、skill、command、hook、规则全部往这个仓库塞，10 个多月之后变成了现在这套配置。

最早开源的时候是 27 agents / 64 skills / 33 commands，今天我打开看是 48 / 182 / 68。这个仓库还在长。

跨工具兼容是它另一个特点。这套配置不只 for Claude Code，在 Cursor、Codex、OpenCode、Gemini 上都能跑。

六个文件夹各自干什么

打开仓库根目录，有六个核心目录。

agents/ 放 48 个 subagent，从 planner、architect 到按语言分的 code reviewer，TypeScript、Python、Go、Java、Kotlin、Rust 全有。

skills/ 是大头，182 个工作流定义，TDD、token 优化、memory persistence、各种框架特定的 skill 都在里面。

commands/ 是 68 个 slash command，像 /plan、/tdd、/security-scan、/refactor-clean 这些。

剩下三个目录我之前没太重视。hooks/ 放生命周期触发的自动化脚本，SessionStart、PostToolUse、Stop 这些事件跑的东西。rules/ 是 always-follow 级别的规范，分了 common 子目录和 12 个语言子目录。mcp-configs/ 放 MCP 服务器定义。

我自己 hooks 配了几个常用的（format、verify-build、完成通知），之前还专门写过一篇文章聊怎么用，但跟他这种系统化的玩法比还差一截。

skills 目录截图

AgentShield

这个项目里最让我意外的还有一个叫 AgentShield 的东西。

它做的事情是审计 .claude 配置文件本身的安全风险。1,282 个测试，102 条静态分析规则，扫五类风险：密钥检测（14 种 pattern）、权限审计、Hook 注入分析、MCP 服务器风险画像、Agent 配置审查。

运行方式是 npm run agentshield scan，可以选 Opus 4.6 的三 agent 流水线（attacker / defender / auditor）跑深度扫描。

为什么需要这个？因为 hook 注入、权限滥配、密钥泄露这些已经成了 Claude Code 用户的真实风险。我自己之前 hook 写得挺随意，没意识到一个 SessionStart hook 如果被污染，能干的事远超我以为的范围。

AgentShield 的存在释放了一个信号，AI 配置文件已经复杂到需要专门工具审计了。

跨 harness

未来 Skill 和 Agent 的格式会标准化。

Anthropic 已经在推 Agent Skills 的开放规范，OpenAI Codex 的官方文档里也有 Skills 章节，OpenCode 直接抄了。一个 skill 写一遍，五个工具都能用，对维护成本是大幅降低。

我自己写 skill 的时候没考虑这件事，每个 skill 都是 Claude Code 专属。看完他的之后我意识到，如果未来想让 skill 更长寿，应该按通用规范写，不要绑死某个工具。

agents 目录截图

四个哲学

他 README 里列了四个设计哲学：Research-first、Token 优化、持续学习、跨 harness 兼容。前两个我一直在做，跨 harness 上面说了。最有意思的是持续学习。

他的做法是把日常踩的坑沉淀成 instinct，然后从 instinct 提取成 skill。这跟我现在的工作流有点像，但他比我更系统。我每次踩坑都会想到补一个 skill，但通常写完就忘了，下次还是凭记忆。他把这个过程做成了一个机制，instinct 文件持续累积，定期回顾、抽象、固化。

最后

71 个 skill 听起来不少，但我老实说，常用的就 几 个。

182 个 skill 不可能每个都常用。Alvaro 这套更像一个参考实现，你拉下来不是为了 182 个全跑，是为了挑出对你工作流有用的几个，再看他怎么写、怎么组织的。

还有 AgentShield 这种思路。我的 hooks 都是工具型的（格式化、验证构建、完成通知），没把任何不可跨越的红线沉淀成 hook。AgentShield 这种审自己配置的思路可以参考，hook 越写越多，确实需要这种东西。

skill 的边际成本不高，但维护成本会随数量线性增长。如果未来真的有 skill registry 之类的生态，这种全栈式个人仓库可能就是个过渡形态。