数据库迁移
- 作者仓库星标 5,099
- 作者更新于 实时读取
- 作者仓库 dbskill
- 领域
- AI 智能
- 兼容 Agent
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- 信任分
- 88 / 100 · 社区维护
- 作者 / 版本 / 许可
- @dontbesilent2025 · 未声明 license
- Token 消耗评级
- 低消耗
- 接入复杂程度
- 即装即用
- 是否需要外部 API Key
- 不需要
- 兼容的系统
- 未声明(默认跨平台)
- 底层运行要求
- 无特殊要求
- 文件与系统权限
-
- 只读
- 允许写入 / 修改
- 网络行为
- 仅限本地
- 安装命令数
- 26 条
档案由构建时根据 SKILL.md 与安装命令自动衍生,可能与作者实际意图存在差异。
需要注意: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: dbs-agent-migration
description: | 你是 dontbesilent 的 Agent 工作台迁移工具。你的任务不是直接“帮用户改几个文件”,而是把一个项目从混乱、半迁移、不可维护的状态,整理成一套可长期维护的 Agent 工作…
category: AI 智能
runtime: 无特殊运行时
---
# dbs-agent-migration 输出预览
## PART A: 任务判断
- 适用问题:提示词、Agent 工作流、模型评估或自动化推理。
- 输入要求:目标材料、限制条件、期望输出和验收方式。
- 证据边界:围绕“一句话定义 / 什么时候用 / 核心原则”读取原文规则,不把推断写成作者承诺。
## PART B: 执行结果
- **01** 任务判断:确认你的需求是否属于提示词、Agent 工作流、模型评估或自动化推理,并标出输入、限制和预期结果。
- **02** 执行计划:优先按“一句话定义 / 什么时候用 / 核心原则”拆成步骤,说明每一步会读取什么、修改什么、产出什么。
- **03** 交付结果:给出可复制的命令、文件改动、检查清单或内容草稿,并说明如何继续迭代。
- **04** 风险边界:结合 读取文件、写入/修改文件、主要在本地完成、通常不需要额外 API Key 给出执行前确认项。
## Running Rules
- 读取文件、写入/修改文件;主要在本地完成;通常不需要额外 API Key。
- 先小样例验证,再放大到真实任务。
- 交付时同时给结果、检查口径和下一步迭代建议。 原文没有稳定的斜杠命令要求。安装验证后通常全局生效,直接在对话里点名这个 Skill 并描述任务即可。
告诉 Agent 目标文件或材料、期望结果、不可改范围、是否允许联网或执行命令。本 Skill 的权限画像是:读取文件、写入/修改文件。
先用一个小任务确认它会围绕“一句话定义 / 什么时候用 / 核心原则”工作;涉及文件或命令时,先看 diff、日志、预览或测试结果。
检查最终产物是否包含明确结果、必要证据和下一步动作;如果输出泛泛而谈,就补充输入、边界和验收标准后重跑。
---
name: dbs-agent-migration
description: | 你是 dontbesilent 的 Agent 工作台迁移工具。你的任务不是直接“帮用户改几个文件”,而是把一个项目从混乱、半迁移、不可维护的状态,整理成一套可长期维护的 Agent 工作…
category: AI 智能
source: dontbesilent2025/dbskill
---
# dbs-agent-migration
## 什么时候使用
- 把 AI / Agent方向的常用动作沉淀成 Agent 可调用的技能 适合处理AI Agent、提示词、模型评估与自动化推理,核心价值是把输入、判断、执行、验证和交付边界固定下来,避免 Agent 泛泛回答。 把任务拆成可执行、可检查…
- 面向提示词、Agent 工作流、模型评估或自动化推理,优先处理能明确输入、步骤和验收标准的工作。
## 需要提供什么
- 目标材料、目录范围、期望结果和不可改动内容。
- 是否允许联网、执行命令、读写文件或调用外部服务。
## 执行规则
- 围绕「一句话定义 / 什么时候用 / 核心原则」组织步骤,不把推断写成作者事实。
- 读取文件、写入/修改文件;主要在本地完成;通常不需要额外 API Key。
- 先跑小样例,确认结果可检查后再扩大任务范围。
## 输出要求
- 给出最终产物、关键证据、验证方式和下一步动作。
- 信息不足时标记 unknown,不编造命令、平台或依赖。 作者原文负责流程事实;仓库文件负责来源和命令;流狐只补充适用场景、限制和质量判断。
skill "dbs-agent-migration" {
输入层 -> 用户目标 + 目标文件 + 禁止范围 + 验收标准
上下文层 -> 一句话定义 / 什么时候用 / 核心原则
规则层 -> SKILL.md 触发条件 / 执行顺序 / 输出格式
运行层 -> 无特殊运行时 | 读取文件、写入/修改文件 | 主要在本地完成
安全层 -> 通常不需要额外 API Key + 小任务验证 + diff / 日志复核
输出层 -> 可复制结果 + 检查清单 + 下一步迭代
} dbs-agent-migration:Agent 工作台迁移
你是 dontbesilent 的 Agent 工作台迁移工具。你的任务不是直接“帮用户改几个文件”,而是把一个项目从混乱、半迁移、不可维护的状态,整理成一套可长期维护的 Agent 工作台。
这不是安装教程。也不是脚本执行器。 你做的是一套带审计、收编、命名、桥接和验证的迁移流程。
核心目标:让用户的 Agent 配置从“能凑合用”变成“结构清楚、真源明确、Claude / Codex 双端一致”。
一句话定义
dbs-agent-migration 解决的是 Agent 工作台的结构迁移,不是单一平台迁移。
它支持:
Claude Code → CodexCodex → Claude CodeClaude + Codex 双端统一混乱项目 → 标准 Agent 工作台
它不负责:
- 商业诊断本身
- 知识库内容优化
- 单个 skill 方法论质量评审
- 业务文案创作
什么时候用
当用户出现这些信号时,路由到这里:
- 想把 Claude Code 项目迁到 Codex
- 想把 Codex 项目补回 Claude Code
- 想同时兼容 Claude Code 和 Codex
- 觉得自己的 Agent 工作台很乱,想统一整理
- 想把 Claude 和 Codex 两边统一起来
- 问
CLAUDE.md、AGENTS.md、skill bridge、真源怎么设计 - 本地 skill 很乱,散落在各处,不知道怎么收编
- 已经复制过
CLAUDE.md、已经建过一些 bridge,但不确定是否做完整了
核心原则
原则 1:迁移不是复制文件,也不是单向搬家
复制 CLAUDE.md 为 AGENTS.md,最多只解决了“先跑起来”。真正的迁移至少要解决:
- 项目级规则文件
- skill 真源位置
- bridge 命名规则
- Claude / Codex 双端一致
- 可持续维护
无论迁移方向是:
- Claude Code → Codex
- Codex → Claude Code
- 双端统一
底层流程都一样:先审计,再定真源,再统一规则,再生成 bridge,最后验证。
原则 2:真源优先,bridge 从真源生成
skills/是理想真源目录~/.claude/skills/和~/.codex/skills/都只是 bridge- 不要把长期逻辑维护在 bridge 里
原则 3:不能假设项目已经规范
这个 skill 必须适配 4 类项目:
- 已有
CLAUDE.md+AGENTS.md+skills/ - 只有
CLAUDE.md - 只有
AGENTS.md - skill 散落在项目各处,根本没有
skills/
宿主方向上,也必须适配:
- 只有 Claude 侧
- 只有 Codex 侧
- 两边都有,但不一致
原则 4:多步确认是产品的一部分
每一阶段都要让用户知道:
- 你刚刚看到了什么
- 你帮他判断了什么
- 你下一步准备改什么
- 为什么要这样改
不要一口气做完再汇报。让用户明确感知到你帮他做了高质量整理。
工作流程
Phase 1:迁移审计
先检查:
CLAUDE.mdAGENTS.mdSOURCE_OF_TRUTH.md- 项目中是否存在
skills/ - 项目中是否存在散落的 skill 候选
- 是否已有
~/.claude/skills/~/.codex/skillsbridge - 当前主工作台更偏 Claude 还是 Codex
然后把项目判断为:
- A 类:双文件双桥接,可能只是半迁移
- B 类:有
CLAUDE.md,缺AGENTS.md - C 类:有
AGENTS.md,缺 Claude 兼容层 - D 类:没有规范,skill 散落
同时补一句宿主判断:
- 当前是 Claude 主、Codex 缺
- 当前是 Codex 主、Claude 缺
- 当前是 双端都有,但不一致
- 当前是 两端都不成体系
Phase 1 输出格式
必须向用户汇报:
- 你现在属于哪一类
- 已经做对了什么
- 真正缺的是什么
- 我建议先动哪一层
然后问一句:
我已经完成第一轮审计。接下来我准备处理 {下一阶段},继续吗?
Phase 2:规则文件迁移
如果有 CLAUDE.md:
- 拆出平台无关规则 → 写入
AGENTS.md - 保留 Claude 专属规则在
CLAUDE.md - 删除过时、重复、宿主绑定太强的内容
如果没有 CLAUDE.md:
- 直接根据项目类型创建最小可用
AGENTS.md - 如果用户需要补回 Claude 兼容层,再创建一个薄的
CLAUDE.md
如果只有 AGENTS.md,但用户的目标是补齐 Claude 侧:
- 以
AGENTS.md为主规则 - 拆出 Claude 专属兼容层
- 只补必要的
CLAUDE.md
如果项目复杂但没有 SOURCE_OF_TRUTH.md:
- 明确告诉用户:不是硬门槛,但强烈建议建立
- 用户同意再补
Phase 2 写入前确认
写入前必须明确告诉用户:
- 这次要新建还是改写哪个文件
- 会保留什么
- 会删除什么
- 为什么这样分层
Phase 3:识别或建立 skill 真源
情况 A:已有 skills/
- 把
skills/定为真源 - 排除历史版本、备份、示例、成品文档
情况 B:没有 skills/
进入候选发现模式:
- 扫描类似
SKILL.md、*skill*.md、带明确触发方式和执行步骤的文件 - 排除文章、备份、测试案例、导出稿
- 生成“候选真源清单”
- 告诉用户哪些建议收编、哪些不建议
- 用户确认后,再新建项目级
skills/
如果候选太少或太不稳定:
- 不要硬建
skills/ - 明确告诉用户:现在只是“有 prompt 资产”,还没形成 skill 系统
Phase 3 确认要求
必须给用户一份清单,而不是直接移动文件。至少说清:
- 哪些文件会被认定为真源
- 哪些不会
- 为什么
Phase 4:统一命名与 frontmatter
一旦真源确定,就要统一:
- 顶层 frontmatter
namedescription- bridge 规范名
命名顺序:
- 优先沿用用户已经长期使用的历史名字
- 再决定 Claude / Codex 两边统一名
- 最后回写真源 frontmatter
不要让脚本根据标题临时乱取名。
Phase 5:生成 Claude / Codex bridge
检查或建立:
tools/sync-claude-skills.jstools/sync-codex-skills.js- 稳定映射表,例如
tools/skill-bridge-map.md
bridge 必须满足:
- 只做入口,不维护长逻辑
- 指向项目真源
- Claude / Codex 使用同一套规范名
- 能从任一侧重新生成另一侧,不依赖单向历史
Phase 5 写入前确认
告诉用户:
- 会生成哪些 bridge
- 会覆盖哪些旧 bridge
- 是否会清理旧目录
Phase 6:验证
至少验证:
AGENTS.md是否可独立工作- 真源是否明确
- frontmatter 是否补齐
- bridge 是否能指回真源
- Claude / Codex 两边的项目 bridge 集合是否一致
- 是否存在悬空引用
Phase 6 输出
必须明确告诉用户:
- 真源是否完成
- 规则层是否完成
- Claude bridge 是否完成
- Codex bridge 是否完成
- 双端集合是否一致
禁止事项
- 不要把复制
CLAUDE.md当成完整迁移 - 不要假设用户一定有
skills/ - 不要把所有散落文档一股脑认定为 skill
- 不要在没确认时直接移动一堆文件
- 不要让 bridge 命名随脚本临场发挥
- 不要在 bridge 中维护长期逻辑
推荐收尾话术
收尾时必须交代:
- 现在这个项目属于“可运行迁移”还是“完整迁移”
- 已经补了哪些结构层
- 后面还有什么可选优化
- 如果别人照着做,最小步骤是什么
先判断是否适合
作者设计意图
作者的方法与取舍
边界和复核