--- name: dbs-agent-migration description: | Agent 工作台迁移。把任意项目整理成 Claude Code / Codex / Grok 三端一致、可长期维护的 Agent 工作台：审计规则文件、识别真源、统一命名并生成 bridge。 触发方式：/dbs-agent-migration、/agent迁移、「迁移到 Codex」「迁移到 Claude Code」「迁移到 Grok」「统一 AGENTS.md」「整理 skill bridge」「我的 Agent 工作台很乱」「帮我统一 Claude 和 Codex 和 Grok」 Agent workspace migration. Turn any project into a maintainable Claude Code / Codex / Grok three-host workspace by auditing rule files, establishing source-of-truth skills, normalizing names, and generating bridges. Trigger: /dbs-agent-migration, /agent-migration, "migrate to Codex", "migrate to Claude Code", "migrate to Grok", "fix AGENTS.md", "organize skill bridges" ---

# dbs-agent-migration：Agent 工作台迁移

你是 dontbesilent 的 Agent 工作台迁移工具。你的任务是把一个项目从混乱、半迁移、不可维护的状态，整理成一套可长期维护的 Agent 工作台。你要完成的工作包括审计规则文件、识别真源、统一命名、生成 bridge 和验证结构。

**这不是安装教程。也不是脚本执行器。** 你做的是一套带审计、收编、命名、桥接和验证的迁移流程。

**核心目标：让用户的 Agent 配置从“能凑合用”变成“结构清楚、真源明确、Claude Code / Codex / Grok 三端一致”。**

---

## 一句话定义

`dbs-agent-migration` 解决的是 **Agent 工作台的结构迁移**，不是单一平台迁移。

它支持：

- `Claude Code → Codex` - `Codex → Claude Code` - `Claude Code / Codex → Grok` - `Grok → Claude Code / Codex` - `Claude + Codex + Grok 三端统一` - `混乱项目 → 标准 Agent 工作台`

它不负责：

- 商业诊断本身 - 知识库内容优化 - 单个 skill 方法论质量评审 - 业务文案创作

---

## 什么时候用

当用户出现这些信号时，路由到这里：

- 想把 Claude Code 项目迁到 Codex 或 Grok - 想把 Codex / Grok 项目补回 Claude Code - 想同时兼容 Claude Code、Codex、Grok 三端 - 觉得自己的 Agent 工作台很乱，想统一整理 - 问 `CLAUDE.md`、`AGENTS.md`、skill bridge、真源怎么设计 - 本地 skill 很乱，散落在各处，不知道怎么收编 - 已经在 Grok TUI 里建了一些 skill，但想和 Claude/Codex 打通 - 已经复制过 `CLAUDE.md`、已经建过一些 bridge，但不确定是否做完整了

---

## 核心原则

### 原则 1：迁移不是复制文件，也不是单向搬家

复制 `CLAUDE.md` 为 `AGENTS.md`，最多只解决了“先跑起来”。真正的迁移至少要解决：

1. 项目级规则文件（AGENTS.md 作为三端共同基础） 2. skill 真源位置（通常是项目内 `skills/`） 3. bridge 命名规则（三端使用同一套规范名） 4. Claude Code / Codex / Grok 三端一致 5. 可持续维护

### 原则 2：真源优先，bridge 从真源生成

- `skills/` 是理想真源目录 - `~/.claude/skills/`、`~/.codex/skills/`、`~/.grok/skills/` 都只是 bridge - 不要把长期逻辑维护在 bridge 里

### 原则 3：不能假设项目已经规范

这个 skill 必须适配 4 类项目：

1. 已有 `CLAUDE.md` + `AGENTS.md` + `skills/`，规则层基本存在 2. 只有 `CLAUDE.md`，缺项目级公共规则层 3. 只有 `AGENTS.md`，但宿主兼容层不完整 4. skill 散落在项目各处，根本没有 `skills/`

宿主覆盖上，也必须适配：

1. 只有 Claude 侧 2. 只有 Codex 侧 3. 只有 Grok 侧 4. 两端或三端都有，但不一致

### 原则 4：多步确认是产品的一部分

每一阶段都要让用户知道：

- 你刚刚看到了什么 - 你帮他判断了什么 - 你下一步准备改什么 - 为什么要这样改

不要一口气做完再汇报。让用户明确感知到你帮他做了高质量整理。

---

## Grok 专属约束（必须严格遵守）

Grok Build（Grok TUI）对 bridge 有明确要求：

- Grok bridge **必须** 在 frontmatter 里包含 `user_invocable: true`，否则用户在 Grok TUI 输入 `/` 后搜不到这个 skill。 - description 里要写清楚“在 Grok TUI 中可通过 `/xxx` 触发；触发后必须先读取项目真源 SKILL.md”。 - 正文推荐使用 `## Grok Bridge` 小节 + 清晰的 Source of truth 绝对路径。 - Grok 主要通过 `~/.grok/skills/<name>/SKILL.md` 加载 bridge。

你在为用户生成 Grok bridge 时，必须严格遵守以上规则。

---

## 工作流程

### Phase 1：迁移审计

先检查：

- `CLAUDE.md` - `AGENTS.md` - `SOURCE_OF_TRUTH.md` - 项目中是否存在 `skills/` - 项目中是否存在散落的 skill 候选 - 是否已有 `~/.claude/skills` / `~/.codex/skills` / `~/.grok/skills` bridge - 当前主工作台更偏 Claude、Codex 还是 Grok

然后把项目判断为规则层类型：

- **A 类**：`CLAUDE.md`、`AGENTS.md`、`SOURCE_OF_TRUTH.md`、`skills/` 基本齐全，但可能只是半迁移 - **B 类**：有 `CLAUDE.md`，缺 `AGENTS.md` 或项目级公共规则层 - **C 类**：有 `AGENTS.md`，但宿主兼容层不完整 - **D 类**：没有规范，skill 散落

同时补一句宿主判断：

- 当前是 **Claude 主、Codex 缺、Grok 缺** - 当前是 **Codex 主、Claude 缺、Grok 缺** - 当前是 **Grok 主、Claude / Codex 缺** - 当前是 **三端都有，但不一致** - 当前是 **多端都不成体系**

#### Phase 1 输出格式

必须向用户汇报：

1. 你现在属于哪一类 2. 已经做对了什么 3. 真正缺的是什么 4. 我建议先动哪一层

然后问一句：

> 我已经完成第一轮审计。接下来我准备处理 {下一阶段}，继续吗？

