Problem
现有的技能skill-installer虽然能将各种开源的skill安装到本地，但是如果技能是只限于Claude Code生态的话，CodeWhale做的二次转写不一定完美等同于原技能。
Proposed solution
标题写得很大“适配Claude Code的技能生态”，但其实我也不清楚这是否是一条合适的路径。
我能想到的办法是：
移植Claude Code的相关功能 → 安装依赖其生态的skill时进行移植转写
Use case
以技能understand-anyting为例，CodeWhale的分析如下：
● 场景：尝试在 CodeWhale 上安装并使用 Understand-Anything
▏ (https://github.com/Lum1104/Understand-Anything)（50K+星标的代码知识图谱技能），发现因平台能力差距导致完全无法运行。
▏
▏ Understand-Anything 是一个 Claude Code Plugin，不是通用的 SKILL.md
▏ 技能。我逐一拆解了它在 CodeWhale
▏ 上的不兼容点，供评估是否值得在平台层面填补这些能力。
▏
▏ ────────────────────────────────────────────────────────────
▏
▏ 1. 缺少 Custom Slash Commands 机制
▏
▏ Understand-Anything 注册了 8 个自定义斜杠命令，用户通过在聊天框中输入 /command_name
▏ 触发：
▏
▏project-scanner: 扫描项目文件，检测语言和框架
▏file-analyzer: 提取函数、类、import，生成图节点和边（并行 5 个一批）
▏architecture-analyzer: 识别架构层级
▏tour-builder: 生成引导式学习路径
▏graph-reviewer: 验证图谱完整性
▏/understand-dashboard: 启动 Web 交互面板
▏/understand-domain: 提取业务领域知识
▏/understand-knowledge: 分析 Karpathy 风格 LLM wiki
▏▏
▏ 在 Claude Code 中，这些命令通过 plugin.json 注册（见
▏ understand-anything-plugin/.claude-plugin/plugin.json）。每个命令对应 skills/
▏ 子目录下的一份独立 SKILL.md，frontmatter 中有 name 和 argument-hint 字段与 /command
▏ 绑定。
▏
▏ CodeWhale 的差距：
▏ - CodeWhale 没有任何 /custom-command 机制
▏ - 现有技能只有两种激活方式：用户提及名称 / 模型根据任务描述自动选择
▏ - 无法将 8 个命令映射到 CodeWhale 的技能体系
▏ - 即使强行把所有 SKILL.md 合并进一个文件，也丢失了用户主动通过命令触发的能力
▏
▏ ────────────────────────────────────────────────────────────
▏
▏ 2. 缺少 Plugin 系统
▏
▏ Understand-Anything 是一个完整的 pnpm monorepo，结构如下（相关信息来自项目中的
▏ CLAUDE.md）：
▏
understand-anything-plugin/
├── .claude-plugin/
│ └── plugin.json ← 插件元数据（name, version, author...）
├── packages/
│ ├── core/ ← TypeScript 核心引擎
│ │ ├── search/ ← 搜索引擎
│ │ ├── types/ ← 知识图谱类型定义
│ │ ├── schema/ ← 图谱 Schema 验证
│ │ └── persistence/ ← 持久化层
│ └── dashboard/ ← React + Vite 交互面板
├── src/ ← 技能 TypeScript 源码
├── skills/ ← 8 个 SKILL.md 命令定义
├── agents/ ← Agent 定义
│ ├── project-scanner/
│ ├── file-analyzer/
│ ├── architecture-analyzer/
│ └── ...
└── package.json ← pnpm build 构建
▏
▏ 而 Claude Code 安装这个插件的方式是：
▏ 1. /plugin marketplace add Lum1104/Understand-Anything
▏ 2. 下载、编译、缓存到 ~/.claude/plugins/cache/...
▏ 3. plugin.json 中的 name 字段将自定义命令注入到 Claude Code 的命令空间
▏
▏ CodeWhale 的差距：
▏ - 没有 plugin.json 或类似元数据注册机制
▏ - 技能目录结构是平的：一个 SKILL.md + 可选脚本
▏ - 没有构建流程支持（pnpm build）
▏ - 没有多包/workspace 意识
▏ - 无法将编译后的 TypeScript 代码暴露为可调用工具
▏ - 即使手动构建，也没有办法注册自定义命令
▏
▏ ────────────────────────────────────────────────────────────
▏
▏ 3. 多 Agent 流水线无法在 CodeWhale 技能中复现
▏
▏ /understand 命令内部编排了多个专门 Agent（摘自项目 CLAUDE.md）：
▏
▏（同前文 /command_name）
▏
▏ 这些 Agent 由 编译后的 TypeScript 代码实现，每个 Agent 有自己的 src/ 源码目录，通过
▏ pnpm build 打包。Agent 之间通过写入 .understand-anything/intermediate/ 目录
▏ 进行数据交换（而非模型上下文传递）。
▏
▏ CodeWhale 的差距：
▏ - CodeWhale 的 agent_open 可以创建子 Agent，但子 Agent 是模型会话，不是编译后的代码
▏ - 无法将 TypeScript Agent 注册为可重复调用的工具
▏ - Agent 间的数据交换依赖磁盘文件系统约定，CodeWhale 的子 Agent
▏ 没有类似的共享中间数据约定
▏
▏ ────────────────────────────────────────────────────────────
▏
▏ 4. Web Dashboard 服务器无缝启动
▏
▏ /understand-dashboard 命令会启动一个 Vite React
▏ 开发服务器（端口自定义），提供交互式知识图谱可视化。启动后通过 TokenGate
▏ 机制控制本地访问权限。
▏
▏ CodeWhale 的差距：没有技能启动 Web 服务器的标准化机制。代理可以在 shell 中执行 pnpm
▏ dev:dashboard，但无法对接起 TCP 端口管理、安全令牌和浏览器打开等流程。
▏
▏ ────────────────────────────────────────────────────────────
▏
▏ 5. 平台间 Agent 模型字段兼容性
▏
▏ 项目 CLAUDE.md 中特别提到：
▏
▏ > Agent model field 起初使用了 model: inherit，但这是 Claude Code
▏ 专有关键词——OpenCode 将其当作文字模型 ID 处理并报 ProviderModelNotFoundError（见项目
▏ #167）。
▏
▏ 这说明即使同为 AI 编码平台，plugin 层的 frontmatter 字段语义也不兼容。CodeWhale 的
▏ Agent 系统如果要支持这类技能，需要定义一套通用的 Agent frontmatter 规范。
▏
▏ ────────────────────────────────────────────────────────────
▏
▏ 总结：如果要支持这类生态技能，CodeWhale 需要什么
▏
▏- Custom Slash Commands: 必须 用户主动触发的/command 机制
▏- Plugin 注册系统: 必须 plugin.json式的元数据和构建流程
▏- 编译代码 Agent 注册: 必须 非会话式的代码级 Agent
▏- 子 Agent 数据约定: 高 Agent间通过约定路径共享中间数据
▏- Web 服务启动: 中 技能启动本地 Web Server的标准化流程
▏- Agent frontmatter通用规范: 中 跨平台兼容的模型/工具声明语法
▏
▏ 目前 CodeWhale 的技能体系与 Claude Code Plugin 体系是完全不同的扩展模型
▏ ——前者是"给模型的指令说明书"，后者是"可执行的多组件插件"。如果要让
▏ Understand-Anything 级别的生态技能移植到 CodeWhale 上，需要在平台层做上述扩展。
Alternatives considered
移植转写开源的skill，有2个隐患：
- 最前面提到的，转写质量不可控
- 当需要更新skill的时候，并不能直接去源库学习，而是要用类似git代码合并分支的形式去把源库里的更新进一步转写到本地
Impact
多耗一些token在教模型如何去高效地“移植”技能而不是学习技能
Additional context
见前文
Problem
现有的技能
skill-installer虽然能将各种开源的skill安装到本地，但是如果技能是只限于Claude Code生态的话，CodeWhale做的二次转写不一定完美等同于原技能。Proposed solution
标题写得很大“适配Claude Code的技能生态”，但其实我也不清楚这是否是一条合适的路径。
我能想到的办法是：
Use case
以技能
understand-anyting为例，CodeWhale的分析如下：● 场景：尝试在 CodeWhale 上安装并使用 Understand-Anything
▏ (https://github.com/Lum1104/Understand-Anything)（50K+星标的代码知识图谱技能），发现因平台能力差距导致完全无法运行。
▏
▏ Understand-Anything 是一个 Claude Code Plugin，不是通用的 SKILL.md
▏ 技能。我逐一拆解了它在 CodeWhale
▏ 上的不兼容点，供评估是否值得在平台层面填补这些能力。
▏
▏ ────────────────────────────────────────────────────────────
▏
▏ 1. 缺少 Custom Slash Commands 机制
▏
▏ Understand-Anything 注册了 8 个自定义斜杠命令，用户通过在聊天框中输入 /command_name
▏ 触发：
▏
▏
project-scanner: 扫描项目文件，检测语言和框架▏
file-analyzer: 提取函数、类、import，生成图节点和边（并行 5 个一批）▏
architecture-analyzer: 识别架构层级▏
tour-builder: 生成引导式学习路径▏
graph-reviewer: 验证图谱完整性▏
/understand-dashboard: 启动 Web 交互面板▏
/understand-domain: 提取业务领域知识▏
/understand-knowledge: 分析 Karpathy 风格 LLM wiki▏▏
▏ 在 Claude Code 中，这些命令通过 plugin.json 注册（见
▏ understand-anything-plugin/.claude-plugin/plugin.json）。每个命令对应 skills/
▏ 子目录下的一份独立 SKILL.md，frontmatter 中有 name 和 argument-hint 字段与 /command
▏ 绑定。
▏
▏ CodeWhale 的差距：
▏ - CodeWhale 没有任何 /custom-command 机制
▏ - 现有技能只有两种激活方式：用户提及名称 / 模型根据任务描述自动选择
▏ - 无法将 8 个命令映射到 CodeWhale 的技能体系
▏ - 即使强行把所有 SKILL.md 合并进一个文件，也丢失了用户主动通过命令触发的能力
▏
▏ ────────────────────────────────────────────────────────────
▏
▏ 2. 缺少 Plugin 系统
▏
▏ Understand-Anything 是一个完整的 pnpm monorepo，结构如下（相关信息来自项目中的
▏ CLAUDE.md）：
▏
understand-anything-plugin/
├── .claude-plugin/
│ └── plugin.json ← 插件元数据（name, version, author...）
├── packages/
│ ├── core/ ← TypeScript 核心引擎
│ │ ├── search/ ← 搜索引擎
│ │ ├── types/ ← 知识图谱类型定义
│ │ ├── schema/ ← 图谱 Schema 验证
│ │ └── persistence/ ← 持久化层
│ └── dashboard/ ← React + Vite 交互面板
├── src/ ← 技能 TypeScript 源码
├── skills/ ← 8 个 SKILL.md 命令定义
├── agents/ ← Agent 定义
│ ├── project-scanner/
│ ├── file-analyzer/
│ ├── architecture-analyzer/
│ └── ...
└── package.json ← pnpm build 构建
▏
▏ 而 Claude Code 安装这个插件的方式是：
▏ 1. /plugin marketplace add Lum1104/Understand-Anything
▏ 2. 下载、编译、缓存到 ~/.claude/plugins/cache/...
▏ 3. plugin.json 中的 name 字段将自定义命令注入到 Claude Code 的命令空间
▏
▏ CodeWhale 的差距：
▏ - 没有 plugin.json 或类似元数据注册机制
▏ - 技能目录结构是平的：一个 SKILL.md + 可选脚本
▏ - 没有构建流程支持（pnpm build）
▏ - 没有多包/workspace 意识
▏ - 无法将编译后的 TypeScript 代码暴露为可调用工具
▏ - 即使手动构建，也没有办法注册自定义命令
▏
▏ ────────────────────────────────────────────────────────────
▏
▏ 3. 多 Agent 流水线无法在 CodeWhale 技能中复现
▏
▏ /understand 命令内部编排了多个专门 Agent（摘自项目 CLAUDE.md）：
▏
▏（同前文 /command_name）
▏
▏ 这些 Agent 由 编译后的 TypeScript 代码实现，每个 Agent 有自己的 src/ 源码目录，通过
▏ pnpm build 打包。Agent 之间通过写入
.understand-anything/intermediate/目录▏ 进行数据交换（而非模型上下文传递）。
▏
▏ CodeWhale 的差距：
▏ - CodeWhale 的 agent_open 可以创建子 Agent，但子 Agent 是模型会话，不是编译后的代码
▏ - 无法将 TypeScript Agent 注册为可重复调用的工具
▏ - Agent 间的数据交换依赖磁盘文件系统约定，CodeWhale 的子 Agent
▏ 没有类似的共享中间数据约定
▏
▏ ────────────────────────────────────────────────────────────
▏
▏ 4. Web Dashboard 服务器无缝启动
▏
▏ /understand-dashboard 命令会启动一个 Vite React
▏ 开发服务器（端口自定义），提供交互式知识图谱可视化。启动后通过 TokenGate
▏ 机制控制本地访问权限。
▏
▏ CodeWhale 的差距：没有技能启动 Web 服务器的标准化机制。代理可以在 shell 中执行 pnpm
▏ dev:dashboard，但无法对接起 TCP 端口管理、安全令牌和浏览器打开等流程。
▏
▏ ────────────────────────────────────────────────────────────
▏
▏ 5. 平台间 Agent 模型字段兼容性
▏
▏ 项目 CLAUDE.md 中特别提到：
▏
▏ > Agent model field 起初使用了 model: inherit，但这是 Claude Code
▏ 专有关键词——OpenCode 将其当作文字模型 ID 处理并报 ProviderModelNotFoundError（见项目
▏ #167）。
▏
▏ 这说明即使同为 AI 编码平台，plugin 层的 frontmatter 字段语义也不兼容。CodeWhale 的
▏ Agent 系统如果要支持这类技能，需要定义一套通用的 Agent frontmatter 规范。
▏
▏ ────────────────────────────────────────────────────────────
▏
▏ 总结：如果要支持这类生态技能，CodeWhale 需要什么
▏
▏- Custom Slash Commands: 必须 用户主动触发的/command 机制
▏- Plugin 注册系统: 必须 plugin.json式的元数据和构建流程
▏- 编译代码 Agent 注册: 必须 非会话式的代码级 Agent
▏- 子 Agent 数据约定: 高 Agent间通过约定路径共享中间数据
▏- Web 服务启动: 中 技能启动本地 Web Server的标准化流程
▏- Agent frontmatter通用规范: 中 跨平台兼容的模型/工具声明语法
▏
▏ 目前 CodeWhale 的技能体系与 Claude Code Plugin 体系是完全不同的扩展模型
▏ ——前者是"给模型的指令说明书"，后者是"可执行的多组件插件"。如果要让
▏ Understand-Anything 级别的生态技能移植到 CodeWhale 上，需要在平台层做上述扩展。
Alternatives considered
移植转写开源的skill，有2个隐患：
Impact
多耗一些token在教模型如何去高效地“移植”技能而不是学习技能
Additional context
见前文