打开 google/skills 后，最容易卡住的不是那一行安装命令，而是两个更实际的问题：几十个 Skill 到底装哪几个，Claude Code 和 Codex 又会把它们放到哪里。稳妥做法是先列出仓库里的 Skill，只挑当前项目需要的两三个，再分别确认两个代理都能识别；完成后，你应该能在 Claude Code 里用斜杠调用，在 Codex 里用 $ 明确点名。

先判断：google/skills 适合什么任务

google/skills 是 Google 维护的 Agent Skills 仓库，面向 Google 产品与技术，当前内容重心包括 Google Cloud、Gemini Enterprise Agent Platform、GKE、BigQuery、Cloud Run、Firebase、Google Ads API 和 Analytics。仓库 README 明确标注仍处于活跃开发阶段，因此安装前看一次清单，比照着旧教程复制 Skill 名更可靠。

它提供的是给编码代理读取的工作流、约束、参考资料和可选脚本，不会替你创建 Google Cloud 项目，也不会自动获得账号权限。例如 gemini-api 要求已有 Google Cloud 凭据并启用对应 API；google-cloud-recipe-auth 则会先追问“谁在认证、代码跑在哪里、目标服务是什么”。

我会这样试：如果目标只是把一个 Web 服务部署到 Cloud Run，我先选 cloud-run-basics 和 google-cloud-recipe-auth，不会把整个仓库一次装完。

先列清单，再装到两个代理

skills CLI 同时支持 Claude Code 与 Codex；官方参数表把 Claude Code 的项目目录映射为 .claude/skills/，把 Codex 的项目目录映射为 .agents/skills/。项目级安装也更容易随仓库提交给团队，是这份教程的默认选项。

在项目根目录先只看清单，不写入文件：

npx skills add google/skills --list

确认 Skill 名后，同时安装给 Claude Code 和 Codex。下面以 Cloud Run 与认证两个 Skill 为例：

npx skills add google/skills 
  --skill cloud-run-basics 
  --skill google-cloud-recipe-auth 
  --agent claude-code 
  --agent codex

想手动选择时，直接运行仓库给出的入口：

npx skills add google/skills

安装器会让你选择 Skill、目标代理和链接或复制方式。看到项目里出现 .claude/skills/cloud-run-basics/ 与 .agents/skills/cloud-run-basics/，才算这一段完成；只有“安装成功”提示、目录却不存在，先不要进入代理测试。

我会这样试：先装一个 Skill 并检查两个目录，再追加第二个。这样若路径或权限有问题，排查范围只有一个名字。

Claude Code：用斜杠点名，也能让它自动匹配

Claude Code 官方 Skills 文档说明，Skill 由 SKILL.md 及可选的脚本、模板和参考资料组成；Claude 可以根据描述自动加载，也可以用 /skill-name 直接调用。个人目录是 ~/.claude/skills/，项目目录是 .claude/skills/。

在同一项目目录启动 Claude Code，然后输入：

/cloud-run-basics

先检查这个仓库是否满足 Cloud Run 的部署条件。不要部署；先列出缺少的 API、IAM 角色、地址和 PORT 设置。

成功标志不是回答里出现“Cloud Run”几个字，而是它会按该 Skill 的规则检查服务、任务或 worker pool，并提醒部署代码必须 0.0.0.0、使用注入的 PORT。如果斜杠列表里没有新 Skill，先退出并重启 Claude Code；官方文档特别提示，启动会话时顶层 Skills 目录还不存在，创建目录后需要重启才能开始。

我会这样试：先让它只做前置检查，不授权真实部署。确认 Skill 确实生效后，再单独批准会修改云资源的命令。

Codex：在 Skills 列表确认，再用 $ 调用

Codex 官方 Skills 文档给出两种调用方式：在 CLI 或 IDE 中打开 /skills，或输入 $ 点名一个 Skill；任务与 Skill 的 description 匹配时，Codex 也可以自动选择。仓库级 Skill 使用 .agents/skills/，Codex 会从当前工作目录向上扫描到仓库根目录。

