opencode-idea 0.0.22 → 0.0.23

package/README.md

@@ -276,8 +276,9 @@ opencode-idea 对这一组工具做三件事:
      建配置是落盘成 `.run/*.run.xml` 供反复用)。判据只写在这一处,**「命令执行」段不重复**,只留
      「配置一律不由你写」这条无条件的,以及"该建的用哪条路建"那一条按工具是否存在分流:有工具时指向上面那条、
      并说明非 Shell 类型与删 / 改交给用户调 `idea-run-config-manager` skill;
-     没有工具时换成「讲清楚配置名 / 命令 / 工作目录 / 理由,请用户在 IDE 里自己建」—— 那时**连那个 skill 也不会出现**
-     (它的门就是这个工具),所以引导里顺手把这一点说明了,免得以后有人把它当成漏写而"补"上一句调不到的指令。**没装插件时绝不会提到那个工具。**
+     没有工具时换成「讲清楚配置名 / 命令 / 工作目录 / 理由,请用户在 IDE 里自己建」—— 那时 skill 本身仍在(它不按工具门禁),
+     但缺 create 工具时它也只能把流程交回用户,所以引导里顺手把这一点说明了,免得以后有人把它当成漏写而"补"上一句调不到的指令。
+     **没装插件时绝不会提到那个工具。**
 3. **工具名清单**写在 `src/mcp/enhance.js`(与原生 IDE 的 `src/mcp/idea.js` 分开放:原生走原生,插件的走插件的),
    与该仓库的 `RunLifecycleSchemas.kt` 保持同步。工具按**存在的子集**逐个点名(而不是「有就全写」),这样旧版本的配套
    插件少给一两个工具时,引导也不会提到它们。同理,**每条命令名只列真的提供它的项目**(逐项目核对,见「条件注入」)——
@@ -301,27 +302,26 @@ opencode-idea 对这一组工具做三件事:
 - 无论哪条路,**写完都要用 `get_run_configurations` 复查** —— `type` 写错 IDE 会静默忽略整个文件,这是唯一的判据;
 - 这些事**不再散着说"让用户自己去 IDE 里搞"**,而是统一指向那个 skill:**让用户调它**(`@idea-run-config-manager`)—— 它是本项目 run
   configuration 增 / 删 / 改的唯一流程入口,**只能由用户触发**(理由见下面的「而且只能用户调」);
-- **没装配套插件** → 那个 skill 也不存在(它的门就是 create 工具),此时才直接请用户自己在 IDE 里建。
+- **没装配套插件** → skill 仍然在(它现在不按工具门禁),只是缺 create 工具时它也只能把流程交回用户,请你在 IDE 里建。
 
 > **曾经有一个 `idea-run-config` skill 教模型凭记忆手写 `.run/*.run.xml`,已经删掉。** 理由不是"不许写",而是**不许凭空写**:`type` 写错 IDE 会
 > **静默忽略整个文件、日志里也不报**,凭记忆猜 option 名就是这么错的。现在这件事由 `idea-run-config-manager` 接手 —— 但**每个类型都得有一份实测模板**
 > (`assets/types/`,字段名全部来自真实文件),没模板的类型宁可交给用户。
 
-**skill 的生命周期跟随两道门,缺一不可**:
+**skill 在插件加载时一次性注册,不跟随工具目录**:
 
-1. **项目配置** —— `/open-in-ide` 写入配置时注册、`/delete-in-ide` 删配置时注销;以前配置过的 root 在 `setup` 时(读回配置)
-   也会走这一步。未配置的 root 不受影响。
-2. **IDE 真的在提供这个 skill 依赖的工具** —— skill 在自己的 frontmatter 里用 `requires:` 声明它绕着哪个工具写,而且写的是**后缀**
-   (例如 `idea-standalone` 声明 `rerun_run_configuration`、`idea-run-config-manager` 声明 `create_shell_run_configuration`,真实工具名是
-   `<项目前缀>rerun_run_configuration` / `<项目前缀>create_shell_run_configuration`)。**没这个工具就不注册这个 skill**:
-   一个教模型去调"它根本看不到的工具"的 skill,不是知识,是一次注定的失败调用。工具的可见性是双向跟随的 —— `setup` 时还没
-   连过 IDE、目录未知,所以那时**不注册**;等 IDE 应答(`/open-in-ide` 或重连)后目录才算已知,该出现的才出现;反过来,某个
-   请求里工具没了,skill 也跟着撤(不需要等重连)。
-   `requires` 必须写 **OpenCode 侧的名字**(IDE 工具带 `ide_` 服务器前缀),因为门就是拿它跟 `ctx.tool.list()` 比;
-   写成 IDE 的原始名(`rerun_run_configuration`)会让这个 skill 在任何机器上都不出现,而且没有任何报错。
+- **判据只有"插件加载了"** —— 不看项目有没有 `/open-in-ide`、也不看 IDE 此刻serve 了哪些工具。
+- **为什么不再按工具门禁**:早先的做法是"IDE 真的提供了这个 skill 绕着的工具才注册"(frontmatter 的 `requires:` + `ctx.tool.list()`)。
+  门本身是对的,但**注册时机错了**:它发生在 `/open-in-ide` 完成之后,而客户端在这之前就已经把 skill 列表快照给当前会话了 ——
+  结果是"服务端注册了、`@` 补全里看不到",**必须刷新页面才出现**。注册提前到 `setup`,就落在快照之前。
+- **工具缺失的代价放回正文** —— skill 里本来就写了"工具列表里没有 `<前缀>_rerun_run_configuration` 时交回用户"这类话;
+  一个缺席的工具是模型能读到并处理的事实,一个看不见的 skill 不是。
+- **`requires:` 这个键已彻底删除** —— 它曾是本插件自己的门禁元数据,OpenCode 不认,注册走 `ctx.skill.transform` 时也不会带上它;
+  门禁取消后它就成了"看起来在设门、实际没人读"的死字段,留着只会误导下一个改代码的人。skill 绕着哪几件工具写,由正文自己说明。
+
+文档放在 `skills/<id>/SKILL.md`(每个 skill 一个目录,`name` / `description` 走 YAML frontmatter,需要"只由用户调"时再加
+`metadata: opencode/autoinvoke: false`),由 `src/skill/loader.js` 扫描加载 —— **加新 skill 只需加一个目录,不用改代码**。
 