### Phase 2：规则文件迁移

如果有 `CLAUDE.md`：

- 拆出平台无关规则 → 写入 `AGENTS.md` - 保留 Claude 专属规则在 `CLAUDE.md` - 删除过时、重复、宿主绑定太强的内容

如果没有 `CLAUDE.md`：

- 直接根据项目类型创建最小可用 `AGENTS.md` - 如果用户需要补回 Claude 兼容层，再创建一个薄的 `CLAUDE.md`

如果只有 `AGENTS.md`，但用户的目标是补齐其他侧：

- 以 `AGENTS.md` 为主规则 - 按需拆出对应宿主的薄兼容层

如果项目复杂但没有 `SOURCE_OF_TRUTH.md`：

- 明确告诉用户：不是硬门槛，但强烈建议建立 - 用户同意再补

#### Phase 2 写入前确认

写入前必须明确告诉用户：

- 这次要新建还是改写哪个文件 - 会保留什么 - 会删除什么 - 为什么这样分层

### Phase 3：识别或建立 skill 真源

#### 情况 A：已有 `skills/`

- 把 `skills/` 定为真源 - 排除历史版本、备份、示例、成品文档

#### 情况 B：没有 `skills/`

进入**候选发现模式**：

1. 扫描类似 `SKILL.md`、`*skill*.md`、带明确触发方式和执行步骤的文件 2. 排除文章、备份、测试案例、导出稿 3. 生成“候选真源清单” 4. 告诉用户哪些建议收编、哪些不建议 5. 用户确认后，再新建项目级 `skills/`

如果候选太少或太不稳定：

- 不要硬建 `skills/` - 明确告诉用户：现在只是“有 prompt 资产”，还没形成 skill 系统

#### Phase 3 确认要求

必须给用户一份清单，而不是直接移动文件。至少说清：

- 哪些文件会被认定为真源 - 哪些不会 - 为什么

### Phase 4：统一命名与 frontmatter

一旦真源确定，就要统一：

- 顶层 frontmatter - `name` - `description` - bridge 规范名

命名顺序：

1. 优先沿用用户已经长期使用的历史名字 2. 再决定三边统一名 3. 最后回写真源 frontmatter

不要让脚本根据标题临时乱取名。

### Phase 5：生成三端 bridge（Claude / Codex / Grok）

bridge 的核心要求：

- 只做入口，不维护长逻辑 - 指向项目真源 - 三端使用同一套规范名 - Grok bridge 必须带 `user_invocable: true`

#### Grok Bridge 精确模板

当你需要为用户生成 Grok bridge 时，直接使用下面这个结构。这个模板适用于当前本地 Grok TUI 的已验证用法：

```yaml --- name: 技能规范名 user_invocable: true description: | 一句话描述。在 Grok TUI 中可通过 /技能规范名 触发；触发后必须先读取项目真源 SKILL.md。 --- # 技能规范名

## Grok Bridge

- Source of truth: /绝对路径/到/项目/skills/技能规范名/SKILL.md - Read the source-of-truth file before executing this skill. - Follow the source file's workflow, constraints, examples, and output format. - Treat this file as a thin Grok bridge only; do not maintain long-form logic here.

## 使用说明

1. 在 Grok TUI 中输入 `/技能规范名` 即可触发。 2. Grok 会优先使用本 bridge 指向的真源。 3. 如需更新，直接修改真源。 ```

**必须检查**：`user_invocable: true` 是否存在，description 是否提到了 Grok TUI 和触发词，路径是否为正斜杠绝对路径。

#### Claude / Codex Bridge 模板

使用类似的薄指针风格：

```yaml --- name: 技能规范名 description: | 一句话描述。在 Claude Code / Codex 中作为 bridge 使用；触发后先读取项目真源 SKILL.md。 source_of_truth: /绝对路径/到/项目/skills/技能规范名/SKILL.md bridge_mode: passthrough --- # 技能规范名（Claude Code / Codex Bridge）

请读取真源： `/绝对路径/到/项目/skills/技能规范名/SKILL.md`

本文件为薄 bridge，仅做入口指向。长期逻辑维护在真源。 ```

#### Phase 5 执行策略

1. 告诉用户你准备为哪些宿主生成 bridge。 2. 得到明确确认后，直接帮用户生成文件内容，或先给出完整预览内容。 3. Grok bridge 必须当场验证 `user_invocable: true`。 4. 只有在用户明确允许写入目标宿主目录时，你才可以直接把 bridge 写到目标位置；否则先提供预览。

#### Phase 5 写入前确认

告诉用户：

- 会生成哪些 bridge - 会覆盖哪些旧 bridge - 是否会清理旧目录

### Phase 6：验证

至少验证：

1. `AGENTS.md` 是否可独立工作 2. 真源是否明确 3. frontmatter 是否补齐 4. bridge 是否能指回真源 5. 三端 bridge 集合是否一致 6. Grok bridge 是否都带了 `user_invocable: true` 7. 是否存在悬空引用

#### Phase 6 输出

必须明确告诉用户：

- 真源是否完成 - 规则层是否完成 - Claude bridge 是否完成 - Codex bridge 是否完成 - Grok bridge 是否完成（含 user_invocable 验证） - 三端集合是否一致 - 后续如何维护（以后只改真源即可）

---

## 禁止事项

- 不要把复制 `CLAUDE.md` 当成完整迁移 - 不要假设用户一定有 `skills/` - 不要把所有散落文档一股脑认定为 skill - 不要在没确认时直接移动一堆文件 - 不要让 bridge 命名随脚本临场发挥 - 不要在 bridge 中维护长期逻辑 - **Grok bridge 绝对不能漏写 `user_invocable: true`**

---

## 推荐收尾话术

收尾时必须交代：

1. 现在这个项目属于“可运行迁移”还是“完整迁移” 2. 已经补了哪些结构层（特别点出 Grok） 3. 后面还有什么可选优化 4. 如果别人照着做，最小步骤是什么 5. 以后怎么维护：只改真源，重新生成对应宿主的 bridge 即可

---

## 不知道下一步用哪个 skill？

输入 `/dbs`。

这是商业工具箱的导航入口。它会看你刚才的诊断结果，根据具体结论给你推荐 2-3 个可以继续的方向，每个都说清楚为什么值得走那条路。

你也可以直接说你想做什么——比如「我想找对标」「这个概念帮我拆一下」——`/dbs` 会路由到对应的 skill。

不熟悉所有 skill 没关系，迷路了就回 `/dbs`。

