Appearance
技能
技能 适合沉淀那些“以后还会反复用到的能力说明”。
如果说工作流更像结构化步骤，那技能更像可复用的能力包。
页面入口
当前 GUI 入口：
- 左侧导航：
技能 - 路由：
/skills
当前页面能做什么
基于当前实现，技能页支持这些动作：
- 查看技能列表
- 搜索技能
- 导入技能
- 创建技能
- 打开技能详情
- 编辑技能内容
- 删除技能
技能是怎么存的
当前页面的提示已经很明确：
- 创建技能后，会自动生成
SKILL.md - 导入时支持 GitHub URL 和本地目录
- 编辑时，本质上是在维护技能正文内容
这意味着技能不是某种抽象黑盒，而是你能看见、能修改、能版本化的文本资产。
导入技能的两种方式
URL 导入
适合这些情况：
- 团队里已经有人整理好了技能仓库
- 你想直接复用一个公开技能
- 你拿到的是 GitHub 链接
本地目录导入
适合这些情况：
- 技能已经在本地磁盘上
- 你在维护自己的技能库
- 你需要直接导入某个
SKILL.md
创建技能时要填什么
当前创建弹窗主要有 3 个字段：
- 技能名称
- 技能描述
- 技能内容
建议你这样理解：
- 名称：给系统和自己看的标识
- 描述：一句话说明用途
- 内容：真正定义这个技能该怎么做
什么时候用技能，什么时候不用
适合做技能的内容：
- 一套稳定的处理规则
- 一种固定的回答/执行风格
- 一段需要长期复用的操作说明
不太适合直接做技能的内容：
- 纯粹依赖外部程序执行的能力
- 更像工具调用或渠道接入的能力
这种情况通常应该考虑 插件 或 MCP。
当前使用限制
技能页当前有一个很重要的前提：
它需要在桌面运行环境里才能真正执行本地读写。
也就是说，浏览器预览结构可以看，但真正的导入、创建、保存，还是要在 Tauri 客户端里做。
一个很实用的判断方法
如果你手里的东西更像：
- “一段长期可复用的能力说明”
优先考虑 技能。
如果更像：
- “一个需要接命令、接服务、接渠道的程序扩展”
优先看 插件开发入口。