Dbs Agent Migration
Audit and reorganize a messy Claude Code, Codex, and Grok workspace so rules, skills, and bridges share one clear source of truth.
Overview
dbs-agent-migration is an agent skill most often used in Build (also Operate) that audits rule files, establishes skill source-of-truth, normalizes names, and generates Claude Code / Codex / Grok bridges.
Install
npx skills add https://github.com/dontbesilent2025/dbskill --skill dbs-agent-migrationWhat is this skill?
- End-to-end migration workflow: audit rule files, identify source-of-truth skills, normalize names, generate bridges, val
- Supports Claude Code ↔ Codex ↔ Grok and three-host unification—not a single-direction install guide
- Explicitly excludes business diagnosis, knowledge-base optimization, and single-skill methodology QA
- Trigger phrases: /dbs-agent-migration, unify AGENTS.md, organize skill bridges, fix half-migrated agent setup
- Goal state: structure clear, truth source explicit, three-host consistency for long-term maintenance
Adoption & trust: 5.9k installs on skills.sh; 6.3k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your project's Claude Code, Codex, and Grok configs disagree, skills are scattered, and you cannot tell which AGENTS.md or bridge file is the real source of truth.
Who is it for?
Indie maintainers juggling Claude Code, Codex, and Grok who need a structured migration pass before adding more agent features.
Skip if: Greenfield projects with a single agent and no CLAUDE.md sprawl—skip until multi-host or messy rules actually hurt velocity; also not for skill content quality reviews or business strategy.
When should I use this skill?
/dbs-agent-migration, /agent迁移, migrate to Codex/Claude Code/Grok, unify AGENTS.md, organize skill bridges, or when the agent workbench is messy across three hosts.
What do I get? / Deliverables
You get a validated three-host agent workbench with audited rules, unified naming, generated bridges, and explicit truth sources instead of a half-migrated pile.
- Migration audit of rule and skill files
- Normalized naming map and generated host bridges
- Validated agent workbench structure report
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Agent workbench structure is built and maintained while you integrate coding agents into the repo—canonical on Build agent-tooling. Migration covers AGENTS.md, skill bridges, and naming across hosts—core agent-tooling hygiene, not app feature code.
Where it fits
Audit scattered skills and generate bridges so Codex and Claude Code read the same canonical skill paths.
Align AGENTS.md and host-specific rule files after renaming so new contributors know the entry doc.
Re-run validation when a host upgrade changes config file conventions.
Pre-merge check that migration did not drop security-related agent rules or duplicate conflicting instructions.
How it compares
A migration-and-governance workflow skill, not a marketplace installer or a one-line “copy AGENTS.md to .cursorrules” cheat sheet.
Common Questions / FAQ
Who is dbs-agent-migration for?
Solo builders and small teams maintaining Claude Code, Codex, and Grok in one repo who need audit, naming, and bridge discipline rather than another ad-hoc config paste.
When should I use dbs-agent-migration?
In Build when standing up agent-tooling, before onboarding teammates to agents, when switching primary host (e.g. Codex → Claude), or in Operate when config drift makes every session start with “which file do I edit?”
Is dbs-agent-migration safe to install?
The skill guides filesystem and repo structure changes—review diffs carefully and check the Security Audits panel on this page before running migration steps on production or sensitive repos.
SKILL.md
READMESKILL.md - Dbs Agent Migration
# 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`、