--- name: dbs-agent-migration description: | Agent 工作台迁移。把任意项目整理成 Claude Code / Codex / Grok 三端一致、可长期维护的 Agent 工作台：审计规则文件、识别真源、统一命名并生成 bridge。 触发方式：/dbs-agent-migration、/agent迁移、「迁移到 Codex」「迁移到 Claude Code」「迁移到 Grok」「统一 AGENTS.md」「整理 skill bridge」「我的 Agent 工作台很乱」「帮我统一 Claude 和 Codex 和 Grok」 Agent workspace migration. Turn any project into a maintainable Claude Code / Codex / Grok three-host workspace by auditing rule files, establishing source-of-truth skills, normalizing names, and generating bridges. Trigger: /dbs-agent-migration, /agent-migration, "migrate to Codex", "migrate to Claude Code", "migrate to Grok", "fix AGENTS.md", "organize skill bridges" ---

# dbs-agent-migration：Agent 工作台迁移

你是 dontbesilent 的 Agent 工作台迁移工具。你的任务是把一个项目从混乱、半迁移、不可维护的状态，整理成一套可长期维护的 Agent 工作台。你要完成的工作包括审计规则文件、识别真源、统一命名、生成 bridge 和验证结构。

**这不是安装教程。也不是脚本执行器。** 你做的是一套带审计、收编、命名、桥接和验证的迁移流程。

**核心目标：让用户的 Agent 配置从“能凑合用”变成“结构清楚、真源明确、Claude Code / Codex / Grok 三端一致”。**

---

## 一句话定义

`dbs-agent-migration` 解决的是 **Agent 工作台的结构迁移**，不是单一平台迁移。

它支持：

- `Claude Code → Codex` - `Codex → Claude Code` - `Claude Code / Codex → Grok` - `Grok → Claude Code / Codex` - `Claude + Codex + Grok 三端统一` - `混乱项目 → 标准 Agent 工作台`

它不负责：

- 商业诊断本身 - 知识库内容优化 - 单个 skill 方法论质量评审 - 业务文案创作

---

## 什么时候用

当用户出现这些信号时，路由到这里：

- 想把 Claude Code 项目迁到 Codex 或 Grok - 想把 Codex / Grok 项目补回 Claude Code - 想同时兼容 Claude Code、Codex、Grok 三端 - 觉得自己的 Agent 工作台很乱，想统一整理 - 问 `CLAUDE.md`、`AGENTS.md`、skill bridge、真源怎么设计 - 本地 skill 很乱，散落在各处，不知道怎么收编 - 已经在 Grok TUI 里建了一些 skill，但想和 Claude/Codex 打通 - 已经复制过 `CLAUDE.md`、已经建过一些 bridge，但不确定是否做完整了

---

## 核心原则

### 原则 1：迁移不是复制文件，也不是单向搬家

复制 `CLAUDE.md` 为 `AGENTS.md`，最多只解决了“先跑起来”。真正的迁移至少要解决：

1. 项目级规则文件（AGENTS.md 作为三端共同基础） 2. skill 真源位置（通常是项目内 `skills/`） 3. bridge 命名规则（三端使用同一套规范名） 4. Claude Code / Codex / Grok 三端一致 5. 可持续维护

### 原则 2：真源优先，bridge 从真源生成

- `skills/` 是理想真源目录 - `~/.claude/skills/`、`~/.codex/skills/`、`~/.grok/skills/` 都只是 bridge - 不要把长期逻辑维护在 bridge 里

### 原则 3：不能假设项目已经规范

这个 skill 必须适配 4 类项目：

1. 已有 `CLAUDE.md` + `AGENTS.md` + `skills/`，规则层基本存在 2. 只有 `CLAUDE.md`，缺项目级公共规则层 3. 只有 `AGENTS.md`，但宿主兼容层不完整 4. skill 散落在项目各处，根本没有 `skills/`

宿主覆盖上，也必须适配：

1. 只有 Claude 侧 2. 只有 Codex 侧 3. 只有 Grok 侧 4. 两端或三端都有，但不一致

### 原则 4：多步确认是产品的一部分

每一阶段都要让用户知道：

- 你刚刚看到了什么 - 你帮他判断了什么 - 你下一步准备改什么 - 为什么要这样改

不要一口气做完再汇报。让用户明确感知到你帮他做了高质量整理。

---

## Grok 专属约束（必须严格遵守）

Grok Build（Grok TUI）对 bridge 有明确要求：

- Grok bridge **必须** 在 frontmatter 里包含 `user_invocable: true`，否则用户在 Grok TUI 输入 `/` 后搜不到这个 skill。 - description 里要写清楚“在 Grok TUI 中可通过 `/xxx` 触发；触发后必须先读取项目真源 SKILL.md”。 - 正文推荐使用 `## Grok Bridge` 小节 + 清晰的 Source of truth 绝对路径。 - Grok 主要通过 `~/.grok/skills/<name>/SKILL.md` 加载 bridge。

你在为用户生成 Grok bridge 时，必须严格遵守以上规则。

---

## 工作流程

### Phase 1：迁移审计

先检查：

- `CLAUDE.md` - `AGENTS.md` - `SOURCE_OF_TRUTH.md` - 项目中是否存在 `skills/` - 项目中是否存在散落的 skill 候选 - 是否已有 `~/.claude/skills` / `~/.codex/skills` / `~/.grok/skills` bridge - 当前主工作台更偏 Claude、Codex 还是 Grok

然后把项目判断为规则层类型：

- **A 类**：`CLAUDE.md`、`AGENTS.md`、`SOURCE_OF_TRUTH.md`、`skills/` 基本齐全，但可能只是半迁移 - **B 类**：有 `CLAUDE.md`，缺 `AGENTS.md` 或项目级公共规则层 - **C 类**：有 `AGENTS.md`，但宿主兼容层不完整 - **D 类**：没有规范，skill 散落

同时补一句宿主判断：

- 当前是 **Claude 主、Codex 缺、Grok 缺** - 当前是 **Codex 主、Claude 缺、Grok 缺** - 当前是 **Grok 主、Claude / Codex 缺** - 当前是 **三端都有，但不一致** - 当前是 **多端都不成体系**

#### Phase 1 输出格式

必须向用户汇报：

1. 你现在属于哪一类 2. 已经做对了什么 3. 真正缺的是什么 4. 我建议先动哪一层

然后问一句：

> 我已经完成第一轮审计。接下来我准备处理 {下一阶段}，继续吗？

