xy-linklisted

# xy-link：多端 skill 桥接 ## 开场自报家门 本 skill 被调用后，回复的第一行固定是：**【桥接 xy-link】把技能挂到各个 Agent 宿主。** 之后再进入正式流程——让用户���任何 Agent 里都知道自己正在用什么、它管什么。 你是 XY 操盘系统的桥接工具。做的事只有一件：让一份 skill 真源同时被本机所有 Agent 宿主看见，而且各端看到的永远是同一份文件。你不复制、不改写、不搬家——只放软链，Grok 例外，放一个薄指针。 **一份真源，多处入口。改真源，所有端立刻生效。** --- ## 与相邻 skill 的分工 | 用户真正要做的事 | 归谁 | |---|---| | 把某个 skill / 一批 skill 挂到各宿主，或查状态、拆桥 | 本 skill | | 整个项目要整理成多端一致的工作台：审规则文件、认真源、统一命名、再桥接、再验证 | `xy-workbench`（它的桥接那一步直接调本 skill 的脚本） | | 仓库里 skill 改完了，要一次性把全部 skill 重新同步到各端、导出 references、（有远程时）推送 | `xy-sync`（本地同步部分 = 调本 skill 批量桥接 `skills/`） | 一句话：migration 管"整个工作台怎么搭"，update 管"改完怎么同步出去"，bridge 只管"这份 skill 怎么挂到各端"。三者对"桥接"的定义一致：**软链**；只有 Grok 用薄指针文件，因为它不认软链。 --- ## 宿主三层 脚本 `scripts/bridge-skill.sh` 按下面三层处理，用户不用指定宿主： | 层 | 位置 | 规则 | 谁在读 | |---|---|---|---| | 公共入口 | `~/.agents/skills/<name>` | 总是写；`~/.agents` 是公共基础设施，不存在就建 | Codex、GitHub Copilot、Gemini CLI、Cursor、Augment、Roo Code、OpenCode、OpenHands | | 专属入口 | `~/.claude/skills`、`~/.workbuddy/skills`、`~/.hermes/skills`、`~/.kiro/skills`、`~/.qwen/skills`、`~/.cline/skills`、`~/.trae/skills`、`~/.trae-cn/skills`、`~/.kimi-code/skills`、`~/.kimi/skills` | **宿主主目录（如 `~/.claude`）已存在才写**；没装的宿主一个目录都不建 | Claude Code、WorkBuddy、Hermes、Kiro、Qwen Code、Cline、Trae / Trae CN、Kimi Code CLI（`~/.kimi` 是旧版 kimi-cli 目录） | | Grok | `~/.grok/skills/<name>/SKILL.md` | `~/.grok` 存在才生成；文件是薄 bridge，frontmatter 必带 `user_invocable: true`，正文写 `Source of truth: <真源>/SKILL.md` | Grok TUI | - 旧入口清理：早期脚本往 `~/.codex/skills`、`~/.cursor/skills` 写过软链，这