| name | go-live |
| description | 当用户正在构建、修改或 vibe-coding 一个应用、网站、原型或前端页面，并希望每次改动完成后都立刻部署到公开的生产或预览 URL，方便用手机或远程设备查看时使用。触发词包括“上线模式”“改完就上线”“自动部署”“每次改完都部署”“给我一个公开链接”“发我部署链接”“手机能打开的链接”“远程预览”，也包括 "Go Live"、"go live"、"auto deploy" 等类似请求。 |
Go Live
执行原则
把部署视为实现工作的一部分，而不是事后补做的步骤。每次修改应用或网站后，都要交付一个用户能立即打开的公开 URL。
这个 skill 面向手机优先的 vibe coding 场景：用户不一定方便查看 localhost，所以真正可用的预览应该是已部署的公开链接。
工作流程
- 确认正在修改的应用或网站，以及它已有的部署路径。
- 完成用户要求的代码、内容或设计修改。
- 运行当前技术栈里最快且有意义的本地检查，例如 build、lint、typecheck、单元测试或 smoke test。
- 把修改后的应用部署到公开目标。
- 验证已部署的 URL 能打开，并且能看到这次修改后的体验。
- 回复用户公开链接、改了什么，以及验证结果。
部署选择
优先使用项目已有的生产或预览发布流程：
- 如果项目已有 npm scripts、部署配置、CI/CD、Vercel、Netlify、Cloudflare、Firebase、GitHub Pages 或其他项目专用部署方式，就使用现有流程。
- 如果项目已经绑定某个部署平台，就通过该平台发布，不要另起一套部署方式。
- 如果生产部署要求 commit/push，只有在用户要求进行版本控制操作，或部署流程确实需要时，才创建干净的提交。
- 如果项目没有持久化部署配置，就使用当前环境里最快的公开预览方式，并明确说明这是临时预览。
链接标准
除非部署确实被阻塞，最终回复必须包含一个公开 URL。
条件允许时，回复中包括：
- 公开 URL
- 使用的部署平台或命令
- build/check 命令结果
- 简短说明已验证变更页面或路由
如果部署失败，不要只说“失败了”。用清楚的话说明阻塞点，并给出下一步可执行的恢复方式，例如缺少登录授权、项目未绑定、构建失败或部署平台故障。
发布节奏
小需求在改完后部署一次。
较大的需求在每个成型的、用户可见的阶段后部署，至少要在最终回复前部署一次。除非用户明确要求只做本地工作，否则不要只留下 localhost 链接。
约束
- 在检查公开 URL 之前，不要声称部署成功。
- 不要在部署出来的 UI 或最终回复里暴露 secrets、API keys、私有环境变量或私有仓库细节。
- 不要用无关内容覆盖已有生产项目。如果仓库没有明确部署目标，而部署选择可能影响真实生产资产，先暂停并询问用户要部署到哪里。
- 保持推进：如果理想的生产路径被阻塞，就提供最快且安全的公开预览替代方案。
