市场里的 Skill 想改一点，怎么兼顾自己的修改和后续更新？

可以按你想改到什么程度来选。只是“增加来源链接列、标题改成中文”，先保留原版，把这些要求单独给 Agent 通常就够了；如果要长期维护自己的版本，我建议考虑下面两种方式。

1. Fork 原作者的 Git 仓库，保留自己的改动并跟踪上游

前提是能访问源码，而且许可允许。把定制改动提交在自己的仓库，升级时先对比上游新版本，选择需要的变化、解决冲突，再安装审核过的版本。

2. 把 Skill 文件保存在 Busabase，让 Agent 提交更新请求

将 SKILL.md、引用文件和需要的脚本放在同一个 Skill 节点，记下来源版本和必须保留的定制规则。给已连接该空间的 Agent“仅提交变更请求”的权限；需要升级时，让它读取当前文件和指定上游版本，检查差异、做安全扫描与测试，再提出文件更新请求，附上它改了什么、保留了什么，以及检查结果。你在审核页比较前后内容后决定是否合并。这个方式让团队围绕同一份文件和审核记录协作，也不用每个人自己维护一套 Git 分支。

可参考 Busabase Skill 安装与工作区技能说明和变更请求说明。

前面的建议里“临时要求”和“自己长期维护一份”这个区分很实用。我补充一下 Buda 的 Managed Skill 更新边界：

• 只改这一次的输出格式：保留市场里的原 Skill，在任务里补一句“加来源链接列、标题用中文”，最省事。
• 每次都要这样输出：把你自己的格式规则放在单独的 Local Skill 或 Agent 指令里，和原 Managed Skill 分开。需要全团队共用时放到 Space 范围。这样上游更新原 Skill 时，不会覆盖你独立保存的规则；但仍要在下一次任务里检查两套指令是否冲突。
• 要修改原 Skill 的核心步骤或脚本：在许可允许时 fork 来源仓库，维护自己的版本，再让 Agent 安装你的来源。以后原作者更新，需要你比较差异、选择要合入的改动；Buda 不会替你自动合并你的改动与上游改动。

Buda 的 Skills 说明把 Managed 与 Local 分开；安装和更新指南也说明 Managed Skill 跟踪来源，而界面里的清单不能直接编辑其 SKILL.md。你描述的“加一列、改标题语言”，我会先用第一种方式试几次，确实每次都需要时再沉淀成本地规则。