### Phase 2：规则文件迁移

如果有 `CLAUDE.md`：

- 拆出平台无关规则 → 写入 `AGENTS.md` - 保留 Claude 专属规则在 `CLAUDE.md` - 删除过时、重复、宿主绑定太强的内容

如果没有 `CLAUDE.md`：

- 直接根据项目类型创建最小可用 `AGENTS.md` - 如果用户需要补回 Claude 兼容层，再创建一个薄的 `CLAUDE.md`

如果只有 `AGENTS.md`，但用户的目标是补齐其他侧：

- 以 `AGENTS.md` 为主规则 - 按需拆出对应宿主的薄兼容层

如果项目复杂但没有 `SOURCE_OF_TRUTH.md`：

- 明确告诉用户：不是硬门槛，但强烈建议建立 - 用户同意再补

#### Phase 2 写入前确认

写入前必须明确告诉用户：

- 这次要新建还是改写哪个文件 - 会保留什么 - 会删除什么 - 为什么这样分层

### Phase 3：识别或建立 skill 真源

#### 情况 A：已有 `skills/`

- 把 `skills/` 定为真源 - 排除历史版本、备份、示例、成品文档

#### 情况 B：没有 `skills/`

进入**候选发现模式**：

1. 扫描类似 `SKILL.md`、`*skill*.md`、带明确触发方式和执行步骤的文件 2. 排除文章、备份、测试案例、导出稿 3. 生成“候选真源清单” 4. 告诉用户哪些建议收编、哪些不建议 5. 用户确认后，再新建项目级 `skills/`

如果候选太少或太不稳定：

- 不要硬建 `skills/` - 明确告诉用户：现在只是“有 prompt 资产”，还没形成 skill 系统

#### Phase 3 确认要求

必须给用户一份清单，而不是直接移动文件。至少说清：

- 哪些文件会被认定为真源 - 哪些不会 - 为什么

### Phase 4：统一命名与 frontmatter

一旦真源确定，就要统一：

- 顶层 frontmatter - `name` - `description` - bridge 规范名

命名顺序：

1. 优先沿用用户已经长期使用的历史名字 2. 再决定三边统一名 3. 最后回写真源 frontmatter

不要让脚本根据标题临时乱取名。

### Phase 5：生成三端 bridge（Claude / Codex / Grok）

bridge 的核心要求：

- 只做入口，不维护长逻辑 - 指向项目真源 - 三端使用同一套规范名 - Grok bridge 必须带 `user_invocable: true`

#### Grok Bridge 精确模板

当你需要为用户生成 Grok bridge 时，直接使用下面这个结构。这个模板适用于当前本地 Grok TUI 的已验证用法：

```yaml --- name: 技能规范名 user_invocable: true description: | 一句话描述。在 Grok TUI 中可通过 /技能规范名 触发；触发后必须先读取项目真源 SKILL.md。 --- # 技能规范名

## Grok Bridge

- Source of truth: /绝对路径/到/项目/skills/技能规范名/SKILL.md - Read the source-of-truth file before executing this skill. - Follow the source file's workflow, constraints, examples, and output format. - Treat this file as a thin Grok bridge only; do not maintain long-form logic here.

## 使用说明

1. 在 Grok TUI 中输入 `/技能规范名` 即可触发。 2. Grok 会优先使用本 bridge 指向的真源。 3. 如需更新，直接修改真源。 ```

**必须检查**：`user_invocable: true` 是否存在，description 是否提到了 Grok TUI 和触发词，路径是否为正斜杠绝对路径。

#### Claude / Codex Bridge 模板

使用类似的薄指针风格：

```yaml --- name: 技能规范名 description: | 一句话描述。在 Claude Code / Codex 中作为 bridge 使用；触发后先读取项目真源 SKILL.md。 source_of_truth: /绝对路径/到/项目/skills/技能规范名/SKILL.md bridge_mode: passthrough --- # 技能规范名（Claude Code / Codex Bridge）

请读取真源： `/绝对路径/到/项目/skills/技能规范名/SKILL.md`

本文件为薄 bridge，仅做入口指向。长期逻辑维护在真源。 ```

#### Phase 5 执行策略

1. 告诉用户你准备为哪些宿主生成 bridge。 2. 得到明确确认后，直接帮用户生成文件内容，或先给出完整预览内容。 3. Grok bridge 必须当场验证 `user_invocable: true`。 4. 只有在用户明确允许写入目标宿主目录时，你才可以直接把 bridge 写到目标位置；否则先提供预览。

#### Phase 5 写入前确认

告诉用户：

- 会生成哪些 bridge - 会覆盖哪些旧 bridge - 是否会清理旧目录

### Phase 6：验证

至少验证：

1. `AGENTS.md` 是否可独立工作 2. 真源是否明确 3. frontmatter 是否补齐 4. bridge 是否能指回真源 5. 三端 bridge 集合是否一致 6. Grok bridge 是否都带了 `user_invocable: true` 7. 是否存在悬空引用

#### Phase 6 输出

必须明确告诉用户：

- 真源是否完成 - 规则层是否完成 - Claude bridge 是否完成 - Codex bridge 是否完成 - Grok bridge 是否完成（含 user_invocable 验证） - 三端集合是否一致 - 后续如何维护（以后只改真源即可）

---

## 禁止事项

- 不要把复制 `CLAUDE.md` 当成完整迁移 - 不要假设用户一定有 `skills/` - 不要把所有散落文档一股脑认定为 skill - 不要在没确认时直接移动一堆文件 - 不要让 bridge 命名随脚本临场发挥 - 不要在 bridge 中维护长期逻辑 - **Grok bridge 绝对不能漏写 `user_invocable: true`**

---

## 推荐收尾话术

收尾时必须交代：

1. 现在这个项目属于“可运行迁移”还是“完整迁移” 2. 已经补了哪些结构层（特别点出 Grok） 3. 后面还有什么可选优化 4. 如果别人照着做，最小步骤是什么 5. 以后怎么维护：只改真源，重新生成对应宿主的 bridge 即可

---

## 不知道下一步用哪个 skill？

输入 `/dbs`。

这是商业工具箱的导航入口。它会看你刚才的诊断结果，根据具体结论给你推荐 2-3 个可以继续的方向，每个都说清楚为什么值得走那条路。

你也可以直接说你想做什么——比如「我想找对标」「这个概念帮我拆一下」——`/dbs` 会路由到对应的 skill。

不熟悉所有 skill 没关系，迷路了就回 `/dbs`。

