[Bug] SKILL不显示

[valiantyan]

What happened? / 问题描述

这是 pi cli 中显示 pi-deskotp 中不显示。 pi-planning-with-files 这个 SKILL 我是安装在：/Users/yanhao/.pi/agent/npm/node_modules/planning-with-files 请问这是 BUG 吗？ @vastsa

Steps to reproduce / 复现步骤

SKILL 在 pi cli 中显示，但是 pi-desktop 中不显示

Expected behavior / 预期行为

pi cli 中的 SKILL 应该在 pi-desktop 中都能显示啊

Actual behavior / 实际行为

不显示 SKILL

App version / 应用版本

0.14.6

Operating system / 操作系统

macOS

Extra environment / 其他环境信息

No response

Logs / 日志

Screenshots / 截图

No response

[vastsa]

您好，手动导入之后有吗

[bd-dxg]

我刚刚下载这个桌面版, 设置里已经显示自动导入了17个skill(全局), 但是在对话框 输入斜杠后 不显示,

对话框斜杠后 没有skill提示

版本: 0.14.6
系统: win 11 pro

[vastsa]

拆成两件事，避免和 #142 混在一起：

1. 斜杠菜单列出 host 技能注册表里的全局/项目技能：当前 main 已修（8e838549，见 [Bug] Windows客户端无法调用全局技能 #142）。设置里「自动导入了 17 个全局 skill」若来源是 ~/.agents/skills，需要含该提交的构建。
2. 本 issue 正文：pi-planning-with-files 装在 ~/.pi/agent/npm/node_modules/，这是 pi CLI 的 npm: 扩展，Desktop 目前不会加载。继续由本 issue 与 [Feature] 支持 pi CLI 的 npm: 扩展（如 pi-maestro-flow）在 PI-Desktop 中使用 #242 跟踪。

保持开放。

[valiantyan]

您好，手动导入之后有吗

手动 + 官方命令安装都不能找到

[muzimu217]

用了刚合并的 #288 在本地按你的复现路径跑了一遍,已修复 👍

我把真实 planning-with-files@3.17.1 放在 ~/.pi/agent/npm/node_modules/planning-with-files(和你一样的位置)做的验证:修复前的导入器会因为复制过滤器把祖先路径里的 node_modules 整个包丢弃(44 个文件一个都没拷进去),所以技能永远不显示;#288 之后手动导入这个目录,pi.skills 会被正确映射成插件的技能贡献,44 个文件逐字节完整,技能 pi-planning-with-files 在插件运行时和宿主 plugins.loadDev 里都能正常加载。

两点提醒:

1. 需要升级到包含 fix(plugins): 修复已安装 pi npm 包的技能导入 #288 的构建(0.14.6 还没有这个修复),然后在 Desktop 的导入入口把这个包目录重新导入一次 —— fix(plugins): 修复已安装 pi npm 包的技能导入 #288 是手动导入路径的修复,不会自动扫描 ~/.pi(那部分由 [Feature] 支持 pi CLI 的 npm: 扩展（如 pi-maestro-flow）在 PI-Desktop 中使用 #242 继续跟踪,依赖安装已在 feat(plugins): install dependencies for imported pi packages (follow-up to #288) #300 跟进);
2. 评论里提到的「设置显示 17 个全局 skill 但斜杠不显示」是另一条路径,按维护者的拆分在 [Bug] Windows客户端无法调用全局技能 #142 里,这个 PR 不覆盖它。

如果还有人遇到,可以试试升级后手动重新导入一次包目录;仍然不显示的话,麻烦贴一下 Desktop 版本和导入时选的路径。

[valiantyan]

用了刚合并的 #288 在本地按你的复现路径跑了一遍,已修复 👍
我把真实 planning-with-files@3.17.1 放在 ~/.pi/agent/npm/node_modules/planning-with-files(和你一样的位置)做的验证:修复前的导入器会因为复制过滤器把祖先路径里的 node_modules 整个包丢弃(44 个文件一个都没拷进去),所以技能永远不显示;#288 之后手动导入这个目录,pi.skills 会被正确映射成插件的技能贡献,44 个文件逐字节完整,技能 pi-planning-with-files 在插件运行时和宿主 plugins.loadDev 里都能正常加载。
两点提醒:

1. 需要升级到包含 fix(plugins): 修复已安装 pi npm 包的技能导入 #288 的构建(0.14.6 还没有这个修复),然后在 Desktop 的导入入口把这个包目录重新导入一次 —— fix(plugins): 修复已安装 pi npm 包的技能导入 #288 是手动导入路径的修复,不会自动扫描 ~/.pi(那部分由 [Feature] 支持 pi CLI 的 npm: 扩展（如 pi-maestro-flow）在 PI-Desktop 中使用 #242 继续跟踪,依赖安装已在 feat(plugins): install dependencies for imported pi packages (follow-up to #288) #300 跟进);
2. 评论里提到的「设置显示 17 个全局 skill 但斜杠不显示」是另一条路径,按维护者的拆分在 [Bug] Windows客户端无法调用全局技能 #142 里,这个 PR 不覆盖它。

如果还有人遇到,可以试试升级后手动重新导入一次包目录;仍然不显示的话,麻烦贴一下 Desktop 版本和导入时选的路径。

等发布 mac 0.14.6升级版本我再测试看看吧

[vastsa]

已在 origin/main（b48c11d1）核对这条，结论是仍未修复，保持 open。

代码事实：

