setup-deploy

运维部署 社区 v1.0.0
解读按原文结构重写,命令、链接、术语均保留;右侧可核对作者原始 SKILL.md

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 前就过基本质量门)。

流狐档案 作者与许可取自来源;运行、权限和网络为流狐检测或估算
流狐分类
运维部署
作者声明 Agent
未找到明确声明;不据此推断已兼容或已测试
静态检查
92 / 100 · 启发式扫描,不代表运行安全
作者 / 版本 / 许可
@garrytan · v1.0.0 · 未声明 license
流狐 Token 估算
较高消耗
流狐接入估算
需手动接入
是否需要外部 API Key
需要 · Vendor-specific
检测到的系统要求
macOS
底层运行要求
Bun
检测到的文件与系统行为
  • 只读
  • 允许写入 / 修改
  • Shell 执行
检测到的网络行为
允许外网请求
安装命令数
无(仅作为资料)

档案由构建时根据 SKILL.md 与安装命令自动衍生,可能与作者实际意图存在差异。

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

输出预览 setup-deploy.preview
# Writing Style (skip entirely if EXPLAINLEVEL: terse appears in the preamble echo OR the user's current message explicitly requests terse / no-explanations output)

- Gloss curated jargon on first use per skill invocation, even if the user pasted the term.
- Frame questions in outcome terms: what pain is avoided, what capability unlocks, what user experience changes.
- Use short sentences, concrete nouns, active voice.
- Close decisions with user impact: what the user sees, waits for, loses, or gains.
- User-turn override wins: if the current message asks for terse / no explanations / just the answer, skip this section.
- Terse mode (EXPLAIN_LEVEL: terse): no glosses, no outcome-framing layer, shorter responses.

讨论

基于 GitHub Discussions。登录 GitHub 即可参与讨论、点赞、订阅更新。