Multica Skills 不是模型插件，更像一包写给 AI agent 看的工作说明。一个 skill 通常包含 SKILL.md 和支持文件，可以挂到 workspace 或 agent 上，再被注入到 Claude Code、Codex、OpenCode 等不同工具的上下文里。它适合沉淀团队经验，但第三方 skill 不能当成无风险资源。

Multica Skills 是什么：团队知识包能不能真的复用

Multica 的 agent 创建完以后，最容易被忽略的是 skills 不是插件按钮。

它更像一包写给 AI agent 看的工作说明。

你可以把团队里反复用到的东西放进去：项目怎么启动，写测试时注意什么，某类 issue 怎么排查，发布前要检查哪些文件。

这些内容不一定是代码。更多时候是经验。

Skill 里面有什么

按 Anthropic Agent Skills 的思路，一个 skill 通常会有一个 SKILL.md。

这个文件告诉 agent：什么时候用这个 skill，怎么做，注意哪些边界。

旁边还可以带支持文件。比如模板、脚本、参考材料、固定 prompt。agent 需要时可以读这些文件。

Multica 把这套东西接进自己的 workspace 和 agent 系统里。你可以做 workspace skill，也可以做本地 skill。

workspace skill 更像团队共享知识。挂上之后，相关 agent 下次执行任务时就能看到。

local skill 更偏个人环境。比如你本机有某个内部脚本，只有这台机器能用，那就不适合放成所有人共享的 skill。

它和 CLAUDE.md、AGENTS.md 的关系

Multica 会根据 provider 写入不同的上下文文件。

Claude Code 读 CLAUDE.md。Codex、OpenCode、Cursor Agent 等很多工具读 AGENTS.md。Gemini 有自己的 GEMINI.md。

Multica 的 runtime config 会把“你现在在 Multica 任务环境里”这类说明注入进去。agent 看到这些内容后，才知道自己该用 Multica CLI 读 issue、checkout repo、回评论。

Skill 也是类似思路。

它不是给模型安装一个神秘能力，而是把一套可复用说明放进 agent 能读到的位置。

这点很重要。

如果一个团队的知识本来就写得很乱，skill 不会自动变聪明。它只是让这份知识更容易被 agent 读到。

Skill 和 MCP 不是一回事

很多人会把 skill 和 MCP 混在一起。

MCP 更像工具通道。它能让 agent 调外部服务，读数据库，访问 API，或者连某个内部系统。

Skill 更像知识包。它告诉 agent 应该怎么想、怎么做、用哪些文件。

Multica 文档里也提到，不同 provider 对 MCP 的支持并不一样。Claude Code 消费 MCP 比较完整，别的工具可能只是通过上下文文件拿到 skill 说明。

所以别把“挂了 skill”理解成“所有 provider 都获得同样能力”。

有些 provider 能读说明。能不能调用工具，要看它本身支持什么。

团队知识能不能靠 skill 复用

能，但要看你写得多实。

一个好 skill 不应该写成口号。

比如“请保持代码质量”“请认真测试”，这种话 agent 看了也没什么用。更有用的是具体流程：哪个命令能跑，哪个目录不能碰，失败日志在哪里，遇到某个错误先查哪份配置。

Skill 适合沉淀那些反复出现的操作。

比如每次发版都要走同一套检查。每次处理某类 provider 问题都要看同几个文件。每次写文档都要遵守同一套 SEO frontmatter。

这些东西写进 skill，agent 才能少问一点，少猜一点。

第三方 skill 要小心

Multica 支持从外部导入 skill，这对生态是好事。

可第三方 skill 不是普通文章。

它会影响 agent 的行为。支持文件里也可能带脚本、模板、命令说明。Multica 文档里对安全边界说得比较直白：它不替你做签名验证，也不替你审查第三方内容。

所以导入之前要看。

尤其是会引导 agent 执行命令、访问文件、调用外部服务的 skill。别因为它在某个列表里出现，就默认可信。

我更建议团队先写自己的 skill。

把已经验证过的流程沉淀下来。等你知道 skill 应该长什么样，再去看外部的。这样不容易被花哨包装带跑。