• PI-Desktop 自己的能力目录来自 crates/host-core/src/agent_capabilities.rs:11 的 AGENTS_DIR = ".agents"，capability_dir()（同文件 :202-217）只解析两处：全局 ~/.agents/skills、项目 <project>/.agents/skills；user_skills.rs:134-152 在每层里读散装 *.md 以及 <skill>/SKILL.md。
• 扩展/技能发现走 packages/agent-runtime/src/extensions/discovery.ts:188-193：只扫 ~/.pi/agent/extensions、<project>/.pi/extensions，加上用户手动添加的路径。
• 全仓没有任何自动扫描 ~/.pi/agent/npm/node_modules/** 的代码。

所以报告者的场景（skill 装在 ~/.pi/agent/npm/node_modules/planning-with-files，pi CLI 能看到、PI-Desktop 看不到）目前依然成立：PI-Desktop 不会自动发现 npm 安装的 pi 包里的 skill。

已有的受支持路径（PR #288 补的）：在扩展/插件入口里手动选择该包目录导入。apps/desktop/electron/main/agent-extensions.ts:298-317 会调用 discoverImportedPackageSkills，把包内显式声明的 pi.skills 映射成插件技能（纯技能包只声明 agent.prompt.inject，不会把 index.js 当可执行扩展）。也就是说：今天可以导入，但不会自动出现。

修复方向（已单独排期）：让 npm 安装的 pi 包里的 skill 能被发现。考虑到技能属于提示层输入、仓库现有信任模型要求用户授权，倾向做成"可发现、显式启用"（例如在技能页列出候选并让用户启用），而不是静默加载任意包内技能。欢迎对这条取舍给意见。

[vastsa]

我按 origin/main @ 8fff510a 核了一遍：这条在 main 上仍然没有修复，~/.pi/agent/npm 下的 npm 安装包不会被自动发现。维护者之前的判断是对的。

现状（已核实）

技能/扩展的扫描根只有这些：

• ~/.agents/skills、<project>/.agents/skills —— crates/host-core/src/agent_capabilities.rs:11（AGENTS_DIR = ".agents"）、:196-217；crates/host-core/src/user_skills.rs:140-151（只认 *.md 与 <dir>/SKILL.md）。
• ~/.pi/agent/extensions、<workspace>/.pi/extensions —— packages/agent-runtime/src/extensions/discovery.ts:188-193，但这段目前没有生产调用方，只有测试在调（即它是死代码）。

全仓 grep agent/npm、npm/node_modules、PI_AGENT_DIR、npmPkg 都是 0 命中；node_modules 的命中全是忽略规则与拷贝排除，没有一处是技能发现。所以 ~/.pi/agent/npm/node_modules/planning-with-files 今天不会被自动列出。

今天能用的办法：手动导入

Plugins → Import pi extension，在文件框里直接选 ~/.pi/agent/npm/node_modules/planning-with-files（或它所在的包目录）。主进程会把包复制成 plugins/imported/<slug>，读取 package.json 的 pi.skills 生成技能条目：apps/desktop/electron/main/imported-package-skills.ts:26（discoverImportedPackageSkills）、agent-extensions.ts:297-317、IPC 见 agent-extensions-ipc.ts:69-83。

这条路径不会自动扫描 ~/.pi，只有你明确选路径时才生效，弹框前的确认就是信任决定。请确认版本 ≥ 0.14.7（#288 的提交已在 v0.14.8 祖先链上）后再试一次 —— 如果手动导入成功但技能列表里还是看不到，那是一个新 bug，麻烦把导入后的插件行与技能页截图发上来。

另外提醒一点：设置里显示「已自动导入 17 个全局 skill」但斜杠菜单不显示，那是另一条路径（#142），与这里的 npm 包发现无关，而且 #142 已经关闭。

为什么不建议「顺手加一行扫描」

现有决定挡着这个方向，而且它们彼此之间还没对齐：

• docs/spec/07-plugins/16-trusted-extensions.md:46：D007 stays in force，PI-Desktop 永不自动导入 ~/.pi；:142 更直接写了「never automatically scans or imports ~/.pi」；v3（读取 pi CLI settings.json 的只读提示、统一 skill/prompt 发现）在 §12 标记为 Not scheduled。
• 但 docs/adr/0214-trusted-extensions.md:41 写的是「D007 is unchanged: ~/.pi is scanned for candidates, never imported」—— 与上一句矛盾，而负责「扫描候选」的 discoverTrustedExtensions 实际是死代码。
• ADR 0112 §1：host 只扫/写 .agents 下那 5 个目录，.pi/skills 不是能力来源。

另外，全局与项目技能目前都默认「已启用」（agent_capabilities.rs 的 enabled() 两个分支都是 unwrap_or(true)），所以「发现但未启用」这个状态无法直接塞进现有技能记录里。

需要维护者决定的两件事

1. 是否把 ~/.pi/agent/npm/** 下的 npm 安装包作为只读候选列出来（只发现，不导入、不执行；启用动作仍走现有导入流程）？这会 amend ADR 0112 §1 并给 spec16 的 v3 排期，按仓库惯例需要一条 ADR。
2. 顺手把 ADR 0214:41 与 spec16:142 的措辞收口 —— 目前一个说「扫候选」，一个说「从不自动扫描」，两边实现的依据不同。这个矛盾本身值得单独修掉。

方向定了我可以按第 1 条实现（候选扫描放 Electron main，复用 discoverImportedPackageSkills 的 pi.skills 解析，技能页加一个「发现但未启用」分区），不会让 npm 包变成自动加载。

[valiantyan]

很奇怪为什么不找 .pi/skill 目录下的 SKILL 呢？

[vastsa]

复核确认场景仍存在：当前 main 不会自动扫描 ~/.pi/agent/npm/node_modules 下的 pi npm 包技能；#288 只修复了用户主动选择包目录后的手动导入。自动发现需要显式信任/启用设计，且与现有不静默导入 ~/.pi 的安全约束相关，因此属于技能发现兼容功能，不是已合并的 bug 修复。我已将分类调整为 enhancement，issue 保持开放。