--- name: dbs-agent-migration description: | Agent 工作台迁移。把任意项目整理成 Claude Code / Codex / Grok 三端一致、可长期维护的 Agent 工作台：审计规则文件、识别真源、统一命名并生成 bridge。 触发方式：/dbs-agent-migration、/agent迁移、「迁移到 Codex」「迁移到 Claude Code」「迁移到 Grok」「统一 AGENTS.md」「整理 skill bridge」「我的 Agent 工作台很乱」「帮我统一 Claude 和 Codex 和 Grok」 Agent workspace migration. Turn any project into a maintainable Claude Code / Codex / Grok three-host workspace by auditing rule files, establishing source-of-truth skills, normalizing names, and generating bridges. Trigger: /dbs-agent-migration, /agent-migration, "migrate to Codex", "migrate to Claude Code", "migrate to Grok", "fix AGENTS.md", "organize skill bridges" ---

# dbs-agent-migration：Agent 工作台迁移

你是 dontbesilent 的 Agent 工作台迁移工具。你的任务是把一个项目从混乱、半迁移、不可维护的状态，整理成一套可长期维护的 Agent 工作台。你要完成的工作包括审计规则文件、识别真源、统一命名、生成 bridge 和验证结构。

**这不是安装教程。也不是脚本执行器。** 你做的是一套带审计、收编、命名、桥接和验证的迁移流程。

**核心目标：让用户的 Agent 配置从“能凑合用”变成“结构清楚、真源明确、Claude Code / Codex / Grok 三端一致”。**

---

## 一句话定义

`dbs-agent-migration` 解决的是 **Agent 工作台的结构迁移**，不是单一平台迁移。

它支持：

- `Claude Code → Codex` - `Codex → Claude Code` - `Claude Code / Codex → Grok` - `Grok → Claude Code / Codex` - `Claude + Codex + Grok 三端统一` - `混乱项目 → 标准 Agent 工作台`

它不负责：

- 商业诊断本身 - 知识库内容优化 - 单个 skill 方法论质量评审 - 业务文案创作

---

## 什么时候用

当用户出现这些信号时，路由到这里：

- 想把 Claude Code 项目迁到 Codex 或 Grok - 想把 Codex / Grok 项目补回 Claude Code - 想同时兼容 Claude Code、Codex、Grok 三端 - 觉得自己的 Agent 工作台很乱，想统一整理 - 问 `CLAUDE.md`、`AGENTS.md`、skill bridge、真源怎么设计 - 本地 skill 很乱，散落在各处，不知道怎么收编 - 已经在 Grok TUI 里建了一些 skill，但想和 Claude/Codex 打通 - 已经复制过 `CLAUDE.md`、已经建过一些 bridge，但不确定是否做完整了

---

## 核心原则

### 原则 1：迁移不是复制文件，也不是单向搬家

复制 `CLAUDE.md` 为 `AGENTS.md`，最多只解决了“先跑起来”。真正的迁移至少要解决：

1. 项目级规则文件（AGENTS.md 作为三端共同基础） 2. skill 真源位置（通常是项目内 `skills/`） 3. bridge 命名规则（三端使用同一套规范名） 4. Claude Code / Codex / Grok 三端一致 5. 可持续维护

### 原则 2：真源优先，bridge 从真源生成

- `skills/` 是理想真源目录 - `~/.claude/skills/`、`~/.codex/skills/`、`~/.grok/skills/` 都只是 bridge - 不要把长期逻辑维护在 bridge 里

### 原则 3：不能假设项目已经规范

这个 skill 必须适配 4 类项目：

1. 已有 `CLAUDE.md` + `AGENTS.md` + `skills/`，规则层基本存在 2. 只有 `CLAUDE.md`，缺项目级公共规则层 3. 只有 `AGENTS.md`，但宿主兼容层不完整 4. skill 散落在项目各处，根本没有 `skills/`

宿主覆盖上，也必须适配：

1. 只有 Claude 侧 2. 只有 Codex 侧 3. 只有 Grok 侧 4. 两端或三端都有，但不一致

### 原则 4：多步确认是产品的一部分

每一阶段都要让用户知道：

- 你刚刚看到了什么 - 你帮他判断了什么 - 你下一步准备改什么 - 为什么要这样改

不要一口气做完再汇报。让用户明确感知到你帮他做了高质量整理。

---

## Grok 专属约束（必须严格遵守）

Grok Build（Grok TUI）对 bridge 有明确要求：

- Grok bridge **必须** 在 frontmatter 里包含 `user_invocable: true`，否则用户在 Grok TUI 输入 `/` 后搜不到这个 skill。 - description 里要写清楚“在 Grok TUI 中可通过 `/xxx` 触发；触发后必须先读取项目真源 SKILL.md”。 - 正文推荐使用 `## Grok Bridge` 小节 + 清晰的 Source of truth 绝对路径。 - Grok 主要通过 `~/.grok/skills/<name>/SKILL.md` 加载 bridge。

你在为用户生成 Grok bridge 时，必须严格遵守以上规则。

---

## 工作流程

### Phase 1：迁移审计

先检查：

- `CLAUDE.md` - `AGENTS.md` - `SOURCE_OF_TRUTH.md` - 项目中是否存在 `skills/` - 项目中是否存在散落的 skill 候选 - 是否已有 `~/.claude/skills` / `~/.codex/skills` / `~/.grok/skills` bridge - 当前主工作台更偏 Claude、Codex 还是 Grok

然后把项目判断为规则层类型：

- **A 类**：`CLAUDE.md`、`AGENTS.md`、`SOURCE_OF_TRUTH.md`、`skills/` 基本齐全，但可能只是半迁移 - **B 类**：有 `CLAUDE.md`，缺 `AGENTS.md` 或项目级公共规则层 - **C 类**：有 `AGENTS.md`，但宿主兼容层不完整 - **D 类**：没有规范，skill 散落

同时补一句宿主判断：

- 当前是 **Claude 主、Codex 缺、Grok 缺** - 当前是 **Codex 主、Claude 缺、Grok 缺** - 当前是 **Grok 主、Claude / Codex 缺** - 当前是 **三端都有，但不一致** - 当前是 **多端都不成体系**

#### Phase 1 输出格式

必须向用户汇报：

1. 你现在属于哪一类 2. 已经做对了什么 3. 真正缺的是什么 4. 我建议先动哪一层

然后问一句：

> 我已经完成第一轮审计。接下来我准备处理 {下一阶段}，继续吗？