先打开 /skills，确认能找到 google-cloud-recipe-auth。随后输入：

$google-cloud-recipe-auth

判断当前项目应使用人类登录、本地 ADC 还是生产服务身份。先问清运行位置和目标 API，再给最小权限方案；不要创建或下载长期服务账号密钥。

看到 Codex 先区分 gcloud auth login 与 gcloud auth application-default login，并询问身份、运行位置和目标服务，说明它读到了 Skill，而不是只根据常识生成一段认证说明。新 Skill 没出现在选择器时，重启 Codex 后再看一次。

我会这样试：在真正运行 gcloud 之前，要求 Codex 把将要执行的命令、影响范围和成功判断列出来；认证与 IAM 属于高风险步骤，不把“能跑”当成“权限合理”。

项目安装与全局安装，先选一个边界

只服务当前仓库时，保留默认的项目安装。团队成员拉取代码后能看到同一组 Skill，也不会把几十个 Google Cloud Skill 带进无关项目。

确实要跨项目使用时，可以加 --global：

npx skills add google/skills 
  --skill google-cloud-recipe-auth 
  --agent claude-code 
  --agent codex 
  --global

这里有一个需要复查的路径差异：skills CLI 的支持表把 Codex 全局目录列为 ~/.codex/skills/，而当前 Codex 官方 Build skills 页面把个人目录列为 $HOME/.agents/skills；两边对项目目录 .agents/skills/ 的说法一致。为减少版本差异造成的“装了但看不见”，初次使用优先项目安装。全局安装后必须在 /skills 里验证，不能只看终端提示。

Codex 还有一条官方替代路径：在 Codex 里调用 $skill-installer，明确要求从 https://github.com/google/skills 安装指定 Skill。官方文档说明该安装器可以从其他仓库下载 Skills；如果新安装项没有出现，重启 Codex。

我会这样试：先在一个测试仓库做项目安装。连续三个项目都需要同一 Skill 时，才考虑全局安装，并把两个代理的 Skills 列表各核对一次。

装好以后，用这五项判断是否真的可用

1. 项目里能看到对应目录和 SKILL.md，不是只有安装器缓存。
2. Claude Code 的斜杠菜单能找到 Skill，并能用 /skill-name 直接调用。
3. Codex 的 /skills 能找到 Skill，并能用 $skill-name 明确点名。
4. 回答体现 Skill 的专属约束，例如 Cloud Run 的 0.0.0.0 与 PORT，或认证 Skill 的身份与运行位置追问。
5. 涉及 Google Cloud 写操作时，代理先展示命令、权限与影响范围，再由你批准执行。

如果第 1 项失败，回到安装器和目录权限；第 2、3 项失败，重启对应代理并检查路径；第 4 项失败，确认调用的是正确 Skill 而不是相近名字；第 5 项失败，停止执行，先收紧提示词和权限。

我会这样试：把第一次验证限定为“只读检查”，保留终端输出。路径、触发和专属规则都对得上，再让 Skill 参与真实部署或 IAM 修改。

四个常见坑，比命令写错更隐蔽

• 一次安装全部 Skill：Google 仓库覆盖面很大，Codex 官方文档也说明初始 Skills 列表有上下文预算；Skill 太多时描述可能被缩短或省略。按项目装小集合更容易触发准确。
• 把安装 Skill 当成完成认证：Skill 只是工作流。Google Cloud 凭据、API 启用、计费、IAM 角色与组织策略仍需独立准备。
• 只测试自然语言，不测试显式调用：自然语言可能碰巧得到相似答案。先用 Claude Code 的 /skill-name 或 Codex 的 $skill-name，再观察专属规则。
• 忽略代理差异：基础 SKILL.md 可以跨代理复用，但 Claude Code 的某些扩展字段、子代理上下文和 hooks 并不等于 Codex 也支持。把 Google 仓库当作事实与工作流来源，不把某一代理的扩展能力硬搬到另一边。

我会这样试：每加一个 Skill，只验证一件真实任务。能触发、能给出专属检查、能在执行前停住让人确认，这个 Skill 才值得留下。