Motivation
希望 kelivo 增加类似 “Skills” 的功能机制，允许用户安装、管理并在需要时调用特定 Skill，而不是只能将 Skill 的 markdown 内容直接写入助手提示词中。
I’d like to suggest that kelivo add a “Skills” mechanism, allowing users to install, manage, and invoke specific skills when needed, instead of embedding skill markdown directly into the assistant prompt.
目前这种方式只适合非常简单、单一的 Skill 场景：
The current approach only works well for very simple, single-skill scenarios:
- Skill 内容与主提示词强耦合
Skill content is tightly coupled with the main prompt
- 不方便同时维护多个 Skill
It is inconvenient to maintain multiple skills at the same time
- 扩展和复用成本高
The cost of extension and reuse is high
- 难以按需启用/停用
It is hard to enable/disable skills on demand
- 后续生态能力有限
It limits future ecosystem possibilities
如果支持 Skills 机制，用户可以获得这些改善：
If a Skills mechanism is introduced, users would benefit from:
- 更方便地安装和复用不同 Skill
Easier installation and reuse of different skills
- 可以按场景动态调用 Skill，而不是把所有内容塞进系统提示词
Dynamically invoking skills based on context, instead of putting everything into the system prompt
- 降低提示词维护成本
Lower prompt maintenance cost
- 更适合多 Skill 组合和扩展
Better support for combining and extending multiple skills
- 为后续插件化、社区共享、技能市场等能力打基础
A foundation for future pluginization, community sharing, or even a skill marketplace
Proposed Solution
一个可行方向是为 kelivo 增加独立的 Skill 概念，例如：
One possible direction would be to introduce a first-class Skill concept in kelivo, for example:
- 支持 Skill 的安装 / 卸载 / 启用 / 禁用
Support installing / uninstalling / enabling / disabling skills
- Skill 以独立文件或目录存在，而不是直接拼接进主提示词
Store skills as independent files or directories instead of concatenating them into the main prompt
- 运行时可按条件或显式指令选择调用某个 Skill
Allow a skill to be invoked at runtime based on context or explicit instruction
- 支持多个 Skill 共存，并处理优先级或冲突问题
Support multiple skills coexisting, with priority or conflict resolution
- 即使只是最基础的“注册 + 按需注入上下文”，也会比当前方式灵活很多
Even a minimal version such as “registration + on-demand context injection” would already be much more flexible than the current approach
当前做法是把 skill 的 md 直接写进助手提示词里，这更像是“静态提示词拼接”，而不是真正的 Skill 机制。
The current practice of putting skill markdown directly into the assistant prompt is closer to “static prompt composition” than a real Skills mechanism.
它在单一 Skill 下尚可使用，但一旦 Skill 变多，维护和扩展都会变得困难。
It may work for a single skill, but once the number of skills grows, maintenance and extensibility become difficult.
因此，建议将 Skill 从“提示词内容”提升为“可管理、可调用的能力单元”。
Therefore, I suggest elevating a skill from “prompt content” to a “manageable and callable capability unit”.
Motivation
希望 kelivo 增加类似 “Skills” 的功能机制，允许用户安装、管理并在需要时调用特定 Skill，而不是只能将 Skill 的 markdown 内容直接写入助手提示词中。
I’d like to suggest that kelivo add a “Skills” mechanism, allowing users to install, manage, and invoke specific skills when needed, instead of embedding skill markdown directly into the assistant prompt.
目前这种方式只适合非常简单、单一的 Skill 场景：
The current approach only works well for very simple, single-skill scenarios:
Skill content is tightly coupled with the main prompt
It is inconvenient to maintain multiple skills at the same time
The cost of extension and reuse is high
It is hard to enable/disable skills on demand
It limits future ecosystem possibilities
如果支持 Skills 机制，用户可以获得这些改善：
If a Skills mechanism is introduced, users would benefit from:
Easier installation and reuse of different skills
Dynamically invoking skills based on context, instead of putting everything into the system prompt
Lower prompt maintenance cost
Better support for combining and extending multiple skills
A foundation for future pluginization, community sharing, or even a skill marketplace
Proposed Solution
一个可行方向是为 kelivo 增加独立的 Skill 概念，例如：
One possible direction would be to introduce a first-class Skill concept in kelivo, for example:
Support installing / uninstalling / enabling / disabling skills
Store skills as independent files or directories instead of concatenating them into the main prompt
Allow a skill to be invoked at runtime based on context or explicit instruction
Support multiple skills coexisting, with priority or conflict resolution
Even a minimal version such as “registration + on-demand context injection” would already be much more flexible than the current approach
当前做法是把 skill 的 md 直接写进助手提示词里，这更像是“静态提示词拼接”，而不是真正的 Skill 机制。
The current practice of putting skill markdown directly into the assistant prompt is closer to “static prompt composition” than a real Skills mechanism.
它在单一 Skill 下尚可使用，但一旦 Skill 变多，维护和扩展都会变得困难。
It may work for a single skill, but once the number of skills grows, maintenance and extensibility become difficult.
因此，建议将 Skill 从“提示词内容”提升为“可管理、可调用的能力单元”。
Therefore, I suggest elevating a skill from “prompt content” to a “manageable and callable capability unit”.