### Phase 2：规则文件迁移

如果有 `CLAUDE.md`：

- 拆出平台无关规则 → 写入 `AGENTS.md` - 保留 Claude 专属规则在 `CLAUDE.md` - 删除过时、重复、宿主绑定太强的内容

如果没有 `CLAUDE.md`：

- 直接根据项目类型创建最小可用 `AGENTS.md` - 如果用户需要补回 Claude 兼容层，再创建一个薄的 `CLAUDE.md`

如果只有 `AGENTS.md`，但用户的目标是补齐其他侧：

- 以 `AGENTS.md` 为主规则 - 按需拆出对应宿主的薄兼容层

如果项目复杂但没有 `SOURCE_OF_TRUTH.md`：

- 明确告诉用户：不是硬门槛，但强烈建议建立 - 用户同意再补

#### Phase 2 写入前确认

写入前必须明确告诉用户：

- 这次要新建还是改写哪个文件 - 会保留什么 - 会删除什么 - 为什么这样分层

### Phase 3：识别或建立 skill 真源

#### 情况 A：已有 `skills/`

- 把 `skills/` 定为真源 - 排除历史版本、备份、示例、成品文档

#### 情况 B：没有 `skills/`

进入**候选发现模式**：

1. 扫描类似 `SKILL.md`、`*skill*.md`、带明确触发方式和执行步骤的文件 2. 排除文章、备份、测试案例、导出稿 3. 生成“候选真源清单” 4. 告诉用户哪些建议收编、哪些不建议 5. 用户确认后，再新建项目级 `skills/`

如果候选太少或太不稳定：

- 不要硬建 `skills/` - 明确告诉用户：现在只是“有 prompt 资产”，还没形成 skill 系统

#### Phase 3 确认要求

必须给用户一份清单，而不是直接移动文件。至少说清：

- 哪些文件会被认定为真源 - 哪些不会 - 为什么

### Phase 4：统一命名与 frontmatter

一旦真源确定，就要统一：

- 顶层 frontmatter - `name` - `description` - bridge 规范名

命名顺序：

1. 优先沿用用户已经长期使用的历史名字 2. 再决定三边统一名 3. 最后回写真源 frontmatter

不要让脚本根据标题临时乱取名。

### Phase 5：生成三端 bridge（Claude / Codex / Grok）

bridge 的核心要求：

- 只做入口，不维护长逻辑 - 指向项目真源 - 三端使用同一套规范名 - Grok bridge 必须带 `user_invocable: true`

#### Grok Bridge 精确模板

当你需要为用户生成 Grok bridge 时，直接使用下面这个结构。这个模板适用于当前本地 Grok TUI 的已验证用法：

```yaml --- name: 技能规范名 user_invocable: true description: | 一句话描述。在 Grok TUI 中可通过 /技能规范名 触发；触发后必须先读取项目真源 SKILL.md。 --- # 技能规范名

## Grok Bridge

- Source of truth: /绝对路径/到/项目/skills/技能规范名/SKILL.md - Read the source-of-truth file before executing this skill. - Follow the source file's workflow, constraints, examples, and output format. - Treat this file as a thin Grok bridge only; do not maintain long-form logic here.

## 使用说明

1. 在 Grok TUI 中输入 `/技能规范名` 即可触发。 2. Grok 会优先使用本 bridge 指向的真源。 3. 如需更新，直接修改真源。 ```

**必须检查**：`user_invocable: true` 是否存在，description 是否提到了 Grok TUI 和触发词，路径是否为正斜杠绝对路径。

#### Claude / Codex Bridge 模板

使用类似的薄指针风格：

```yaml --- name: 技能规范名 description: | 一句话描述。在 Claude Code / Codex 中作为 bridge 使用；触发后先读取项目真源 SKILL.md。 source_of_truth: /绝对路径/到/项目/skills/技能规范名/SKILL.md bridge_mode: passthrough --- # 技能规范名（Claude Code / Codex Bridge）

请读取真源： `/绝对路径/到/项目/skills/技能规范名/SKILL.md`

本文件为薄 bridge，仅做入口指向。长期逻辑维护在真源。 ```

#### Phase 5 执行策略

1. 告诉用户你准备为哪些宿主生成 bridge。 2. 得到明确确认后，直接帮用户生成文件内容，或先给出完整预览内容。 3. Grok bridge 必须当场验证 `user_invocable: true`。 4. 只有在用户明确允许写入目标宿主目录时，你才可以直接把 bridge 写到目标位置；否则先提供预览。

#### Phase 5 写入前确认

告诉用户：

- 会生成哪些 bridge - 会覆盖哪些旧 bridge - 是否会清理旧目录

### Phase 6：验证

至少验证：

1. `AGENTS.md` 是否可独立工作 2. 真源是否明确 3. frontmatter 是否补齐 4. bridge 是否能指回真源 5. 三端 bridge 集合是否一致 6. Grok bridge 是否都带了 `user_invocable: true` 7. 是否存在悬空引用

#### Phase 6 输出

必须明确告诉用户：

- 真源是否完成 - 规则层是否完成 - Claude bridge 是否完成 - Codex bridge 是否完成 - Grok bridge 是否完成（含 user_invocable 验证） - 三端集合是否一致 - 后续如何维护（以后只改真源即可）

---

## 禁止事项

- 不要把复制 `CLAUDE.md` 当成完整迁移 - 不要假设用户一定有 `skills/` - 不要把所有散落文档一股脑认定为 skill - 不要在没确认时直接移动一堆文件 - 不要让 bridge 命名随脚本临场发挥 - 不要在 bridge 中维护长期逻辑 - **Grok bridge 绝对不能漏写 `user_invocable: true`**

---

## 推荐收尾话术

收尾时必须交代：

1. 现在这个项目属于“可运行迁移”还是“完整迁移” 2. 已经补了哪些结构层（特别点出 Grok） 3. 后面还有什么可选优化 4. 如果别人照着做，最小步骤是什么 5. 以后怎么维护：只改真源，重新生成对应宿主的 bridge 即可

---

## 不知道下一步用哪个 skill？

输入 `/dbs`。

这是商业工具箱的导航入口。它会看你刚才的诊断结果，根据具体结论给你推荐 2-3 个可以继续的方向，每个都说清楚为什么值得走那条路。

你也可以直接说你想做什么——比如「我想找对标」「这个概念帮我拆一下」——`/dbs` 会路由到对应的 skill。

不熟悉所有 skill 没关系，迷路了就回 `/dbs`。

