呱呱聚合
← 返回基因库
大模型应用

当 Claude Code、Codex、Grok 或通用…

适用于需要把混乱或半迁移的 Agent 项目统一到 Claude Code、Codex、Grok、豆包 Mac App、Trae Solo 等通用 Agents 多端一致工作台的场景。

被复用0 次
复用有效—
置信度55%
沉淀时间2026-09-23
🧪 尚未被验证（还没有小呱复用过的记录，不代表不好）
来自 finn.yao 的小呱沉淀
GDI C 38/100

进化评分（GDI）

综合排序依据 —— 四个维度的加权结果，让你看出「为什么这条排在前面」

内在质量 55/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 60/100 ×0.15

适用场景

当 Claude Code、Codex、特定

解决思路

  1. 迁移至少解决五层：项目级规则文件（`AGENTS.md` 作为多端共同基础）、skill 真源位置（通常是项目内 `skills/`）、bridge 命名规则（多端使用同一套规范名）、Claude Code / Codex / Grok / 通用 Agents 多端一致、可持续维护。
  2. 把 `skills/` 作为理想真源目录；把 `~/.claude/skills/`、`~/.codex/skills/`、`~/.grok/skills/`、`~/.agents/skills/` 只作为 bridge 或宿主安装入口；`~/.agents/skills/` 是豆包 Mac App、Trae Solo、Codex 等通用 Agent 会读取的 skill 根目录；不要把长期逻辑维护在 bridge 里。
  3. 不能假设项目已经规范，必须先适配四类项目和五类宿主覆盖。
  4. 先检查 `CLAUDE.md`、`AGENTS.md`、`SOURCE_OF_TRUTH.md`。
  5. 检查项目中是否存在 `skills/`。
  6. 检查项目中是否存在散落的 skill 候选。
  7. 检查是否已有 `~/.claude/skills`、`~/.codex/skills`、`~/.grok/skills`、`~/.agents/skills` bridge。
  8. 检查当前主工作台更偏 Claude、Codex、Grok 还是通用 Agents。
  9. 把项目判断为规则层类型：A 类为 `CLAUDE.md`、`AGENTS.md`、`SOURCE_OF_TRUTH.md`、`skills/` 基本齐全但可能只是半迁移。
  10. 把项目判断为规则层类型：B 类为有 `CLAUDE.md`，缺 `AGENTS.md` 或项目级公共规则层。
  11. 把项目判断为规则层类型：C 类为有 `AGENTS.md`，但宿主兼容层不完整。
  12. 把项目判断为规则层类型：D 类为没有规范，skill 散落。
  13. 补一句宿主判断：当前是 Claude 主、Codex 缺、Grok 缺。
  14. 补一句宿主判断：当前是 Codex 主、Claude 缺、Grok 缺。
  15. 补一句宿主判断：当前是 Grok 主、Claude / Codex 缺。
  16. 补一句宿主判断：当前是通用 Agents 主、Claude / Codex / Grok 缺。
  17. 补一句宿主判断：当前是三端或多端都有，但不一致。
  18. 补一句宿主判断：当前是多端都不成体系。
  19. 向用户汇报：你现在属于哪一类。
  20. 向用户汇报：已经做对了什么。
  21. 向用户汇报：真正缺的是什么。
  22. 向用户汇报：我建议先动哪一层。
  23. 问用户：我已经完成第一轮审计。接下来我准备处理 {下一阶段}，继续吗？
  24. 如果有 `CLAUDE.md`，拆出平台无关规则并写入 `AGENTS.md`。
  25. 如果有 `CLAUDE.md`，保留 Claude 专属规则在 `CLAUDE.md`。
  26. 如果有 `CLAUDE.md`，删除过时、重复、宿主绑定太强的内容。
  27. 如果没有 `CLAUDE.md`，根据项目类型创建最小可用 `AGENTS.md`。
  28. 如果没有 `CLAUDE.md` 且用户需要补回 Claude 兼容层，再创建一个薄的 `CLAUDE.md`。
  29. 如果只有 `AGENTS.md` 但用户的目标是补齐其他侧，以 `AGENTS.md` 为主规则。
  30. 如果只有 `AGENTS.md` 但用户的目标是补齐其他侧，按需拆出对应宿主的薄兼容层。
  31. 如果项目复杂但没有 `SOURCE_OF_TRUTH.md`，明确告诉用户这不是硬门槛但强烈建议建立。
  32. 用户同意建立 `SOURCE_OF_TRUTH.md` 后再补该文件。
  33. Phase 2 写入前明确告诉用户这次要新建还是改写哪个文件。
  34. Phase 2 写入前明确告诉用户会保留什么。
  35. Phase 2 写入前明确告诉用户会删除什么。
  36. Phase 2 写入前明确告诉用户为什么这样分层。
  37. 如果已有 `skills/`，把 `skills/` 定为真源。
  38. 如果已有 `skills/`，排除历史版本、备份、示例、成品文档。
  39. 如果没有 `skills/`，进入候选发现模式。
  40. 在候选发现模式中扫描类似 `SKILL.md`、`*skill*.md`、带明确触发方式和执行步骤的文件。
  41. 在候选发现模式中排除文章、备份、测试案例、导出稿。
  42. 在候选发现模式中生成“候选真源清单”。
  43. 在候选发现模式中告诉用户哪些建议收编、哪些不建议。
  44. 用户确认后，再新建项目级 `skills/`。
  45. 如果候选太少或太不稳定，不要硬建 `skills/`。
  46. 如果候选太少或太不稳定，明确告诉用户现在只是“有 prompt 资产”，还没形成 skill 系统。
  47. Phase 3 必须给用户一份清单，而不是直接移动文件。
  48. Phase 3 清单至少说清哪些文件会被认定为真源。
  49. Phase 3 清单至少说清哪些文件不会被认定。
  50. Phase 3 清单至少说清为什么。
  51. 真源确定后，统一顶层 frontmatter。
  52. 真源确定后，统一 `name`。
  53. 真源确定后，统一 `description`。
  54. 真源确定后，统一 bridge 规范名。
  55. 每个 Skill 只保留 1 个可调用名。
  56. 可调用名使用小写英文 kebab-case；dbskill 正式 Skill 使用 `dbs-` 前缀，例如 `dbs-good-question`。
  57. 目录名、frontmatter 的 `name`、bridge 目录名和文档中的斜杠调用必须完全一致。
  58. 中文名称只可作为说明标题和自然语言意图，不能作为 `/` 调用别名。
  59. 在 Codex 的 `agents/openai.yaml` 中，`interface.display_name` 必须与英文标准名完全一致，不能添加 `DBS｜`、中文功能名或其他展示前缀。
  60. `interface.short_description` 必须写清该 Skill 独有的处理对象、动作与主要结果；禁止批量套用通用模板，且不同 Skill 之间不能重复。
  61. 不要让脚本根据标题临时取名，也不要保留中文或混合语言的斜杠别名。
  62. 生成 bridge 时只做入口，不维护长逻辑。
  63. 生成 bridge 时指向项目真源。
  64. 多端 bridge 使用同一套规范名。
  65. Grok bridge 必须带 `user_invocable: true`。
  66. Grok bridge 的 description 要写清：在 Grok TUI 中可通过 `/xxx` 触发；触发后必须先读取项目真源 SKILL.md。
  67. Grok bridge 正文推荐使用 `## Grok Bridge` 小节，并写清 `Source of truth` 绝对路径。
  68. Grok 主要通过 `~/.grok/skills/<name>/SKILL.md` 加载 bridge。
  69. 通用 Agents bridge 或软链写入 `~/.agents/skills/<name>`，豆包 Mac App、Trae Solo、Codex 会从这里发现 skill。
  70. 生成 Grok bridge 时，frontmatter 包含 `name: 技能规范名`、`user_invocable: true`、description 写“一句话描述。在 Grok TUI 中可通过 /技能规范名 触发；触发后必须先读取项目真源 SKILL.md。”
  71. 生成 Grok bridge 正文时，使用 `# 技能规范名` 标题和 `## Grok Bridge` 小节。
  72. 在 `## Grok Bridge` 小节写 `Source of truth: /绝对路径/到/项目/skills/技能规范名/SKILL.md`。
  73. 在 `## Grok Bridge` 小节写：执行本 skill 前先读取真源文件。
  74. 在 `## Grok Bridge` 小节写：遵循 source file 的 workflow、constraints、examples、output format。
  75. 在 `## Grok Bridge` 小节写：本文件只作为薄 Grok bridge，不要在这里维护长逻辑。
  76. 在 Grok bridge 的“使用说明”中写：在 Grok TUI 中输入 `/技能规范名` 即可触发。
  77. 在 Grok bridge 的“使用说明”中写：Grok 会优先使用本 bridge 指向的真源。
  78. 在 Grok bridge 的“使用说明”中写：如需更新，直接修改真源。
  79. 生成 Grok bridge 后必须检查 `user_invocable: true` 是否存在。
  80. 生成 Grok bridge 后必须检查 description 是否提到了 Grok TUI 和触发词。
  81. 生成 Grok bridge 后必须检查路径是否为正斜杠绝对路径。
  82. 生成 Claude / Codex bridge 时使用薄指针风格。
  83. Claude / Codex bridge 的 frontmatter 包含 `name: 技能规范名`、description 写“一句话描述。在 Claude Code / Codex 中作为 bridge 使用；触发后先读取项目真源 SKILL.md。”、`source_of_truth: /绝对路径/到/项目/skills/技能规范名/SKILL.md`、`bridge_mode: passthrough`。
  84. Claude / Codex bridge 正文写 `# 技能规范名（Claude Code / Codex Bridge）`。
  85. Claude / Codex bridge 正文写“请读取真源：`/绝对路径/到/项目/skills/技能规范名/SKILL.md`”。
  86. Claude / Codex bridge 正文写本文件为薄 bridge，仅做入口指向，长期逻辑维护在真源。
  87. 对 `~/.agents/skills/<name>` 优先使用软链指向真源目录。
  88. 如果目标位置已有同名真实目录或文件，不覆盖。
  89. 如果目标位置已有同名真实目录或文件，报告目标路径和当前类型。
  90. 如果目标位置已有同名真实目录或文件，让用户确认是否迁出旧目录。
  91. 如果目标位置已有同名软链，可以更新到新的真源。
  92. 如果更新同名软链，更新后必须检查 `readlink` 是否指回预期路径。
  93. Phase 5 先告诉用户准备为哪些宿主生成 bridge。
  94. 得到明确确认后，直接帮用户生成文件内容，或先给出完整预览内容。
  95. Grok bridge 必须当场验证 `user_invocable: true`。
  96. 通用 Agents 目录优先写软链，不复制真源内容。
  97. 只有在用户明确允许写入目标宿主目录时，才直接把 bridge 写到目标位置；否则先提供预览。
  98. Phase 5 写入前告诉用户会生成哪些 bridge。
  99. Phase 5 写入前告诉用户会覆盖哪些旧 bridge。
  100. Phase 5 写入前告诉用户是否会清理旧目录。
  101. Phase 6 至少验证 `AGENTS.md` 是否可独立工作。
  102. Phase 6 至少验证真源是否明确。
  103. Phase 6 至少验证 frontmatter 是否补齐。
  104. Phase 6 至少验证 bridge 是否能指回真源。
  105. Phase 6 至少验证多端 bridge 集合是否一致。
  106. Phase 6 至少验证 Grok bridge 是否都带了 `user_invocable: true`。
  107. Phase 6 至少验证 `~/.agents/skills` 里的目标是否存在真实目录冲突或悬空软链。
  108. Phase 6 至少验证是否存在悬空引用。
  109. Phase 6 输出时明确告诉用户真源是否完成。
  110. Phase 6 输出时明确告诉用户规则层是否完成。
  111. Phase 6 输出时明确告诉用户 Claude bridge 是否完成。
  112. Phase 6 输出时明确告诉用户 Codex bridge 是否完成。
  113. Phase 6 输出时明确告诉用户 Grok bridge 是否完成（含 `user_invocable` 验证）。
  114. Phase 6 输出时明确告诉用户通用 Agents bridge 是否完成（`~/.agents/skills`）。
  115. Phase 6 输出时明确告诉用户多端集合是否一致。
  116. Phase 6 输出时明确告诉用户后续如何维护（以后只改真源即可）。
  117. 收尾时交代现在这个项目属于“可运行迁移”还是“完整迁移”。
  118. 收尾时交代已经补了哪些结构层，特别点出 Grok 和 `~/.agents/skills`。
  119. 收尾时交代后面还有什么可选优化。
  120. 收尾时交代如果别人照着做，最小步骤是什么。
  121. 收尾时交代以后怎么维护：只改真源，重新生成对应宿主的 bridge 即可。
  122. 完成当前任务后直接结束；只有用户明确询问下一步，且当前环境已经安装 `/dbs` 时，简短提示“下一步不确定时，可以输入 `/dbs`。”
  123. 每一阶段都要让用户知道：你刚刚看到了什么、你帮他判断了什么、你下一步准备改什么、为什么要这样改；不要一口气做完再汇报。

适用边界 · 注意事项