setup-deploy

运维部署 已审计 @garrytan v1.0.0
信任分
92/100
兼容 Agent
1
速查档案 只列事实:领域、Agent、信任分、作者、原文章节。装与不装请看下方作者解读。
领域
运维部署
兼容 Agent
Claude Code
信任分
92 / 100 · 已通过审计
作者 / 版本 / 许可
@garrytan · v1.0.0 · 未声明 license
安装命令数
1 条

需要注意: 未限定 allowed-tools,默认拥有全部工具权限。

想读作者英文原文? ↓ 滚到正文区切换 · 在 GitHub 查看 ↗

解读由编辑根据原文凝练而成,命令、链接、术语均与作者原文一致;想看完整论述请切到右侧

setup-deploy 是 /land-and-deploy 的前置——它把「这个仓库上线到哪里、怎么发版、URL 是什么、健康检查打哪里」一次性问清楚并写进 CLAUDE.md,让后续每次部署都可被自动化执行。

设计思路

作者发现部署链路最大的成本是「每次都要现查」:哪台主机?是 fly.toml 还是 render.yaml?workflow 在哪个 yml?deploy 完应该 ping 哪个 URL?把这些写一次到 ## Deploy Configuration 段落,下游 /ship / /land-and-deploy 直接读,省去每次的探测开销。

工作流

Step 1 探测当前状态 — 扫平台 config(fly.toml / render.yaml / vercel.json / .vercel / netlify.toml / Procfile / railway.json / railway.toml)+ .github/workflows 里 grep deploy|release|production|staging|cd 标识 DEPLOY_WORKFLOW + 用 package.json 里有无 "bin" 判定 CLI / 用 *.gemspec 判定 library;② Step 2 平台分支处理 — Fly.io(提取 app 名、检 fly CLI、推 URL https://{app}.fly.dev、设 fly status);Render(自动推 URL {service-name}.onrender.com,提示自动 deploy 不需 workflow);Vercel(探 CLI + 项目);Netlify / Heroku / Railway 类似。每条都让用户 confirm production URL,不要替自定义域用户拍脑袋。

输出

最后把决定写成 ## Deploy Configuration (configured by /setup-deploy) 段落 piggy-back 到 CLAUDE.md:platform、deploy command、status command、health check URL、project type。

适合的场景

  • 第一次接手一个仓库就要完成 /ship → /land-and-deploy 闭环
  • 部署链路常变(例如刚切 fly → render),需要把新现状固化
  • 多人协作,希望「部署去哪」对人 / 对 agent 都是同一份事实

何时不要用

  • 项目根本不部署(仅 CLI / 库):PROJECT_TYPE 探测出来后大量步骤可跳
  • 已有团队级部署平台 dashboard 与文档:直接引用 dashboard,不必再走一次

配套

ship(合并入口,用本配置触发部署)、land-and-deploy(合并完直接到生产并轮询健康检查)、landing-report(部署完成后写发布说明)、setup-pre-commit(让 commit 前就过基本质量门)。