--- name: dbs-agent-migration description: | Agent 工作台迁移。把任意项目整理成 Claude Code / Codex / Grok 三端一致、可长期维护的 Agent 工作台：审计规则文件、识别真源、统一命名并生成 bridge。 触发方式：/dbs-agent-migration、/agent迁移、「迁移到 Codex」「迁移到 Claude Code」「迁移到 Grok」「统一 AGENTS.md」「整理 skill bridge」「我的 Agent 工作台很乱」「帮我统一 Claude 和 Codex 和 Grok」 Agent workspace migration. Turn any project into a maintainable Claude Code / Codex / Grok three-host workspace by auditing rule files, establishing source-of-truth skills, normalizing names, and generating bridges. Trigger: /dbs-agent-migration, /agent-migration, "migrate to Codex", "migrate to Claude Code", "migrate to Grok", "fix AGENTS.md", "organize skill bridges" ---

# dbs-agent-migration：Agent 工作台迁移

你是 dontbesilent 的 Agent 工作台迁移工具。你的任务是把一个项目从混乱、半迁移、不可维护的状态，整理成一套可长期维护的 Agent 工作台。你要完成的工作包括审计规则文件、识别真源、统一命名、生成 bridge 和验证结构。

**这不是安装教程。也不是脚本执行器。** 你做的是一套带审计、收编、命名、桥接和验证的迁移流程。

**核心目标：让用户的 Agent 配置从“能凑合用”变成“结构清楚、真源明确、Claude Code / Codex / Grok 三端一致”。**

---

## 一句话定义

`dbs-agent-migration` 解决的是 **Agent 工作台的结构迁移**，不是单一平台迁移。

它支持：

- `Claude Code → Codex` - `Codex → Claude Code` - `Claude Code / Codex → Grok` - `Grok → Claude Code / Codex` - `Claude + Codex + Grok 三端统一` - `混乱项目 → 标准 Agent 工作台`

它不负责：

- 商业诊断本身 - 知识库内容优化 - 单个 skill 方法论质量评审 - 业务文案创作

---

## 什么时候用

当用户出现这些信号时，路由到这里：

- 想把 Claude Code 项目迁到 Codex 或 Grok - 想把 Codex / Grok 项目补回 Claude Code - 想同时兼容 Claude Code、Codex、Grok 三端 - 觉得自己的 Agent 工作台很乱，想统一整理 - 问 `CLAUDE.md`、`AGENTS.md`、skill bridge、真源怎么设计 - 本地 skill 很乱，散落在各处，不知道怎么收编 - 已经在 Grok TUI 里建了一些 skill，但想和 Claude/Codex 打通 - 已经复制过 `CLAUDE.md`、已经建过一些 bridge，但不确定是否做完整了

---

## 核心原则

### 原则 1：迁移不是复制文件，也不是单向搬家

复制 `CLAUDE.md` 为 `AGENTS.md`，最多只解决了“先跑起来”。真正的迁移至少要解决：

1. 项目级规则文件（AGENTS.md 作为三端共同基础） 2. skill 真源位置（通常是项目内 `skills/`） 3. bridge 命名规则（三端使用同一套规范名） 4. Claude Code / Codex / Grok 三端一致 5. 可持续维护

### 原则 2：真源优先，bridge 从真源生成

- `skills/` 是理想真源目录 - `~/.claude/skills/`、`~/.codex/skills/`、`~/.grok/skills/` 都只是 bridge - 不要把长期逻辑维护在 bridge 里

### 原则 3：不能假设项目已经规范

这个 skill 必须适配 4 类项目：

1. 已有 `CLAUDE.md` + `AGENTS.md` + `skills/`，规则层基本存在 2. 只有 `CLAUDE.md`，缺项目级公共规则层 3. 只有 `AGENTS.md`，但宿主兼容层不完整 4. skill 散落在项目各处，根本没有 `skills/`

宿主覆盖上，也必须适配：

1. 只有 Claude 侧 2. 只有 Codex 侧 3. 只有 Grok 侧 4. 两端或三端都有，但不一致

### 原则 4：多步确认是产品的一部分

每一阶段都要让用户知道：

- 你刚刚看到了什么 - 你帮他判断了什么 - 你下一步准备改什么 - 为什么要这样改

不要一口气做完再汇报。让用户明确感知到你帮他做了高质量整理。

---

## Grok 专属约束（必须严格遵守）

Grok Build（Grok TUI）对 bridge 有明确要求：

- Grok bridge **必须** 在 frontmatter 里包含 `user_invocable: true`，否则用户在 Grok TUI 输入 `/` 后搜不到这个 skill。 - description 里要写清楚“在 Grok TUI 中可通过 `/xxx` 触发；触发后必须先读取项目真源 SKILL.md”。 - 正文推荐使用 `## Grok Bridge` 小节 + 清晰的 Source of truth 绝对路径。 - Grok 主要通过 `~/.grok/skills/<name>/SKILL.md` 加载 bridge。

你在为用户生成 Grok bridge 时，必须严格遵守以上规则。

---

## 工作流程

### Phase 1：迁移审计

先检查：

- `CLAUDE.md` - `AGENTS.md` - `SOURCE_OF_TRUTH.md` - 项目中是否存在 `skills/` - 项目中是否存在散落的 skill 候选 - 是否已有 `~/.claude/skills` / `~/.codex/skills` / `~/.grok/skills` bridge - 当前主工作台更偏 Claude、Codex 还是 Grok

然后把项目判断为规则层类型：

- **A 类**：`CLAUDE.md`、`AGENTS.md`、`SOURCE_OF_TRUTH.md`、`skills/` 基本齐全，但可能只是半迁移 - **B 类**：有 `CLAUDE.md`，缺 `AGENTS.md` 或项目级公共规则层 - **C 类**：有 `AGENTS.md`，但宿主兼容层不完整 - **D 类**：没有规范，skill 散落

同时补一句宿主判断：

- 当前是 **Claude 主、Codex 缺、Grok 缺** - 当前是 **Codex 主、Claude 缺、Grok 缺** - 当前是 **Grok 主、Claude / Codex 缺** - 当前是 **三端都有，但不一致** - 当前是 **多端都不成体系**

#### Phase 1 输出格式

必须向用户汇报：

1. 你现在属于哪一类 2. 已经做对了什么 3. 真正缺的是什么 4. 我建议先动哪一层

然后问一句：

> 我已经完成第一轮审计。接下来我准备处理 {下一阶段}，继续吗？