-文档放在 `skills/<id>/SKILL.md`(每个 skill 一个目录,`name` / `description` / `requires` 走 YAML frontmatter,`requires` 由
-loader 消费、**不会进入注册给 OpenCode 的定义**),由 `src/skill/loader.js` 扫描加载 —— **加新 skill 只需加一个目录,不用改代码**。
 
 还可以用 OpenCode 官方的 frontmatter 写法**关掉模型主动调用**:
 
@@ -366,6 +366,7 @@ loader 读的是 OpenCode 文档里的那个嵌套写法(它自己的读取器
 2. **建档**:过滤之后剩下的每个 run configuration 在**项目根 `AGENTS.md`** 的标记块(`<!-- idea-run-config-manager:begin -->` /
    `<!-- idea-run-config-manager:end -->`)里占**一个条目** —— 标题是配置名(括号里写它属于哪个项目),下面五项固定:
    `when` / `before run` / `run` / `after run` / `desc`;
+   **每一项各选一种写法**(行内 / 子列表),同一配置里可以混用 —— 全行内、全子列表、混合(例如 `when` 一句、`after run` 三条)都合法,判据只有"这一项自己有几句话",模板里给了两种形态的可照抄例子;
    `when` 回答的是**谁能起它**,而这件事只有三种:`用户授权触发`(用户开口 / 在本会话里一次性授权之后 AI 才跑,后面写用户通常在什么情况下要它跑)、
    `AI 自己触发`(AI 判断到场景就自己跑,**必须把场景写具体**)、`用户手动触发` ——
    最后这一种**不进条目**,只登记在块末尾「用户手动触发(线下,AI 不跑)」一节,**只有名字**,五项一律不写(没人会照它跑);
@@ -418,8 +419,8 @@ loader 读的是 OpenCode 文档里的那个嵌套写法(它自己的读取器
 **别的文档都指向这里**:引导文本与 `idea-standalone` skill 碰到"要建 / 删 / 改一个配置",不再让用户自己去 IDE 里摸,而是让用户调本 skill ——
 增 / 删 / 改的流程入口只有这一个,而它只由用户触发。
 
-**它比 `idea-standalone` 多一道门**:frontmatter 里 `requires: create_shell_run_configuration` —— 它绕着"新建配置"这件事写,而新建只有
-配套插件 `idea-mcp-enhance` 能做,所以**没装插件的 IDE 看不到它**(`idea-standalone` 只要 `rerun_run_configuration`,门更松)。这是刻意的:
+**它绕着"新建配置"这件事写**(新建只有配套插件 `idea-mcp-enhance` 能做),但**这不影响它出不出现** —— 两个 skill 都在插件加载时注册,
+不缺任何工具也照样在列表里;缺工具时由正文把流程交回用户(`idea-standalone` 只要 `rerun_run_configuration`,门更松)。这是刻意的:
 一个只教模型"去建配置"、却没给建配置工具的 skill,只会把用户拖进一次注定失败的调用。
 
 **而且只能用户调**:它的 frontmatter 带 `metadata: opencode/autoinvoke: false`,loader 翻成定义的 `autoinvoke: false` ——

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "opencode-idea",
-  "version": "0.0.22",
+  "version": "0.0.23",
   "description": "OpenCode plugin that connects to JetBrains IDE MCP servers and prefers IDE tools when the current project is open in the IDE",
   "main": "src/index.js",
   "type": "module",

package/skills/idea-run-config-manager/SKILL.md

@@ -1,7 +1,6 @@
 ---
 name: idea-run-config-manager
-requires: create_shell_run_configuration
-description: "管理本项目的 run configuration:直接增 / 删 / 改(新建走工具,改和删直接编辑 `.run/<配置名>.run.xml` —— 都照 `assets/types/` 里**逐类型实测模板**写,没有模板的类型交给用户在 IDE 里配),并把配置档案同步进**项目根 `AGENTS.md`** 里由 `<!-- idea-run-config-manager:begin -->` 与 `<!-- idea-run-config-manager:end -->` 包裹的标记块 —— 每个 run configuration 一个条目,写清它干什么、怎么跑、什么时候跑;服务化的那些不在这里,它们归 `idea-standalone` 的块。当用户要建 / 删 / 改 run configuration,或要一份"这个项目有哪些配置、各自干什么"的说明时使用。"
+description: "管理本项目的 run configuration:直接增 / 删 / 改(新建走工具,改和删直接编辑 `.run/<配置名>.run.xml` —— 都照 `assets/types/` 里**逐类型实测模板**写,没有模板的类型交给用户在 IDE 里配),并把配置档案同步进**项目根 `AGENTS.md`** 里由 `<!-- idea-run-config-manager:begin -->` 与 `<!-- idea-run-config-manager:end -->` 包裹的标记块 —— 每个 run configuration 一个条目,写清它干什么、怎么跑、什么时候跑;服务化的那些不在这里,它们归 `idea-standalone` 的块。当用户要建 / 删 / 改 run configuration,或要一份「这个项目有哪些配置、各自干什么」的说明时使用。"
 metadata:
   opencode/autoinvoke: false
 ---
@@ -10,6 +9,8 @@ metadata:
 
 **联动是硬要求**:配置被**新建 / 删除 / 修改**,文档就跟着**加条目 / 删条目 / 改条目** —— 无论那次改动是谁做的(你做的、用户自己做的、用户删掉的,都算)。改了配置却忘了同步这个档案块,等于它在骗下一个读者。
 
+**工具不在时**:先看工具表里有没有 `<前缀>_get_run_configurations` / `<前缀>_create_shell_run_configuration`。没有,就是项目还没接入 IDE(或那个 IDE 没装 `idea-mcp-enhance`)—— 让用户执行 `/open-in-ide`,接入之前**不要手写 `.run/*.run.xml` 假装做完**(IDE 不认,复查也过不了)。
+
 ## 流程
 
 1. **读**:项目根 `AGENTS.md` —— 有没有 `<!-- idea-run-config-manager:begin -->` … `<!-- idea-run-config-manager:end -->` 标记块(有则更新,没有就在文件末尾追加);同时读同文件里 `idea-standalone` 的标记块,它登记过的配置不进本块。

package/skills/idea-run-config-manager/assets/AGENTS.template.md

@@ -5,73 +5,138 @@
 <!-- 生成提示:begin -->
 
 标记之外是项目自己在 `AGENTS.md` 里维护的内容,本 skill 一律不动;也只写这个项目 —— 不写全局配置目录,不另建规则文件。
-`{...}` 是待替换的元变量,不留进产物。未涉及的条目与小节整块删掉,不留空标题。
-**`<!-- 生成提示:… -->` 是给生成过程的说明,产物里整块删掉** —— 产物是给 AI 当规则读的,里面不该留指令。
+`{...}` 是待替换的元变量,不留进产物。未涉及的条目与小节整块删掉,不留空标题。 **`<!-- 生成提示:… -->`
+是给生成过程的说明,产物里整块删掉** —— 产物是给 AI 当规则读的,里面不该留指令。
 <!-- 生成提示:end -->
 
-本项目里**除服务化应用之外**的 run configuration:每个配置**是什么、怎么跑、什么时候跑**;服务化(长驻应用)的配置登记在 `idea-standalone` 块里,不在这里。
+本项目里 **除服务化应用之外**的 run configuration:每个配置 **是什么、怎么跑、什么时候跑**;服务化 (长驻应用)的配置登记在
+`idea-standalone` 块里,不在这里。
 
 **谁能起它,只有三种** —— 读这个块的人照它决定动不动手:
 
-- **用户手动触发**:用户自己在 IDE 里跑,AI **完全不碰**。这类只登记在末尾「用户手动触发」一节,**只有名字**,没有别的说明。
-- **用户授权触发**:用户开口之后 AI 才跑(用户也可以在这个会话里一次性授权);**AI 不自己挑时机**。
+- **用户手动触发**:用户自己在 IDE 里跑,AI **完全不碰**。这类只登记在末尾「用户手动触发」一节, **只有名字**,没有别的说明。
+- **用户授权触发**:用户开口之后 AI 才跑 (用户也可以在这个会话里一次性授权); **AI 不自己挑时机**。
 - **AI 自己触发**:AI 判断到场景就自己跑;这类条目的 `when` **必须把那个场景写具体**。
 
 ## run configuration 一览
 
 <!-- 生成提示:begin -->
 
-**先过滤**:动手前读 `<项目根>/AGENTS.md` 里 `idea-standalone` 的标记块,把它登记过的 run configuration 名字收集起来 —— **这些一律不进本块**(它们服务化 / 长驻,端口与热重载已在那边写清)。剩下的才是本块内容;没有那个块就不过滤。
-**枚举以工具为准**:各项目各有自己的工具前缀(root 是 `ide`,子项目是它的目录名),看哪个项目就用**它自己那个前缀**的工具 —— `<前缀>_get_run_configurations` 直接调用,不传参数,它给出 IDE 真正认的配置(含存在 `.idea/` 里的那些,单翻 `.run/` 目录看不到)。**项目与各子项目里真正存在的、过滤后剩下的都要有。**
+**先过滤**:动手前读 `<项目根>/AGENTS.md` 里 `idea-standalone` 的标记块,把它登记过的 run configuration 名字收集起来 ——
+**这些一律不进本块**(它们服务化 / 长驻,端口与热重载已在那边写清)。剩下的才是本块内容;没有那个块就不过滤。
+**枚举以工具为准**:各项目各有自己的工具前缀 (root 是 `ide`,子项目是它的目录名),看哪个项目就用 **它自己那个前缀**
+的工具 —— `<前缀>_get_run_configurations` 直接调用,不传参数,它给出 IDE 真正认的配置 (含存在 `.idea/` 里的那些,单翻
+`.run/` 目录看不到)。 **项目与各子项目里真正存在的、过滤后剩下的都要有。**
 **项目写在标题的括号里**(那套工具的前缀:root 写 `ide`,子项目写它的目录名):一条配置属于谁、该用哪套工具去看和跑,由它决定。
-标题里的配置名必须是该前缀下**真实存在的名字**,不凭印象写;块里有、项目里已经没有的**整个条目删掉**。
-**按操作系统分成两节**:macOS / Linux 一节,Windows 一节。同一份流程在两个平台上常常不是同一条命令(解释器不同、脚本后缀不同、路径写法不同),所以**按这个配置真正能跑的那个平台归节**,不要把 Windows 上才成立的命令写进 macOS 那一节。判断依据看配置里的解释器路径与脚本内容(例如 `INTERPRETER_PATH` 指向 PowerShell、命令里有 `\` 路径的,就是 Windows);**判断不了就问用户**,不猜。只在一个平台成立的流程就只写那一节。
+标题里的配置名必须是该前缀下 **真实存在的名字**,不凭印象写;块里有、项目里已经没有的 **整个条目删掉**。
+**按操作系统分成两节**:macOS / Linux 一节,Windows 一节。同一份流程在两个平台上常常不是同一条命令
+(解释器不同、脚本后缀不同、路径写法不同),所以 **按这个配置真正能跑的那个平台归节**,不要把 Windows 上才成立的命令写进 macOS
+那一节。判断依据看配置里的解释器路径与脚本内容 (例如 `INTERPRETER_PATH` 指向 PowerShell、命令里有 `\` 路径的,就是
+Windows); **判断不了就问用户**,不猜。只在一个平台成立的流程就只写那一节。
 
-**when** 写**谁能起它、什么场景起它** —— 会进这份列表的只有两种,写明是哪一种:
+**when** 写 **谁能起它、什么场景起它** —— 会进这份列表的只有两种,写明是哪一种:
 
-- **用户授权触发**:用户开口(或在本会话里授权)之后 AI 才跑;后面写用户通常在什么情况下会要它跑(发版前 / 出安装包 / 回归)。
-- **AI 自己触发**:AI 判断到这个场景就自己跑;后面**必须把场景写具体**(改完某类代码要生成代码 / 改了依赖要装依赖 / 改了 schema 要同步某个环境的 DDL),不写"需要时""合适时"。
+- **用户授权触发**:用户开口 (或在本会话里授权)之后 AI 才跑;后面写用户通常在什么情况下会要它跑 (发版前 / 出安装包 /
+  回归)。
+- **AI 自己触发**:AI 判断到这个场景就自己跑;后面 **必须把场景写具体**(改完某类代码要生成代码 / 改了依赖要装依赖 / 改了
+  schema 要同步某个环境的 DDL),不写"需要时""合适时"。
 
 第三种 —— **用户手动触发**(用户自己在 IDE 里跑、AI 完全不碰)**不要写进上面的条目**,登记到末尾「用户手动触发」一节,只写名字。
-判断不了就问用户。**有副作用的流程(改远端、动数据、出产物)说不清场景就别标成 AI 自己触发** —— 归"用户授权触发"。
-
-**before run** 写**跑之前要先做的事**(先装依赖 / 先构建 / 先起某个服务):**多数没有 —— 写 `无`**(这一项始终在,别省略)。确实得先做点什么才写,而且**按顺序写清第 1 步、第 2 步**。前置事项往往**不是**一个 run configuration(没有对应配置),所以只能写在这里 —— 漏了它,照着本块跑的人会直接跑出一个起不来的流程。
-**run** 写走哪条工具:跑完即退的用 `<前缀>_execute_run_configuration`;长驻进程用 `<前缀>_rerun_run_configuration`(在跑就重启、没在跑就启动)。**不要**用 `execute` 跑长驻进程 —— 它是 Run 路径,对常驻进程**它会起出重复实例**。
-**after run** 写**跑完之后的结果**:产物落在哪(路径 / 文件名 / 被谁读走),以及**接下来要不要做什么**(要发布 / 要拷贝到某处 / 要通知谁 / 什么都不用做)。**没有产物、跑完就完的,写 `无`。**
-**desc** 是这个条目唯一的自由文本项:**它是什么、干什么的**(同步某个环境的 DDL / 生成代码 / 跑迁移 …),以及有什么坑(必须先备份 / 只对某个环境生效 / 幂等与否 …)。
-分两件事都往这里写,**不要再开新项**。写清它到底跑什么命令,就读它所在项目的落地文件 `.run/<name>.run.xml` 看里面的内容,拿不准就**问用户**,不猜。
-本块的**主要价值**就在 **desc** 与 **before run**:下次要办同类事情先在这里搜关键词,找得到就直接用,**不要再建一个重复的**。
-**目录、端口这类"配置里本来就有"的字段不要抄进来** —— 它们会跟配置变旧而对不上;确实要交代依赖关系,就写进 `desc` 或 `before run`。
-**五项的名字与顺序不要改**(`when` / `before run` / `run` / `after run` / `desc`),并且**与 `idea-standalone` 应用表的列同名同序**(`before run` / `run` / `after run` / `desc` 这四项两边一致);本块多 `when`,那边多 `app` / `run configuration` / `port`(服务化应用就是"改完代码要起它来测"的时候起,没有别的时机可写)。**五项始终都在**:`before run` / `after run` 真没有内容就写 **`无`** —— 不省略,也不写 `-` / `N/A`。
+判断不了就问用户。 **有副作用的流程 (改远端、动数据、出产物)说不清场景就别标成 AI 自己触发** —— 归"用户授权触发"。
+
+**每一项都有两种写法,逐项判断,不要给整条定一个"简单/复杂"模式**:
+
+- **行内形态** —— 这一项只有一句话:写在项名同一行,`when:用户授权触发 —— 改了 x 后 y`。
+- **子列表形态** —— 这一项有好几条 (多个触发条件 / 多个步骤 / 多个结果 / 多个事实):项名冒号后留空,缩进两个空格各起一条
+  `-`。
+
+所以同一个条目里 **混着两种写法是常态**,下面三种都可以:
+
+| 情况     | 长什么样                                       | 典型配置                                       |
+|----------|------------------------------------------------|------------------------------------------------|
+| 全行内   | 五项各一句,没有任何子项                        | 跑完即退、一句话能说清的命令(推迁移、跑生成器) |
+| 全子列表 | 五项里多数各有多条                             | 带产物、要同步、要重启的构建 / 部署类          |
+| 混合     | 例如 `when` 一句行内、`after run` 三件事拆三条 | 最常见 —— 只看**那一项自己**有几句             |
+
+判断只看"这一项有几句话",与配置本身复杂不复杂无关;别为了整齐把一句硬拆成几条,也别把五六条压成一行。也可以只对少数项例外:
+`before run:无(脚本自己跑 mvn package)` 这种一句带解释,就留在行内。
+
+示例 (混合形态):
+
+```markdown
+- `connector-build`(项目 ide)
+    - when:AI 自己触发
+        - 改了 `poc/文件数据源解析与检索/解析程序` 下的 Java 源码后,重新出连接器 jar 并装进
+          `middleware/seatunnel/connectors/`
+    - before run:无 (脚本自己跑 mvn package)
+    - run:ide_execute_run_configuration
+    - after run:
+        - 产物 `middleware/seatunnel/connectors/connector-fileparse-<ST 版本>.jar`(78M,已 gitignore)
+        - 接着同步到部署机:`ide_upload_to_deployment`,`serverName` 传 `mbpmiddleware`、`mode` 传 `upload`(默认 `mirror`
+          会删远端多余文件,别用);`in_progress` 就按 handle 轮 `ide_get_deployment_task_status`
+        - 同步完在部署机上 `docker compose restart seatunnel`
+    - desc:
+        - 一条命令完成「构建 → 拷进 connectors → 打印 md5 并与 compose 引用比对」
+        - 产物改名会在输出里点名 compose 失配;脚本本身不管同步与重启
+```
+
+示例 (全行内形态,同一块里出现很正常):
+
+```markdown
+- `db-migrate`(项目 ide)
+    - when:用户授权触发 —— 改了 `packages/db` 的 schema 后要重新生成客户端并推迁移
+    - before run:无
+    - run:ide_execute_run_configuration
+    - after run:数据库结构更新,生成的客户端代码落在 `packages/db`
+    - desc:先 `pnpm -C packages/db generate` 再 `migrate:deploy`;动远端数据,不由 AI 自行触发
+```
+
+**before run** 写 **跑之前要先做的事**(先装依赖 / 先构建 / 先起某个服务):**一条一步,按顺序排**。 **多数没有 —— 写 `无`**
+(这一项始终在,别省略)。前置事项往往 **不是**一个 run configuration (没有对应配置),所以只能写在这里 ——
+漏了它,照着本块跑的人会直接跑出一个起不来的流程。 **run** 写走哪条工具:跑完即退的用 `<前缀>_execute_run_configuration`
+;长驻进程用 `<前缀>_rerun_run_configuration`(在跑就重启、没在跑就启动)。 **不要**用 `execute` 跑长驻进程 —— 它是 Run
+路径,对常驻进程 **它会起出重复实例**。 **after run** 写 **跑完之后的结果**:**产物落在哪**(路径 / 文件名 / 被谁读走)一条,
+**接下来要不要做什么**(要发布 / 要同步到某台机器 / 要重启什么 / 什么都不用做)一条。 **没有产物、跑完就完的,写 `无`。**
+**desc** 是这个条目唯一的自由文本项:**它是什么、干什么的**(同步某个环境的 DDL / 生成代码 / 跑迁移 …)一条,有什么坑
+(必须先备份 / 只对某个环境生效 / 幂等与否 …)一条。
+分两件事都往这里写, **不要再开新项**。写清它到底跑什么命令,就读它所在项目的落地文件 `.run/<name>.run.xml` 看里面的内容,拿不准就
+**问用户**,不猜。
+本块的 **主要价值**就在 **desc** 与 **before run**:下次要办同类事情先在这里搜关键词,找得到就直接用,
+**不要再建一个重复的**。 **目录、端口这类"配置里本来就有"的字段不要抄进来** —— 它们会跟配置变旧而对不上;确实要交代依赖关系,就写进
+`desc` 或 `before run`。 **五项的名字与顺序不要改**(`when` / `before run` / `run` / `after run` / `desc`),并且 **与
+`idea-standalone` 应用表的列同名同序**(`before run` / `run` / `after run` / `desc` 这四项两边一致);本块多 `when`,那边多
+`app` / `run configuration` / `port`(服务化应用就是"改完代码要起它来测"的时候起,没有别的时机可写)。 **五项始终都在**:
+`before run` / `after run` 真没有内容就写 **`无`** —— 不省略,也不写 `-` / `N/A`。
 <!-- 生成提示:end -->
 
 ### macOS / Linux
 
-- {配置名}(项目 {前缀})
-  - when:{用户授权触发 / AI 自己触发} —— {什么场景}
-  - before run:{第 1 步 / 第 2 步 / 无}
-  - run:{<前缀>_execute_run_configuration}
-  - after run:{产物落在哪 / 接下来要做什么 / 无}
-  - desc:{它是什么 + 有什么坑}
+- {配置名} (项目 {前缀})
+    - when:{用户授权触发 / AI 自己触发} —— {什么场景}
+    - before run:{第 1 步 / 第 2 步 / 无}
+    - run:{<前缀>_execute_run_configuration}
+    - after run:{产物落在哪 / 接下来要做什么 / 无}
+    - desc:{它是什么 + 有什么坑}
 
 ### Windows
 
-- {配置名}(项目 {前缀})
-  - when:{用户授权触发 / AI 自己触发} —— {什么场景}
-  - before run:{第 1 步 / 第 2 步 / 无}
-  - run:{<前缀>_execute_run_configuration}
-  - after run:{产物落在哪 / 接下来要做什么 / 无}
-  - desc:{它是什么 + 有什么坑}
+- {配置名} (项目 {前缀})
+    - when:{用户授权触发 / AI 自己触发} —— {什么场景}
+    - before run:{第 1 步 / 第 2 步 / 无}
+    - run:{<前缀>_execute_run_configuration}
+    - after run:{产物落在哪 / 接下来要做什么 / 无}
+    - desc:{它是什么 + 有什么坑}
 
-## 用户手动触发(线下,AI 不跑)
+## 用户手动触发 (线下,AI 不跑)
 
 用户自己在 IDE 里跑的那种配置 —— AI 不碰,这里只登记名字。
 
 <!-- 生成提示:begin -->
 
-只写名字(带项目),**不要**写 run / when / before run / after run / desc:没人会照它跑,写了只是噪音。判断不了某一项是"授权"还是"手动"就**问用户**。
+只写名字 (带项目), **不要**写 run / when / before run / after run / desc:
+没人会照它跑,写了只是噪音。判断不了某一项是"授权"还是"手动"就 **问用户**。
 <!-- 生成提示:end -->
 
-- {配置名}(项目 {前缀})
+- {配置名} (项目 {前缀})
 
 <!-- idea-run-config-manager:end -->

package/skills/idea-standalone/SKILL.md

@@ -1,6 +1,5 @@
 ---
 name: idea-standalone
-requires: rerun_run_configuration
 description: "为项目生成/维护 standalone(启动收口只有 IDEA run configuration)模式的纪律,写进**项目根 `AGENTS.md`** 里由 `<!-- idea-standalone:begin -->` 与 `<!-- idea-standalone:end -->` 包裹的标记块。当用户要做 standalone 规范、要固化「本机跑哪几个应用」「哪些应用热重载、哪些改了必须重启」「启停走哪个工具」这类项目级纪律时使用。产物固定三段:standalone 是什么、经 IDEA run configuration 启动哪些应用、逐应用的热重载与重启提示纪律。"
 ---
 

package/src/ide-guidance.template.md

@@ -160,6 +160,6 @@
 {{#if canCreateRunConfiguration}}
 - 要固化的固定流程(判据见上:会不会以同样形态重复发生):Shell 类型用上面那个「新建项目级 Shell 配置」建;非 Shell 类型与删 / 改,交给用户调 `idea-run-config-manager` skill。
 {{else}}
-- 要固化的固定流程:把配置名、实际执行的命令、工作目录、为什么值得留讲清楚,**请用户在 IDE 里自己建** —— 当前没有能建它的工具(`idea-run-config-manager` skill 的门就是这个工具,所以它这次也不会出现),不要手写文件凑。
+- 要固化的固定流程:把配置名、实际执行的命令、工作目录、为什么值得留讲清楚,**请用户在 IDE 里自己建** —— 当前没有能建它的工具(`idea-run-config-manager` skill 仍可加载,但缺这件工具时它也做不了新建),不要手写文件凑。
 {{/if}}
 - 不需要项目环境的命令:用原生 `shell`。

package/src/mcp/idea.js

@@ -127,7 +127,7 @@ export async function callTool(port, projectPath, name, args = {}, options = {})
       params: {
         protocolVersion: PROTOCOL_VERSION,
         capabilities: {},
-        clientInfo: { name: 'opencode-idea', version: '0.0.22' },
+        clientInfo: { name: 'opencode-idea', version: '0.0.23' },
       },
     });
     // The IDE's Streamable-HTTP endpoint binds follow-up requests to the session

package/src/plugin.js

@@ -564,8 +564,6 @@ export default {
     let commandRegistration;
     /** @type {{ dispose: () => Promise<void> | void } | undefined} */
     let skillRegistration;
-    /** Ids of the skills currently registered, so a sync can tell "unchanged". */
-    let registeredSkillIds = [];
     let disposed = false;
 
     // Latches when a request showed the IDE tools are gone. It is cleared
@@ -622,8 +620,6 @@ export default {
         // best effort
       }
       config = next;
-      // skill 生命周期跟随配置：配置在就注册 IDEA skill，删掉配置就移除。
-      await syncSkills();
     };
 
     /** 当前接入的全部项目（root 在前），每个带工具前缀与展示标签。 */
@@ -707,11 +703,7 @@ export default {
       // Without this, a session that already captured a snapshot keeps the old
       // tool list until the session is reopened.
       if (typeof ctx.tool?.reload === 'function') await ctx.tool.reload();
-      const ready = await waitForIdeTools();
-      // The catalog decides which of the shipped skills may be offered, so this
-      // is the first moment that question has an answer; see `syncSkills`.
-      await syncSkills();
-      return ready;
+      return await waitForIdeTools();
     };
 
     /**
@@ -1042,105 +1034,40 @@ export default {
       }
     };
 
-    /**
-     * The IDEA tools this project's IDE is serving right now.
-     *
-     * Empty is the honest answer for "does the IDE serve X?" before anything has
-     * connected — and it fails that way on error too, because the alternative
-     * (assuming a tool exists) is the one mistake that cannot be walked back
-     * after the model has seen it.
-     *
-     * @returns {Promise<Set<string>>}
-     */
-    const servedIdeaToolNames = async () => {
-      if (typeof ctx.tool?.list !== 'function') return new Set();
-      try {
-        return new Set(toolIds(await ctx.tool.list()));
-      } catch {
-        return new Set();
-      }
-    };
-
-    /** Same ids in the same order — `readSkills()` sorts, so the order is stable. */
-    const isSameSkillSet = (skills, ids) =>
-      skills.length === ids.length && skills.every((skill, index) => skill.id === ids[index]);
-
     // The shipped skills are static knowledge (`skills/<id>/SKILL.md`) that write
     // a project's own rules into its `AGENTS.md`: `idea-standalone` fixes how
     // resident apps are started, `idea-run-config-manager` fixes which repeated
-    // flows are solidified into configurations. They pass two independent gates,
-    // because a skill can be wrong twice over:
+    // flows are solidified into configurations.
+    //
+    // They are registered **once, when the plugin loads** — with no condition on
+    // the project config and none on the IDE's tool catalog. That is a deliberate
+    // reversal of the earlier design, which offered a skill only after the tools
+    // it drives were actually served. The gate looked right in isolation and was
+    // wrong in use: the client snapshots the skill list when the session starts,
+    // so anything registered later (by `/open-in-ide` finishing, or by a catalog
+    // refresh) stays invisible until the page is reloaded — the user reads that
+    // as "the skill is missing" while the registry already has it.
     //
-    //   * the project config — an unrelated project never sees an IDE skill;
-    //   * the tools the IDE actually serves — a skill that teaches a call the
-    //     model cannot make is not knowledge, it is a failed call waiting to
-    //     happen. Both skills drive tools that only the companion plugin
-    //     `idea-mcp-enhance` serves (rerun for standalone, create for the
-    //     manager), so a stock IDE must not see them at all. Each skill declares
-    //     its own dependency in its frontmatter (`requires:`), as a SUFFIX — tool
-    //     names carry a per-project prefix, so a hard-coded `idea_...` could only
-    //     ever match one project.
+    // What the old gate protected against is handled where it belongs: the skill
+    // text itself says what to do when a tool is absent ("hand it back to the
+    // user", "run /open-in-ide"). A missing tool is a fact the model can read and
+    // act on; an invisible skill is not.
     //
-    // The catalog is unknown at setup: the config is read from storage offline,
-    // before anything has connected to the IDE. So this is a reconcile rather
-    // than a one-shot — every catalog refresh re-runs it, and it offers exactly
-    // what is justified right now. Until the IDE has answered, the gated skills
-    // simply do not exist.
+    // The frontmatter `requires:` key is gone with the gate. It was this
+    // package's own metadata, never read by OpenCode, and keeping it after the
+    // gate disappeared would look like it still decided something.
     //
     // Deliberately NOT wrapped in a catch: these are core features of the plugin,
     // so a rejected definition must fail loudly. Swallowing it would ship a
     // silently incomplete plugin — which is exactly how 0.0.6 lost
     // `/open-in-ide` without anyone noticing until the command was gone.
-    const syncSkillsOnce = async () => {
+    const registerSkills = async () => {
       if (typeof ctx.skill?.transform !== 'function') return;
-
-      const served = await servedIdeaToolNames();
-      const wanted = (config ? readSkills() : [])
-        .filter(({ requires }) =>
-          requires.every((suffix) => prefixes().some((prefix) => served.has(`${prefix}${suffix}`))),
-        )
-        .map(({ skill }) => skill);
-      if (isSameSkillSet(wanted, registeredSkillIds)) return;
-
-      // Tear down and register again, the same way the MCP server is
-      // re-registered: a transform that only ever adds would leave a stale skill
-      // behind, and one that only removes could never bring it back.
-      registeredSkillIds = [];
-      const previous = skillRegistration;
-      skillRegistration = undefined;
-      if (previous) {
-        try {
-          await previous.dispose();
-        } catch {
-          // best effort
-        }
-      }
-      if (wanted.length === 0) return;
       skillRegistration = await ctx.skill.transform((editor) => {
-        for (const skill of wanted) editor.add(skill);
+        for (const { skill } of readSkills()) editor.add(skill);
       });
-      registeredSkillIds = wanted.map((skill) => skill.id);
-    };
-
-    // Serialized like the reconciler, and for the same reason: one call disposes
-    // a registration before it makes the next, so two overlapping calls would
-    // leak one of them. That overlap is easy to reach — `/delete-in-ide` can land
-    // while a reconnect is still in flight. With the chain in place, callers may
-    // fire this without awaiting.
-    let skillSyncChain = Promise.resolve();
-    const syncSkills = () => {
-      const run = () => syncSkillsOnce();
-      const next = skillSyncChain.then(run, run);
-      skillSyncChain = next.then(
-        () => {},
-        () => {},
-      );
-      return next;
     };
-    // A project configured in an earlier run gets its skills as soon as the IDE
-    // has answered; a project configured for the first time gets them when
-    // `/open-in-ide` runs (both paths go through `writeConfig` / this setup hook).
-    await syncSkills();
+    await registerSkills();
 
     /**
      * 问用户"这个项目用哪个 IDE"，由模型转达并回写。
@@ -1407,15 +1334,6 @@ export default {
         if (config || serving) {
           appendIdeRecoveryGuidance(event?.system, { marked: Boolean(config), serving });
         }
-        // A skill follows its tools in both directions, and this is the one place
-        // that sees the answer change WITHOUT a reconnect: a request that has
-        // lost the enhance tools must not keep the skill that drives them. Fired,
-        // not awaited — the hook is synchronous, and the chain in `syncSkills`
-        // makes that safe. `refreshIdeTools` covers the other direction.
-        //
-        // Skipped when there is nothing it could change, so a project that never
-        // touched the IDE does not pay a catalog read on every request.
-        if (config || registeredSkillIds.length > 0) void syncSkills();
         if (!injectGuidance) return;
         // Guidance promises tools the model can call, so it only goes out when
         // they are actually in this request.

package/src/skill/loader.js

@@ -22,11 +22,14 @@
 // The frontmatter reader below handles only the flat `key: value` form this
 // package writes. It is not a YAML engine and must not grow into one.
 //
-// One frontmatter key is the loader's own rather than OpenCode's: `requires`, a
-// comma-separated list of the tools the skill is written around. It is read here
-// and deliberately kept OUT of the registered definition — the caller filters on
-// it instead (see `readSkills`), because a skill whose tools are absent must not
-// be registered at all.
+// The skills used to carry a `requires:` key (the tools each one is written
+// around), and the plugin registered a skill only when those tools were being
+// served. That gate is gone, together with the key: skills are registered once,
+// when the plugin loads (see `plugin.js`), and a missing tool is handled inside
+// the skill text. Registering only after the tools appeared made the skill
+// invisible until the client reloaded the page. A key left behind would look
+// like it still decided something — it does not: OpenCode never reads it, and
+// nothing in this package does either.
 //
 // The other key is OpenCode's own, written in the portable frontmatter spelling
 // OpenCode documents: a nested `metadata:` block holding
@@ -80,20 +83,6 @@ export function parseSkillFrontmatter(text, source) {
   return fields;
 }
 
-/**
- * Split a frontmatter list value: `a, b` -> `['a', 'b']`.
- *
- * @param {string | undefined} value
- * @returns {string[]}
- */
-function splitList(value) {
-  if (!value) return [];
-  return value
-    .split(',')
-    .map((entry) => entry.trim())
-    .filter((entry) => entry !== '');
-}
-
 /**
  * Read `opencode/autoinvoke` out of the frontmatter, or `undefined` when absent.
  *
@@ -131,11 +120,10 @@ export function readSkill(id) {
 }
 
 /**
- * A skill plus the tools it needs before it is worth offering.
+ * One skill package.
  *
- * The two are kept apart on purpose: `skill` must satisfy `Skill.Info` exactly,
- * while `requires` is this package's own metadata and must NOT be registered —
- * it is what the caller filters on.
+ * `skill` must satisfy `Skill.Info` exactly — nothing of this package's own
+ * metadata rides along into the definition OpenCode validates.
  *
  * `autoinvoke` is OpenCode's, so it goes the other way: it ships in the
  * frontmatter as `opencode/autoinvoke` and is translated onto the definition,
@@ -143,7 +131,7 @@ export function readSkill(id) {
  * frontmatter asks for it, so a skill that says nothing keeps the plain shape.
  *
  * @param {string} id Directory name, used as the skill id.
- * @returns {{ skill: { id: string, name: string, description: string, autoinvoke?: boolean, path: string, content: string }, requires: string[] }}
+ * @returns {{ skill: { id: string, name: string, description: string, autoinvoke?: boolean, path: string, content: string } }}
  */
 export function readSkillPackage(id) {
   const file = new URL(`${id}/${SKILL_FILE_NAME}`, SKILLS_DIR);
@@ -164,14 +152,13 @@ export function readSkillPackage(id) {
       path: fileURLToPath(file),
       content: text.replace(FRONTMATTER, '').replace(/^\s+/, '').trimEnd(),
     },
-    requires: splitList(fields.requires),
   };
 }
 
 /**
- * Every shipped skill, sorted by id, each with the tools it requires.
+ * Every shipped skill, sorted by id.
  *
- * @returns {Array<{ skill: { id: string, name: string, description: string, autoinvoke?: boolean, path: string, content: string }, requires: string[] }>}
+ * @returns {Array<{ skill: { id: string, name: string, description: string, autoinvoke?: boolean, path: string, content: string } }>}
  */
 export function readSkills() {
   return readdirSync(SKILLS_DIR, { withFileTypes: true })