mcpField
R
review-gha-migration

review-gha-migration

github.com/rwx-cloud测试与质量366 次安装1 周前更新
代码仓库

关于 review-gha-migration

review-gha-migration 是一项技能,用于审慎审查由 GitHub Actions 工作流迁移生成的 RWX 配置。它比对行为、检查 RWX 结构与优化空间,并输出问题分类和核对清单。

主要功能

  1. 01梳理任务、触发器与工作流设置
  2. 02比对源工作流与 RWX 配置行为
  3. 03检查 RWX 语法和结构
  4. 04发现 RWX 优化机会
  5. 05输出按严重性分类的问题和清单

适用场景

  1. 01审查 GHA 迁移后的 RWX 配置
  2. 02查找遗漏的密钥或工作流步骤
  3. 03检查任务并行度和缓存设置

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/rwx-cloud/skills --skill review-gha-migration

安装后在 Claude Code 中输入/review-gha-migration确认已加载。

详细介绍

快速参考

开始前,先获取并阅读速查表。不要使用 WebFetch——它会总结内容并遗漏关键细节。请改用 Bash 运行 rwx docs pull,并直接阅读标准输出:

rwx docs pull /docs/rwx/migrating/gha-cheat-sheet

审查流程

你正在审查从 GitHub Actions 工作流迁移而生成的 RWX 配置。你的任务是找出实施者遗漏的问题。请以审慎的审查者身份进行检查,而不是为之前的工作辩护。

步骤 1:确定文件

用户会通过 $ARGUMENTS 提供 RWX 配置路径。如果没有提供路径,请列出 .rwx/ 中的文件,并询问用户要审查哪个配置。

然后找到对应的源 GitHub Actions 工作流。查找以下线索:

  • RWX 配置中引用源文件的注释
  • 文件名对应关系(例如,.rwx/ci.yml 可能来自 .github/workflows/ci.yml)
  • 如果源文件不明确,请询问用户

完整读取这两个文件。

步骤 2:盘点源工作流

根据 GitHub Actions 工作流制定检查清单。逐项验证其是否已正确转换。提取以下内容:

  • 每个作业及其 needs: 依赖项
  • 每个作业中的所有步骤(名称及其作用)
  • 所有触发条件及其配置(分支、路径、事件类型)
  • 所有引用的密钥
  • 所有环境变量(工作流、作业和步骤级别)
  • 矩阵策略及其维度
  • 服务(数据库、缓存等)
  • 工件上传/下载配对
  • 缓存步骤
  • 复合操作引用
  • 可复用工作流调用
  • 条件逻辑(if: 表达式)
  • 超时和并发设置
步骤 3:验证行为等效性

逐项检查清单,并验证 RWX 配置中是否已涵盖每一项。将每项归类为:

  • 正确——已正确转换为对应的 RWX 功能
  • 缺失——RWX 配置中未包含,且没有 TODO 注释说明原因
  • 错误——已转换,但存在会改变行为的语义差异
  • 降级——可以运行,但丢失了重要特性(例如,并行作业变成了串行作业)

请特别留意:

  • 迁移过程中被悄然删除的步骤
  • 丢失或简化错误的 if: 条件
  • 未沿用的环境变量
  • 已引用但未映射的密钥
  • 被展开或丢失的矩阵维度
  • 没有对应项的服务容器
  • 未保留的作业间工件传递
步骤 4:验证 RWX 优化

如果上下文中尚无参考文档,请现在获取。不要使用 WebFetch——它会总结内容并遗漏关键细节。请改用 Bash 运行每个文档的 rwx docs pull,并直接阅读标准输出。请在同一轮中并行调用 Bash,运行以下两条命令:

  • rwx docs pull /docs/rwx/migrating/rwx-reference——完整的 RWX 配置语法
  • rwx docs pull /docs/rwx/migrating/gha-reference——GHA 到 RWX 的概念映射

如果遇到这些参考文档未涵盖的问题,请使用 rwx docs search "<query>" 查找相关文档页面,然后对搜索结果运行 rwx docs pull。

根据参考文档,检查配置是否充分利用 RWX 的功能:

  • DAG 结构:可以并行运行的任务是否确实并行运行,还是存在不必要的串行依赖?
  • 基于内容的缓存:在可行的情况下,缓存键是否基于内容(而非哈希)?
  • 软件包替换:是否有安装工具的 run: 步骤可以使用 RWX 软件包来替代?
  • 任务粒度:大型单体任务是否可以拆分为可并行运行的子任务?尤其要指出同时包含安装命令和构建命令的安装任务(例如,先运行 npm ci,再运行 npm run build)——这些应拆分为独立任务,以便分别进行缓存。
  • 触发器优化:是否有效使用了路径筛选和分支筛选来设置触发器?
第 5 步:验证结构

检查 RWX 配置是否存在结构问题:

  • 必填字段是否齐全
  • YAML 格式是否正确
  • 任务顺序是否符合 DAG(先列出独立任务)
  • 是否存在没有对应定义的 use 引用
  • 运行 rwx lint .rwx/<name>.yml 并检查诊断信息
第 6 步:生成审查结果

输出一份结构化审查结果,包含以下部分:

Summary:用一句话给出结论——此次迁移是否正确且已准备就绪,还是需要修改?

Issues(如有):以编号列表列出发现的问题,每项包括:

  • 严重程度:blocking(使用前必须修复)或 suggestion(改进建议)
  • 问题所在
  • 问题在 RWX 配置中的位置
  • 应如何修复

Checklist:使用 Markdown 复选框清单列出每项源工作流内容及其是否已正确转换:

- [x] Job: build — correctly translated as task `build`
- [ ] Job: deploy — missing, no TODO comment
- [x] Trigger: push to main — correctly mapped
- [ ] Secret: DEPLOY_KEY — referenced but not in secrets mapping

Optimization opportunities:尚未应用的 RWX 专属改进建议。

如果发现阻塞性问题,请提出直接修复。

评论

支持 Markdown