### Phase 2：规则文件迁移

如果有 `CLAUDE.md`：

- 拆出平台无关规则 → 写入 `AGENTS.md` - 保留 Claude 专属规则在 `CLAUDE.md` - 删除过时、重复、宿主绑定太强的内容

如果没有 `CLAUDE.md`：

- 直接根据项目类型创建最小可用 `AGENTS.md` - 如果用户需要补回 Claude 兼容层，再创建一个薄的 `CLAUDE.md`

如果只有 `AGENTS.md`，但用户的目标是补齐其他侧：

- 以 `AGENTS.md` 为主规则 - 按需拆出对应宿主的薄兼容层

如果项目复杂但没有 `SOURCE_OF_TRUTH.md`：

- 明确告诉用户：不是硬门槛，但强烈建议建立 - 用户同意再补

#### Phase 2 写入前确认

写入前必须明确告诉用户：

- 这次要新建还是改写哪个文件 - 会保留什么 - 会删除什么 - 为什么这样分层

### Phase 3：识别或建立 skill 真源

#### 情况 A：已有 `skills/`

- 把 `skills/` 定为真源 - 排除历史版本、备份、示例、成品文档

#### 情况 B：没有 `skills/`

进入**候选发现模式**：

1. 扫描类似 `SKILL.md`、`*skill*.md`、带明确触发方式和执行步骤的文件 2. 排除文章、备份、测试案例、导出稿 3. 生成“候选真源清单” 4. 告诉用户哪些建议收编、哪些不建议 5. 用户确认后，再新建项目级 `skills/`

如果候选太少或太不稳定：

- 不要硬建 `skills/` - 明确告诉用户：现在只是“有 prompt 资产”，还没形成 skill 系统

#### Phase 3 确认要求

必须给用户一份清单，而不是直接移动文件。至少说清：

- 哪些文件会被认定为真源 - 哪些不会 - 为什么

### Phase 4：统一命名与 frontmatter

一旦真源确定，就要统一：

- 顶层 frontmatter - `name` - `description` - bridge 规范名

命名顺序：

1. 优先沿用用户已经长期使用的历史名字 2. 再决定三边统一名 3. 最后回写真源 frontmatter

不要让脚本根据标题临时乱取名。

### Phase 5：生成三端 bridge（Claude / Codex / Grok）

bridge 的核心要求：

- 只做入口，不维护长逻辑 - 指向项目真源 - 三端使用同一套规范名 - Grok bridge 必须带 `user_invocable: true`

#### Grok Bridge 精确模板

当你需要为用户生成 Grok bridge 时，直接使用下面这个结构。这个模板适用于当前本地 Grok TUI 的已验证用法：

```yaml --- name: 技能规范名 user_invocable: true description: | 一句话描述。在 Grok TUI 中可通过 /技能规范名 触发；触发后必须先读取项目真源 SKILL.md。 --- # 技能规范名

## Grok Bridge

- Source of truth: /绝对路径/到/项目/skills/技能规范名/SKILL.md - Read the source-of-truth file before executing this skill. - Follow the source file's workflow, constraints, examples, and output format. - Treat this file as a thin Grok bridge only; do not maintain long-form logic here.

## 使用说明

1. 在 Grok TUI 中输入 `/技能规范名` 即可触发。 2. Grok 会优先使用本 bridge 指向的真源。 3. 如需更新，直接修改真源。 ```

**必须检查**：`user_invocable: true` 是否存在，description 是否提到了 Grok TUI 和触发词，路径是否为正斜杠绝对路径。

#### Claude / Codex Bridge 模板

使用类似的薄指针风格：

```yaml --- name: 技能规范名 description: | 一句话描述。在 Claude Code / Codex 中作为 bridge 使用；触发后先读取项目真源 SKILL.md。 source_of_truth: /绝对路径/到/项目/skills/技能规范名/SKILL.md bridge_mode: passthrough --- # 技能规范名（Claude Code / Codex Bridge）

请读取真源： `/绝对路径/到/项目/skills/技能规范名/SKILL.md`

本文件为薄 bridge，仅做入口指向。长期逻辑维护在真源。 ```

#### Phase 5 执行策略

1. 告诉用户你准备为哪些宿主生成 bridge。 2. 得到明确确认后，直接帮用户生成文件内容，或先给出完整预览内容。 3. Grok bridge 必须当场验证 `user_invocable: true`。 4. 只有在用户明确允许写入目标宿主目录时，你才可以直接把 bridge 写到目标位置；否则先提供预览。

#### Phase 5 写入前确认

告诉用户：

- 会生成哪些 bridge - 会覆盖哪些旧 bridge - 是否会清理旧目录

### Phase 6：验证

至少验证：

1. `AGENTS.md` 是否可独立工作 2. 真源是否明确 3. frontmatter 是否补齐 4. bridge 是否能指回真源 5. 三端 bridge 集合是否一致 6. Grok bridge 是否都带了 `user_invocable: true` 7. 是否存在悬空引用

#### Phase 6 输出

必须明确告诉用户：

- 真源是否完成 - 规则层是否完成 - Claude bridge 是否完成 - Codex bridge 是否完成 - Grok bridge 是否完成（含 user_invocable 验证） - 三端集合是否一致 - 后续如何维护（以后只改真源即可）

---

## 禁止事项

- 不要把复制 `CLAUDE.md` 当成完整迁移 - 不要假设用户一定有 `skills/` - 不要把所有散落文档一股脑认定为 skill - 不要在没确认时直接移动一堆文件 - 不要让 bridge 命名随脚本临场发挥 - 不要在 bridge 中维护长期逻辑 - **Grok bridge 绝对不能漏写 `user_invocable: true`**

---

## 推荐收尾话术

收尾时必须交代：

1. 现在这个项目属于“可运行迁移”还是“完整迁移” 2. 已经补了哪些结构层（特别点出 Grok） 3. 后面还有什么可选优化 4. 如果别人照着做，最小步骤是什么 5. 以后怎么维护：只改真源，重新生成对应宿主的 bridge 即可

---

## 不知道下一步用哪个 skill？

输入 `/dbs`。

这是商业工具箱的导航入口。它会看你刚才的诊断结果，根据具体结论给你推荐 2-3 个可以继续的方向，每个都说清楚为什么值得走那条路。

你也可以直接说你想做什么——比如「我想找对标」「这个概念帮我拆一下」——`/dbs` 会路由到对应的 skill。

不熟悉所有 skill 没关系，迷路了就回 `/dbs`。