setup-deploy

setup-deploy 技能概览

setup-deploy 是 gstack 的部署配置技能，用来为项目配置部署元数据，让后续的 land-and-deploy 运行能够自动执行。它最适合那些需要把一个笼统的“这个要怎么部署？”需求，整理成可重复的部署配置的代理或开发者，尤其是在目标平台还没有明确锁定的时候。

setup-deploy skill 的核心工作很务实：识别部署 provider、生产环境 URL、健康检查 endpoint 和部署状态命令，然后把这些配置写入 CLAUDE.md。这比通用 prompt 更有价值，因为它的目标是沉淀决策，而不是每次都重新追问。

适合做部署配置的场景

当你已经确定应用应该可以部署，但还需要把部署路径厘清并记录下来时，适合用 setup-deploy。它很适合 Fly.io、Render、Vercel、Netlify、Heroku、GitHub Actions 或自定义部署流程。

它和其他方式有什么不同

这个技能的重点是收集配置，而不只是给建议。它的价值在于把部署选择映射到项目记忆里，让后续自动化具备正确上下文。对于有多个环境、状态检查不清晰，或者部署目标需要从现有文件推断的 repo，这一点尤其重要。

什么时候不该用

如果你只是想一次性了解某个示例应用怎么部署，普通 prompt 通常就够了。如果项目已经有完整、稳定的部署规范，而且不需要把配置回写进去，那么 setup-deploy 除了结构化收集信息之外，可能不会带来太多额外价值。

如何使用 setup-deploy 技能

在正确的项目上下文中安装技能

使用仓库里的技能命令安装，然后在需要记录部署设置的项目中运行它。一个典型的 setup-deploy install 流程如下：

npx skills add garrytan/gstack --skill setup-deploy

安装后，要确保代理运行在需要更新 CLAUDE.md 的应用 repo 里，而不是技能仓库本身。

提供部署事实，而不只是目标

setup-deploy usage 的效果最好，前提是你的提示词里包含应用类型、当前托管目标，以及已经知道的发布和健康检查信息。更有质量的输入例如：

• “为一个部署在 Render 上的 Node API 配置部署；生产 URL 是 https://api.example.com；健康检查 endpoint 是 /health；状态命令是 curl -f。”
• “为一个部署在 Vercel 上的 Next.js 应用配置部署；使用 main 分支；把 CI 里已经在用的 deploy check 命令记录下来。”

像“帮我部署一下这个”这样的弱输入，会迫使技能推断太多信息，从而拖慢配置过程。

按这个顺序读取技能文件

先看 SKILL.md，理解动作流程；如果需要了解生成后的技能是怎么拼出来的，再查看 SKILL.md.tmpl。在这个仓库里，没有可以依赖的 rules/、references/ 或 resources/ 目录，所以核心技能文件就是主要事实来源。

按技能设计的工作流来用

setup-deploy guide 应该遵循一条简单路径：识别平台、确认生产端点、确认如何检查部署健康状态，然后持久化结果。如果 repo 里有多个看起来都合理的部署目标，就明确回答这些选项，而不是让代理去猜。确认步骤越扎实，最终写入 CLAUDE.md 的平台或状态命令就越不容易出错。

setup-deploy 技能 FAQ

setup-deploy 只适合完整的部署自动化吗？

不是。setup-deploy for Deployment 的用途比自动化本身更广。它也用于收集最少但足够可靠的部署事实，让后续运行拥有可信上下文。

我需要先知道托管平台吗？

不一定。很多人安装 setup-deploy，就是为了帮助判断项目到底应该走 Fly.io、Render、Vercel、Netlify、Heroku、GitHub Actions，还是自定义路径。如果你已经知道平台，技能执行起来会更快也更精准。

这比普通 prompt 更好吗？

通常是的，尤其当目标是把部署设置记录进 repo，并让后续部署工作可重复时。普通 prompt 可以解释部署思路，但 setup-deploy skill 设计出来就是为了收集正确输入，并把它们写入项目记忆。

安装前应该先检查什么？

看看项目是否已经有现成的部署约定、CI 状态检查，或者必须保留的环境假设。如果这些都没有，这个技能通常更能节省时间；如果这些已经高度标准化，那它可能会显得有些重复。

如何改进 setup-deploy 技能

给技能提供具体的部署证据

提升效果最大的方式，是直接提供准确事实：平台名称、生产 URL、健康检查 endpoint、分支名，以及当前的 deploy 或 status 命令。如果有某一项你不确定，就明确说出你已知的信息，并让技能从 repo 里补全其余部分。

在写入 CLAUDE.md 之前先消除歧义

最常见的失败模式，是根据不完整线索选错目标。如果这个 repo 可能有多种部署方式，就告诉技能哪些信号优先级最高，比如 vercel.json、render.yaml、GitHub Actions workflows，或者现有的 package.json 脚本。

第一轮之后继续迭代

完成第一次 setup-deploy 运行后，检查写入的 CLAUDE.md 条目，看看是否存在平台名称不一致、URL 过时，或者状态检查过于笼统的问题。如果配置范围还是太宽，就再跑一轮，并明确写出你希望保留的具体 service、environment 和 validation command。