deployment-composer

部署编排器

根据仓库的实际分支模型、CI 设置、部署提供商和发布风险，组合出最精简且安全的部署工作流。将工作交给专门的技能处理，而不是把每次部署都套用同一份检查清单。

授权范围

只能在用户请求和现有授权范围内操作；加载此技能不会授予任何新权限。仅要求报告时，只提供报告；遵循调用方指定的目标、主机、提供商和成本限制，并将这些限制转达给委派对象。扩展范围前先征求同意。

契约

输入：

• 仓库根目录
• 期望的发布／部署目标
• 可选的目标环境、源分支、目标分支、PR 编号或提供商

输出：

• 部署路径：发布 PR、提供商部署、CI 设置或修复
• 选定的委派技能
• 质量门禁状态
• 仍需满足的确认门槛

创建／修改：

• 发现阶段不创建任何内容
• 可能创建本地发布说明或 PR 正文文件
• 只有在满足 release 的确认规则后，才能通过 release 发布

外部副作用：

• 读取 git/GitHub 元数据和工作流状态
• 可能通过委派技能触发提供商部署命令

需要确认：

• 生产环境部署或合并前
• 用户未明确要求创建 GitHub PR 时，创建 PR 前
• 运行带有生产环境标志的提供商命令前

委派给：

• release
• deploy-app
• github-fix-ci
• ec2-backend-deployer
• testing-cicd-init

组合技能

阶段	用途
release	检查准确的 trunk SHA，然后通过 release-please、受保护的发布工作流或标签发布
deploy-app	通用的预发布／生产部署检查清单、本地质量门禁和部署后监控
github-fix-ci	修复发布或部署 PR 中失败的 GitHub Actions 检查
ec2-backend-deployer	设置 Docker + GitHub Actions + EC2 后端部署
testing-cicd-init	补充缺失或薄弱的 GitHub Actions／测试基础设施
提供商专属技能	在可用时用于 Vercel、Docker、Turborepo、监控或应用专属部署

发现阶段

选择路径前务必先检查：

git status -sb
git remote -v
git branch -r
find . -maxdepth 3 -type f \( -name 'package.json' -o -name 'vercel.json' -o -name 'Dockerfile' -o -name 'docker-compose.yml' -o -name 'docker-compose.yaml' -o -name 'turbo.json' \)
find .github/workflows -maxdepth 1 -type f 2>/dev/null

对于 GitHub 仓库：

gh repo view --json nameWithOwner,defaultBranchRef
gh workflow list

记录：

• 当前分支和工作区是否有未提交更改
• 默认（trunk）分支和远程分支列表
• CI 提供商和必需检查
• 部署提供商：Vercel、EC2/Docker、GitHub Actions、自定义脚本或未知
• 包管理器和质量检查命令
• 环境目标：预览、预发布、生产

路由规则

发布

如果用户希望发布一个版本：

1. 使用 release：它会检查准确的 trunk SHA，并通过仓库自身的发布机制进行发布。
2. staging 和 production 是由 CI／标签驱动的部署环境，不是 git 分支。
3. 如果检查失败，使用 github-fix-ci。

直接部署到提供商

如果用户希望将当前分支／应用部署到某个环境：

1. 使用 deploy-app 执行部署前本地检查和部署后验证。
2. 按提供商设置或执行部署：
   • Vercel 项目：使用 Vercel 专属指南或 CLI。
   • EC2/Docker 后端：使用 ec2-backend-deployer。
   • Turborepo：检查 turbo.json，并在适当时使用受影响范围构建。
   • 未知提供商：操作前检查脚本和工作流文件。
3. 未经明确确认，不得部署到生产环境。

CI 设置或修复

如果仓库没有 CI 或质量门禁薄弱：

1. 使用 testing-cicd-init 添加基线检查。
2. CI 设置完成后使用 deploy-app。
3. 对于现有检查失败，使用 github-fix-ci。

发布说明

如果发布需要面向用户的说明或 PR 正文：

1. 使用 release 的 notes 模式，根据提交历史编写面向用户的说明。
2. 将可见的迁移、环境变量变更和回滚说明纳入内容。

部署工作流

1. 探查仓库拓扑和部署提供方。

2. 根据路由规则选择范围最小的路径。

3. 直接部署前，在仓库指定的主机上运行仓库自身的格式检查、lint 和类型检查脚本（如已配置，也要运行测试和构建）。 切勿猜测或串联使用包管理器；将缺失的脚本报告为覆盖缺口。 发布则依赖 CI 对确切 SHA 的检查（参见 release）。

4. 执行选定的发布或部署路径。

5. 等待远程检查或部署状态。

6. 验证已部署的环境：

   • 健康检查端点
   • 关键页面/API 路径
   • 可用时检查日志或监控

7. 报告最终状态和阻碍。

安全规则

• 切勿隐瞒工作区存在未提交更改；说明本地更改是否属于此次部署。
• 切勿绕过分支保护或必需检查。
• 未经明确确认，切勿合并或部署到生产环境。
• 切勿假设已配置 staging 环境；请验证 CI/部署设置。
• 切勿将跳过或缺失的检查标记为通过。
• 优先使用仓库现有脚本和工作流，不要自行编造新的部署命令。
• 如果无法识别提供方，请在探查后停止，并报告缺失的信息。

输出格式

返回简洁的部署状态：

Deployment route: [release PR / provider deploy / CI setup / repair]
Repository: [owner/repo]
Branches: [source] -> [target] or [current branch]
Provider: [Vercel/EC2/Docker/GitHub Actions/custom/unknown]
Checks: [passing/failing/pending/not configured]
Deployment: [not started/in progress/succeeded/failed]
Verification: [passed/failed/not available]
Needs confirmation: [production merge/deploy, if applicable]