‹ 首页

team-release

@pixel-cellar · 收录于 5 天前 · 上游提交 4 个月前

编排发布团队:协调 release-manager、qa-lead、devops-engineer 和 producer,从候选版本到部署执行完整发布流程。

适合你,如果你需要管理从候选版本到部署的完整发布流程。

/ 通过 npx 安装 校验哈希
npx oh-my-skill add pixel-cellar/claude-code-game-studios/team-release
/ 通过 bash 安装
curl -fsSL https://oh-my-skill.com/install.sh | bash -s -- pixel-cellar/claude-code-game-studios/team-release
/ 已经装过?验证本机副本,不用重装
npx oh-my-skill verify pixel-cellar/claude-code-game-studios/team-release
安装目标可用 --agent / --scope 或 --to 明确指定;省略时只会在唯一已存在的 agent 目录上自动选择,零命中或多命中会停止并提示。content_hash 缺失或不一致均拒装。
273GitHub stars
~1.2K上下文体积 · 单文件
索引托管

怎么用

商店整理自技能原文 · 版本 2c016ef · 表述以原文为准
它做什么

Claude 会编排发布团队,协调 release-manager、qa-lead、devops-engineer 和 producer 四个角色,从候选版本到部署执行完整的发布流程,包括规划、质量门禁、放行决策和部署。

什么时候触发

当你调用该技能时触发,通常你会提供版本号或指定 'next' 来启动发布流程。

装好后可以这样说
启动发布规划阶段。
执行阶段2:候选版本创建。
并行运行 QA 和 DevOps 测试。
技能原文 SKILL.md作者撰写 · MIT · 2c016ef

当此技能被调用时,通过结构化管线编排发布团队。

决策点: 在每个阶段转换时,使用 AskUserQuestion 将子代理的提案以可选项的形式呈现给用户。在对话中展示代理的完整分析,然后用简洁的标签记录决策。用户必须批准后才能进入下一阶段。

团队构成
  • release-manager — 发布分支、版本管理、变更日志、部署
  • qa-lead — 测试签收、回归测试套件、发布质量门禁
  • devops-engineer — 构建管线、产物、部署自动化
  • producer — 放行/中止决策、利益相关者沟通、排期
委派方式

使用 Task 工具将每位团队成员作为子代理启动:

  • subagent_type: release-manager — 发布分支、版本管理、变更日志、部署
  • subagent_type: qa-lead — 测试签收、回归测试套件、发布质量门禁
  • subagent_type: devops-engineer — 构建管线、产物、部署自动化
  • subagent_type: producer — 放行/中止决策、利益相关者沟通

始终在每个代理的提示中提供完整上下文(版本号、里程碑状态、已知问题)。在管线允许的情况下并行启动独立代理(例如,阶段 3 的代理可以同时运行)。

管线
阶段 1:发布规划

委派给 producer

  • 确认所有里程碑验收标准均已满足
  • 识别从本次发布中推迟的范围项
  • 设定目标发布日期并通知团队
  • 输出:附带范围确认的发布授权
阶段 2:候选版本(Release Candidate)

委派给 release-manager

  • 从约定的提交切出发布分支
  • 在所有相关文件中递增版本号
  • 使用 /release-checklist 生成发布检查清单
  • 冻结分支——不再接受功能变更,仅允许缺陷修复
  • 输出:发布分支名称和检查清单
阶段 3:质量门禁(并行)

并行委派:

  • qa-lead:执行完整回归测试套件。测试所有关键路径。确认不存在 S1/S2 级别缺陷。签收质量。
  • devops-engineer:为所有目标平台构建发布产物。验证构建干净且可复现。在 CI(持续集成)中运行自动化测试。
阶段 4:本地化与性能

委派(如果资源允许,可与阶段 3 并行运行):

  • 验证所有字符串已完成翻译(如可用,委派给 localization-lead)
  • 针对性能目标运行基准测试(如可用,委派给 performance-analyst)
  • 输出:本地化和性能签收
阶段 5:放行/中止决策

委派给 producer

  • 收集以下人员的签收:qa-lead、release-manager、devops-engineer、technical-director
  • 评估所有未解决的问题——是阻塞项还是可以随版本发布?
  • 做出放行/中止决策
  • 输出:附带理由的发布决策
阶段 6:部署(如通过)

委派给 release-manager + devops-engineer

  • 在版本控制中打标签
  • 使用 /changelog 生成变更日志
  • 部署到预发布环境进行最终冒烟测试
  • 部署到生产环境
  • 发布后监控 48 小时
阶段 7:发布后
  • release-manager:生成发布报告(已发布内容、已推迟内容、度量数据)
  • producer:更新里程碑跟踪,通知利益相关者
  • qa-lead:监控接收到的缺陷报告,排查回归问题
  • 如果出现问题,安排发布后复盘
输出

涵盖以下内容的总结报告:发布版本、范围、质量门禁结果、放行/中止决策、部署状态和监控计划。

按 MIT 许可原样转载,未经改动 · 在 GitHub 查看 →

评论

登录即可评论;带「已验证安装」的,是发布者名下有本店的安装或持有记录。