add delivery workflow skills

This commit is contained in:
2026-10-12 20:34:20 +08:00
parent c9faedc39d
commit ab29598a9a
13 changed files with 339 additions and 0 deletions
+23
View File
@@ -0,0 +1,23 @@
# pr-ship
把已有 PR 从检查和合并推进到合并后完整回归、构建和部署。
## 什么时候使用
```text
处理当前 PR,确认 CI 后合并,跑完整回归并部署测试环境。
```
## 使用前准备
- PR/MR 链接或当前分支上下文。
- 审核、CI、目标分支和部署 profile 可被读取。
- 需要生产部署时,当前请求必须覆盖该动作。
## Agent 会做什么
先检查 PR 是否可合并;合并后重新以目标分支 commit 回归和构建,再按配置继续发布或部署。
## 如何判断完成
报告会给出合并 commit,而不是只给源分支 commit,并附完整回归、产物和部署证据。
+45
View File
@@ -0,0 +1,45 @@
---
name: pr-ship
description: >-
处理已有 PR/MR:检查差异、审核和 CI,必要时修复阻塞项,合并后以合并 commit 做完整回归,
再按配置构建、发布和部署。用户说处理、合并、回归或发布 PR 时使用。
---
# PR Ship:合并后的完整交付
重点是合并后的真实状态:PR 分支通过不代表目标分支已回归,也不代表产物和生产已更新。
## 何时使用
- 用户提供 PR/MR 或要求处理当前 PR。
- 用户要求合并 PR 后完整回归并部署。
## 不适用
- 没有 PR、需要从零修 bug:使用 `bugfix-ship`。
- 复杂需求尚未形成批准 PRD:使用 `specifier` 和 `requirement-flow`。
- 只做 diff 审查、不合并:使用 `check`。
## 工作规则
1. 读取 PR 的目标/源分支、差异、关联任务、审核状态、CI、冲突和变更风险;使用 `check`。
2. 审核、CI 或必需检查缺失时停止。若发现可修复问题,只有当前请求明确包含修复时才在 PR 分支上处理,
然后重新验证;不能静默改变 PR 范围。
3. 具备合并条件后执行合并,并重新获取目标分支;记录合并后的 commit,后续所有回归和构建都以它为来源。
4. 读取并执行 `delivery-loop` 的状态机,运行完整回归;失败时停在合并后的中间状态或回到修复流程,不部署失败版本。
5. 只有项目 profile 和当前授权允许时才构建、发布和部署;生产部署完成后做节点状态和关键路径检查。
## 安全门
- 不绕过审核、CI、分支保护或冲突;不强推、不重写已共享历史。
- 不用 PR 源分支的旧 APK/镜像证明合并版本已发布。
- 目标分支变化、合并后代码漂移、回归失败、产物来源不明或部署健康检查失败时停止。
## 必读资料
- 执行交付阶段时读取已安装的 `delivery-loop` skill 及其状态机 reference。
- 发布版本时遵循 `releaser`;构建/部署/回归分别遵循 `builder`、`deployer`、`tester`。
## 完成报告
报告 PR/MR、审核/CI 结果、合并 commit、完整回归证据、产物摘要、tag、部署目标、健康检查和回滚点。
+6
View File
@@ -0,0 +1,6 @@
interface:
display_name: "PR Ship"
short_description: "Merge, regress, build, and deploy a PR"
default_prompt: "Use $pr-ship to process this PR through merge, full regression, and the configured deployment stop."
policy:
allow_implicit_invocation: true