feat: 优化skill管理器，可直接参考开源项目popskill

[maojiebc]

使用场景 / Use case

目前的skill管理器功能较为单一

当前问题 / Current limitation

可直接复刻我的开源项目：https://github.com/maojiebc/majia-Popskill

期望方案 / Proposed solution

No response

已考虑的替代方案 / Alternatives considered

No response

[dash-s-cindy]

判断：这个方向有明确用户价值，建议推进“跨引擎 Skill 管理与状态可视化”的产品设计；当前不宜把 Popskill 作为实现规格直接复刻。Cindy 已经具备 Skill 的多条底层链路，待补的是把分散的发现、安装、引擎挂载、运行时状态和修复动作统一成用户可理解的管理面，并明确哪些操作属于普通文件管理、哪些需要批准或安全审查。

现有能力与代码事实

在 origin/main@764d0b94279dc81acf3ad5fdfc2ca57ea86b22cd：

• packages/maker-core/src/agents/pi/customization-scanner.ts 已按 Pi 实际规则扫描用户级 ~/.agents/skills、项目 .pi/skills，以及从当前目录向最近 Git 根目录回溯的 .agents/skills；项目来源标记为 runtimeStatus: 'discovered'，说明文件系统“发现”与 Pi 运行时“已加载”被有意区分。
• packages/maker-core/src/agents/pi/index.ts 使用每会话隔离的 PI_CODING_AGENT_DIR，其中承载本次会话的 models.json、Cindy bridge 和受控扩展。该隔离不是缺陷，应继续保留，不能为了方便管理而直接复用整个用户 ~/.pi/agent，否则会混入 Pi 的 settings、trust、packages、extensions 或凭证相关配置。
• apps/desktop/src/main/maker-host/shared-global-skills.ts 已有受管的跨目录链接逻辑：以 ~/.agents/skills 为共享入口，在 .agents、.claude、.codex 之间创建链接；真实目录和非托管路径不覆盖，冲突会报告，断链清理由受管路径范围约束。当前类型和实现主要覆盖 shared、claude、codex，Pi 原生 config-home 不是简单加一个枚举值就能接入。
• Desktop 已有 SkillHub、插件/市场安装链路和 Slash Command Palette；因此需求不是从零做“安装器”，而是补齐跨来源、跨引擎的统一视图、状态解释和可恢复操作。

Popskill 可复用的产品启发

外部项目 majia-Popskill 的核心不是某个特定 UI，而是把本地 Skill 管理抽象成一张能力台账：

• 统一展示来源、安装状态和 Claude/Codex 挂载状态；
• 识别断链、来源孤儿和本地副本，并给出修复方案；
• 用目录内容哈希识别更新，而不是依赖版本号；
• 以源式套装聚合同一上游的多个 Skill；
• 安装/更新前预览动作，更新旧版本进入可恢复的回收站；
• 通过文件系统变化实时刷新视图。

这些能力对 Cindy 有参考价值，但不能原样照搬：Popskill 是 macOS-only 的本地应用，依赖“文件系统即数据库”，并直接管理用户目录中的 symlink；Cindy 还需要兼容 Windows、插件批准 receipt、项目资源 containment、Pi 的隔离运行时以及已有 SkillHub/市场数据模型。

相关记录

• #2134（已合入）：直接修复 Pi Skill 真实路径、祖先 Git 边界和 discovered/loaded 状态投影，是当前管理器应复用的运行时事实来源，而不是重新实现一套扫描规则。
• #2481（已合入）：修正 Pi 项目 Skill 尚未加载时的 UI 文案，说明团队已经决定区分“未加载”和“需要信任”，管理器应沿用这一状态语义。
• #2295（开放）：提供 host-owned、skills-only 的 Pi 项目资源装配 consumer seam；缺少 approval authority 时继续 fail closed，说明项目 Skill 的可用性不能由管理器 UI 单方面开启。
• #2482（开放 Draft）：在 为 Pi 装配已批准的项目技能 #2295 基础上接入受 containment 约束的 Pi 项目 Skill admission，尚未发布，不能作为当前用户能力承诺。
• #2265（开放 Draft）：插件的渐进式 Manual 披露，解决的是运行时信息按需加载，不是 Skill 资产管理；可作为后续“管理元数据与执行内容分离”的背景，不应与本 Issue 合并实施。

建议行动

1. 先做现状台账：按 user/project、来源目录、真实路径、引擎、发现状态、运行时加载状态、安装/市场来源和是否为受管链接逐项列出，明确每个字段的唯一事实源。
2. 先做只读聚合原型：展示“来源、覆盖引擎、当前状态、最近一次扫描/加载结果、冲突或断链原因”，不改变文件、不自动批准项目资源。
3. 选择性引入 Popskill 能力：优先来源识别、断链诊断、内容哈希和套装聚合；更新、删除、回收站和批量挂载放在明确的用户确认与回滚设计之后。
4. 验证矩阵至少覆盖：.agents/skills、.claude/skills、.codex/skills、Pi .pi/skills、项目与祖先 Git 目录、真实目录与 symlink 冲突、重复名称、Windows 路径、Pi 新会话 get_commands 结果，以及 SkillHub/市场安装后的状态一致性。

风险与边界

• 不建议直接链接或复制整个 ~/.pi/agent，不建议因为“管理器优化”而默认传 --approve、开放 packages/extensions 或绕过现有 approval/containment。
• 不建议新增第二套持久化状态来重复记录已有安装账本、SkillHub 来源或 Pi runtime manifest；若需要缓存，应明确它是可重建索引，不是权限事实。
• 当前没有真实用户故障、数据损坏或线上性能证据支持立即实施大规模重构。下一步最需要补的是：团队希望统一管理哪些引擎/来源、哪些操作必须由用户确认，以及 SkillHub、项目 Skill 和用户本地 Skill 是否要在同一产品面内管理。

验证建议：先以现有 scanner、shared-global-skills、SkillHub 和 runtime capability 测试作为回归基线；只读聚合原型完成后，再补跨平台文件变化监听、哈希扫描成本和真实 Electron 交互验证。