插件目录结构
.claude-plugin目录
只有1个plugin.json文件
{
"name": "claude-burrow",
"displayName": "ClaudeBurrow",
"version": "0.1.0",
"description": "Cross-device session sync for Claude Code — encrypt and sync your conversations via Cloudflare R2",
"author": {
"name": "ClaudeBurrow",
"url": "https://github.com/foguangsword/claude-burrow"
},
"keywords": ["sync", "backup", "cross-device", "cloudflare-r2", "encryption"],
"categories": ["productivity", "backup"],
"homepage": "https://github.com/foguangsword/claude-burrow",
"license": "MIT"
}
--plugin-dir 和 marketplace 安装的区别
机制完全一样，区别只在加载路径——--plugin-dir 直接指向本地目录，marketplace 安装后插件被放到 CC 的插件目录里，之后每次启动自动扫描。plugin.json 是插件的身份证，CC 靠它识别插件名、版本、命名空间（命令前缀 claude-burrow: 就来自这里）。
commands目录
里边是跟插件命令一一对应的几个markdown文档，也可以理解里边是提示词。是告诉LLM输入了对应命令以后应该干什么，比如跟用户如何对话交互、告诉CC执行什么shell、node脚本，或者展示什么。
这些markdown文档可以称作AI时代的业务逻辑代码。
传统软件是代码直接写死控制流，这里是用自然语言描述意图和流程，LLM 负责"解释执行"。好处是灵活、容错（用户输错了 LLM 能理解意图），代价是不确定性——同样的 markdown，不同模型或不同上下文可能走出不同的执行路径。这也是为什么复杂的确定性逻辑（加密、网络请求）还是要放到 js 脚本里，markdown 只描述"做什么"，不描述"怎么做"。
scripts目录
里边是js脚本程序，是工具，commands里边让LLM调用的node脚本就在这里，需要先npm install
CC插件的工作机制原理
本质上是 skill/command 注册机制。CC 启动时扫描 commands/ 目录，把每个 .md 文件注册成一个 slash command，文件名就是命令名。
加载方式是按需注入而非全量塞进 system prompt —— CC 维护了一个命令目录（类似函数签名列表），只把命令名和 description 放进 system prompt，当用户实际触发 /claude-burrow:push 的时候，才把对应 markdown 的完整内容注入到当前上下文。
插件有"always-on token 成本"和"on-invoke token 成本"两部分——前者是命令列表，后者是触发时的 markdown 全文。
触发命令后，LLM 读到 markdown 里的指令，比如"运行 node scripts/push.js"，然后通过 CC 的 Bash tool 调用它。本质上是LLM 阅读 markdown 里的业务逻辑描述，决定调用什么工具，走的是 Tool Calling 路径。
用户输入 /claude-burrow:push
↓
CC 把 push.md 全文注入上下文
↓
LLM 阅读 push.md（理解业务流程）
↓
LLM 决定调用 Bash tool：node scripts/push.js
↓
CC 执行脚本，返回结果给 LLM
↓
LLM 根据结果和 push.md 里的指引，决定下一步（比如提示用户输入密码）
