5.3 真实案例研究——React、Anthropic、llm-wiki
📋 多工具适用说明
本节案例以 Claude Code 项目为例（因其 Skills 系统最完整、公开案例最多）。
案例中的设计决策和模式适用于所有工具：
- 项目指令文件的行数标准——通用
- 渐进式披露的实践——通用
- 安全边界和权限控制——概念通用，实现各异
如果你使用其他工具，可以参考这些案例的设计思路，而非具体语法。
引言
纸上得来终觉浅。这一节我们深入三个真实项目的技能包设计，看看高手是怎么做的。
案例一：Facebook/React——最成熟的开源技能包集合
概览
React 项目的 .claude/ 目录是大型开源项目中最成熟的技能包集合。
.claude/
├── instructions.md（47 行） # CLAUDE.md 等价物
├── settings.json # 精细的 allow/deny 权限
└── skills/（7 个）
├── extract-errors/
├── feature-flags/ # 知识库模式
├── fix/ # 工作流模式
├── flags/
├── flow/ # 类型检查
├── test/ # 动态注入模式
└── verify/ # 检查清单模式三个设计亮点
1. instructions.md 只有 47 行
只包含"始终需要"的核心信息：项目结构、必须用 yarn、指向 /verify。不塞 API 规范、不放部署步骤。
2. Skill 间互相引用
/verify 明确调用 /flow 和 /test：
1. 运行 yarn prettier（失败停止）
2. 运行 yarn linc（失败停止）
然后并行：
3. 使用 /flow 类型检查
4. 使用 /test 测试源码3. 精细的 allow/deny 权限
{
"allow": ["Skill(test)", "Bash(yarn test:*)", "Bash(yarn flow:*)"],
"deny": ["Bash(npm:*)", "Bash(pnpm:*)", "Bash(bun:*)"]
}允许什么和拒绝什么同样重要——明确拒绝其他包管理器，因为团队只用 yarn。
关键教训
- 常驻内容极简：47 行 instructions vs 几百行的 CLAUDE.md
- 短就是好：每个 Skill 20-50 行
- Skill 可以调用 Skill：在指令中写"使用 /flow 类型检查"
案例二：Anthropic 自家仓库——极简主义典范
概览
Anthropic 的 .claude/commands/（旧版格式）只有 3 个命令，却是极简主义的典范。
commit-push-pr：13 行的杰作
---
allowed-tools: Bash(git checkout --branch:*), Bash(git add:*), ...
---
## Context
- Current git status: !`git status`
- Current git diff: !`git diff HEAD`
- Current branch: !`git branch --show-current`
## Your task
Based on the above changes:
1. Create a new branch if on main
2. Create a single commit...为什么只有 13 行却如此强大？ 因为动态上下文注入把所有需要的信息都拉进来了——不需要写"请查看 git diff"，diff 已经在眼前。
triage-issue：护栏模式的典范
IMPORTANT: Don't post any comments or messages to the issue.
ONLY use labels from ./scripts/gh.sh label list -- never create or guess label names工具限制 + 硬性禁止 + 脚本白名单——三重护栏确保 Claude 不会越权。
关键教训
- 极简是力量：13 行比很多 100 行的 Skill 更有效
- 动态注入减少长度：不需要写"查看 diff"，直接注入
- 多重护栏：allowed-tools + 硬性禁止 + 脚本白名单
案例三：llm-wiki——最全面的技能包系统
概览
llm-wiki 项目有 13 个技能包，组成完整的知识管理系统。
维护者套件：/maintainer, /review-pr, /triage-issue, /release
Wiki 管线：/wiki-init, /wiki-ingest, /wiki-build, /wiki-lint, /wiki-query, /wiki-reflect, /wiki-graph, /wiki-candidates
便利包装：/wiki-all三个设计亮点
1. 元 Skill 模式
/maintainer 是"入口 Skill"——它检查项目状态，推荐下一步操作：
- 卡住的 PR → 建议
/review-pr - 未分类 Issue → 建议
/triage-issue - 未发布变更 → 建议
/release
2. 一致的日志约定
每个 Skill 都向 wiki/log.md 追加日志，创建跨 Skill 的审计追踪。
3. Skill 间显式引用
/wiki-candidates 说"promote/merge 后运行 /wiki-lint"。/wiki-all 说"用这个代替手动链接 /wiki-build + /wiki-graph + /wiki-lint"。
关键教训
- 元 Skill 管理复杂性：当 Skill 超过 5 个时，创建"入口"Skill
- 一致约定 > 灵活性：每个 Skill 都写日志
- "全部执行"Skill：
/wiki-all是便利包装
三项目对比
| 维度 | React | Anthropic | llm-wiki |
|---|---|---|---|
| Skill 数 | 7 | 3 | 13 |
| 平均长度 | 20-50 行 | 13-75 行 | 30-80 行 |
| 核心模式 | 分层 + 互调 | 极简 + 注入 | 元 Skill + 管线 |
| 权限控制 | 精细 allow/deny | allowed-tools | 较少 |
| 适合规模 | 大型开源 | 小团队 | 知识管理 |
通用原则
- CLAUDE.md 保持极简——47 行（React）比 500 行好得多
- Skill 短小聚焦——20-50 行是甜蜜区
- Skill 可以调用 Skill——在指令中提到其他 Skill 的名称
- 动态注入 > 静态指令——用
!command`` 拉取实时数据 - 工具限制是安全手段——allowed-tools 让越权不可能
- 元 Skill 管理复杂性——超过 5 个 Skill 时创建入口
- 一致约定 > 灵活性——日志格式、错误处理保持统一
本节小结
📌 本节核心要点
- React：47 行常驻 + 7 个短 Skill + 精细权限——最成熟的参考
- Anthropic：13 行的 commit-push-pr 证明极简的力量
- llm-wiki：元 Skill + 一致日志约定——管理复杂 Skill 集合的范本
- 通用原则：极简常驻、短小 Skill、互调、动态注入、多重护栏
思考题
- React 的
instructions.md只有 47 行，你的 CLAUDE.md 有多长？你能把它缩减到 50 行吗？怎么做？ - Anthropic 的 13 行 commit-push-pr 为什么比很多 100 行的 Skill 更有效？核心差异是什么？
- 如果你的项目有 10 个 Skill，你会怎么组织？需要元 Skill 吗？
下一节预告
理论、实战、模式、案例都学完了。最后一个阶段——练习与巩固。概念题、设计题、综合实战，确保你真正掌握了。