[Feature Request] 支持从开源仓库安装 Skill 并追踪上游版本更新

[stoner-byte]

背景

目前 Memory Hub 的 Skill 导入主要面向本地文件/目录或会话提取。对于 GitHub 等平台上已经存在的开源 Skill，用户仍需要手动完成：

1. clone 或下载开源仓库；
2. 找到 Skill 所在目录；
3. 手工打包或上传；
4. 上游 Skill 更新后，再次人工检查并重新导入。

我们实际导入开源 Skill ask-five-pro 时走的就是这条流程。导入成功后，Memory Hub 中的 Skill 已经与原始仓库脱离，无法看到它来自哪个仓库、哪个目录、哪个 tag/commit，也无法判断上游是否发布了新版本。

这使 Skill 更像一次性的文件拷贝，而不是可维护、可升级的团队资产。

期望能力

建议增加“从 Git 仓库安装 Skill”的入口，首期可以只支持公开 GitHub 仓库或公开 Git URL。

1. 从仓库直接安装

用户输入：

• 仓库 URL；
• 可选的 branch / tag / commit；
• 可选的 Skill 子目录（兼容一个仓库包含多个 Skill 的情况）。

系统解析并预览 Skill 后，由用户确认安装，不需要先在本地 clone、打包再上传。

2. 保存来源与版本信息

安装后为 Skill 保存并展示至少以下 provenance 信息：

• repository URL；
• Skill 在仓库中的相对路径；
• 用户选择的 branch / tag / commit；
• 实际解析到的 commit SHA；
• Skill manifest 中声明的版本（如果存在）；
• 最近检查更新时间。

这样可以明确回答“这个 Skill 从哪里来、当前安装的是哪一版”。

3. 检查并更新上游版本

在 Skill 详情页提供：

• 手动“检查更新”；
• 显示当前版本与上游最新版本/commit；
• 有更新时展示文件差异或变更摘要；
• 用户确认后更新，而不是默认静默自动更新；
• 每次更新继续生成现有的 Skill version，保留历史版本和回滚能力。

后续可再增加定时检查更新，但首期手动检查即可解决核心问题。

4. 本地修改的处理

如果导入后的 Skill 已在 Memory Hub 中被人工编辑，应在更新前明确提示冲突，并允许用户选择：

• 查看差异后覆盖更新；
• 保留本地版本并断开上游跟踪（fork/detach）；
• 取消更新。

不建议不经确认直接覆盖团队正在使用的 Skill。

建议的最小实现范围

首期 MVP 可以只实现：

1. 支持公开 GitHub 仓库；
2. 支持指定仓库、ref 和子目录；
3. 保存 repo URL、path、resolved commit；
4. 提供手动检查更新；
5. 确认后以新 Skill version 更新。

暂不要求：

• 完整 Skill Marketplace；
• 私有仓库凭据管理；
• 自动定时更新；
• 跨 Git 托管平台的统一适配。

安全建议

从外部仓库安装时建议：

• 展示最终解析出的 commit SHA，保证安装结果可复现；
• 限制下载体积、文件数量和允许的文件类型；
• 导入阶段只读取 Skill 文件，不执行仓库中的安装脚本或 hook；
• 更新前展示来源和变更并要求人工确认。

预期价值

• 降低复用社区开源 Skill 的安装门槛；
• 避免每次更新都人工下载、打包、重新导入；
• 保留来源、版本和更新历史，便于团队审计与回滚；
• 让 Memory Hub 的 Skill 从“上传后的静态副本”升级为“可追踪、可维护的团队资产”。