Claude Code Skills的核心形态是文件夹而非Markdown，这一设计如何改变你的开发思路？

核心观点：从"写文档"到"搭系统"

Anthropic官方实践揭示了一个反直觉的事实：Skills不是增强版的Prompt，而是精简版的Agent框架。

文件夹形态带来的范式转移，彻底重构了我对AI扩展能力的理解：

一、认知重构：三个维度的思维升级

1. 从线性文本 → 立体工程

关键洞察：当Claude能ls、cat、source你的Skill目录时，你其实是在为它设计可执行的工作空间。

2. 从静态配置 → 动态生态

文件夹形态天然支持：

• 脚本钩子：pre-execution.sh 做环境校验
• 资产沉淀：templates/、schemas/、fixtures/
• 版本演化：Git追踪整个Skill的变更历史

这不再是"给AI的说明书"，而是"AI的专用工具箱"。

3. 从个人技巧 → 团队协作

Anthropic内部数百个Skills的实践表明：文件夹结构即接口规范。

billing-lib-skill/
├── README.md          # 人类可读：设计意图
├── CLAUDE.md          # AI可读：调用协议
├── hooks/
│   ├── validate.py    # 前置检查
│   └── cleanup.sh     # 后置清理
├── snippets/          # 可复用代码块
├── test-cases/        # 验证示例
└── config.yaml        # 注册动态钩子

二、实战影响：我的开发流程发生了哪些变化？

❌ 旧思路：Prompt Engineering

"请用我们内部的billing-lib，注意：
1. 初始化时要设置region参数
2. 调用charge()前必须验证quota
3. 错误码1003需要重试..."

✅ 新思路：Context Engineering

# Claude自动执行
$ ls skills/billing-lib/
→ 发现 test-cases/edge-cases.json
→ 读取 config.yaml 的hook注册
→ 执行 hooks/validate.py 检查环境
→ 引用 snippets/charge-with-retry.py

效率差异：前者每次对话重复说明，后者一次配置、持续生效。

三、设计原则：Anthropic方法的精髓提炼

基于官方9类Skills分类，我总结出文件夹设计的黄金法则：

四、开放讨论

这一设计让我重新思考几个问题：

1. 边界问题：文件夹形态是否会催生"Skill膨胀"？何时该拆分为多个Skills？

2. 安全考量：Claude对Skill目录有完整文件操作权限，如何设计权限隔离？

3. 生态演进：如果Skills可以互相依赖（import other-skill/），是否会形成微服务式的AI能力网络？

我的结论：文件夹形态的本质是把AI从"对话者"重新定位为"操作者"--它不再只是读你写的东西，而是进入你设计的环境，使用你提供的工具，执行你定义的工作流。

这对你的开发思路产生了哪些冲击？欢迎分享你的实践或困惑。