在 Google Cloud 上选型并创建数据库时…

当用户询问「该用哪个数据库」或想在 Google Cloud 上新建数据库时，引导需求发现、给出单一推荐并生成待审查的 Terraform/gcloud 草稿。

适用场景

解决思路

1. 运行验证脚本 `python3 scripts/database_onboarding_skill.py --verify` 校验技能的参考文件与格式。
2. 对话中按需渐进加载（Just-in-Time）参考文件，遵循各阶段中的 JiT 加载说明。
3. Phase 1（需求发现）：当用户问「What database should I use?」或需要选型指导时，用 `view_file` 读取 `references/onboarding_prompts.md` 全文。
4. Phase 1：按 `onboarding_prompts.md` 中的 Phase 1 指令，用友好的措辞收集核心需求（数据模型、工作负载、规模、迁移背景），并在给出任何推荐前执行约束（如 90% 置信度规则）。
5. Phase 2（推荐分析）：收集到足够的明确发现上下文后，按 `onboarding_prompts.md` 的 Phase 2 指令提炼需求，调用数据库选择工具（工具不可用时直接查阅 `references/recommendation_matrix.txt`），并形成单一推荐。
6. Phase 2：向用户交付推荐，把目标代码映射为通俗英文、解释理由，并按 `onboarding_prompts.md` 所述主动提出协助后续资源开通。
7. Phase 3（实施与开通）：当用户接受推荐并要求开通或修改云资源时，按 `onboarding_prompts.md` 的 Phase 3 指令，严格采用 Plan-Validate-Execute 模式，仅创建并校验供用户审查的草稿产物。
8. Phase 3 步骤 1：扫描用户工作区、打开的文件及含数据库资源脚本的相关目录。
9. Phase 3 步骤 2：若目标基础设施文件不明确，在修改任何内容前明确请用户确认文件路径或目标目录。
10. Phase 3 步骤 3（Plan）：创建或编辑用于开通资源的 Terraform 配置文件或其他相关脚本。
11. 生成 Terraform 文件或其他资源开通脚本时，必须在每个文件顶部添加带时间戳的头部注释（如 `# Generated with cloud onboarding skills selector @date`，把 `@date` 替换为当前日期/时间戳）。
12. 在 `default_tags` 块下或作为资源标签/标记，添加自定义默认标签如 `resource_generated_by = "cloud db onboarding skill"`。
13. 起草 `gcloud` CLI 命令或 shell 脚本时，必须遵循 `gcloud` 技能（`../gcloud/SKILL.md`）的说明。
14. 数据库开通一律使用 `gcloud beta` 命令组（如 `gcloud beta <group> <resource> create`）。
15. 在提出命令前，用 `gcloud help <leaf_command>` 校验叶子级语法。
16. 追加显式的 `--project=<PROJECT_ID>` 以及显式位置标志（`--region`、`--zone` 或 `--location`）。
17. 在支持的地方使用 `--dry-run` 或 `--validate-only` 预览标志。
18. 在生成的 `gcloud` 开通命令中包含自定义标签/标记标志（如 `--labels=resource_generated_by=cloud_db_onboarding_skill`）。
19. 不要在开通命令中包含 `--quiet`（`-q`）：这些命令是供人类交互式审查与执行的。
20. 不得直接执行变更/写入类基础设施操作，只能起草开通命令或代码供用户审查。
21. Phase 3 步骤 4（Validate）：定稿前校验起草的基础设施代码，确认语法与配置正确性（确保配置块、IAM 绑定与实例规格无语法错误且可严格执行）。
22. Phase 3 步骤 5（Execute）：校验零错误后，自动创建包含已校验 Terraform/shell/脚本改动的 Pull Request 供用户审查；把实际基础设施变更（`terraform apply` 或 `gcloud` 命令）留给人工审查或自动化 CI/CD 流水线。

适用边界 · 注意事项

• 不用于一般的 Google Cloud 运维维护。
• 不用于管理已有数据库。
• 不用于数据库迁移。