review-gha-migration

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Quick Reference

快速参考

Fetch and read the cheat sheet before starting. Do NOT use WebFetch — it summarizes and drops critical details. Instead, use Bash to run

rwx docs pull

and read stdout directly:

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

开始前请获取并阅读速查表。请勿使用WebFetch——它会进行摘要并遗漏关键细节。请改用Bash运行

rwx docs pull

并直接读取标准输出：

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

Review Procedure

审查流程

You are reviewing an RWX config that was generated from a GitHub Actions workflow migration. Your job is to catch problems the implementer missed. Approach this as a skeptical reviewer, not as someone defending prior work.

你需要审查一份从GitHub Actions工作流迁移生成的RWX配置。你的任务是找出实施者遗漏的问题。请以持怀疑态度的审查者身份开展工作，而非为之前的工作辩护。

Step 1: Identify the files

步骤1：确定文件

The user provides the RWX config path as

$ARGUMENTS

. If no path is provided, list the files in

.rwx/

and ask the user which config to review.

Then locate the corresponding source GitHub Actions workflow. Look for clues:

Comments in the RWX config referencing the source file
Filename correspondence (e.g.,
```
.rwx/ci.yml
```
likely came from
```
.github/workflows/ci.yml
```
)
Ask the user if the source is ambiguous

Read both files in full.

用户会将RWX配置路径作为

$ARGUMENTS

提供。如果未提供路径，请列出

.rwx/

目录下的文件并询问用户要审查哪个配置。

然后找到对应的源GitHub Actions工作流。可以通过以下线索查找：

RWX配置中引用源文件的注释
文件名对应关系（例如，
```
.rwx/ci.yml
```
大概率来自
```
.github/workflows/ci.yml
```
）
如果源文件不明确，请询问用户

完整阅读这两个文件。

Step 2: Inventory the source workflow

步骤2：梳理源工作流

Build a checklist from the GitHub Actions workflow. For each item, you will verify it was correctly translated. Extract:

Every job and its
```
needs:
```
dependencies
Every step within each job (name + what it does)
All triggers and their configurations (branches, paths, event types)
Every secret referenced
Every environment variable (workflow, job, and step level)
Matrix strategies and their dimensions
Services (databases, caches, etc.)
Artifact upload/download pairs
Caching steps
Composite action references
Reusable workflow calls
Conditional logic (
```
if:
```
expressions)
Timeout and concurrency settings

根据GitHub Actions工作流制作一份检查清单。对于每一项，你需要验证它是否被正确转换。提取以下内容：

每个Job及其
```
needs:
```
依赖关系
每个Job中的每一步（名称+具体操作）
所有触发器及其配置（分支、路径、事件类型）
所有引用的密钥（Secret）
所有环境变量（工作流、Job和步骤级别）
矩阵策略及其维度
服务（数据库、缓存等）
工件上传/下载对
缓存步骤
复合Action引用
可复用工作流调用
条件逻辑（
```
if:
```
表达式）
超时和并发设置

Step 3: Verify behavioral equivalence

步骤3：验证行为等价性

Go through your checklist item by item and verify each one is accounted for in the RWX config. For each item, classify it as:

Correct — properly translated to the RWX equivalent
Missing — not present in the RWX config and no TODO comment explaining why
Wrong — translated but with a semantic difference that changes behavior
Degraded — works but lost important properties (e.g., a parallel job became sequential)

Pay special attention to:

Steps that were silently dropped during migration
```
if:
```
conditionals that were lost or simplified incorrectly
Environment variables that were not carried over
Secrets that are referenced but not mapped
Matrix dimensions that were flattened or lost
Service containers that have no equivalent
Artifact passing between jobs that was not preserved

逐项检查你的清单，验证每一项是否在RWX配置中得到体现。对于每一项，将其归类为：

正确——已正确转换为RWX等效内容
缺失——RWX配置中不存在且无TODO注释说明原因
错误——已转换但存在语义差异，导致行为改变
降级——可运行但丢失了重要属性（例如，并行Job变为串行）

特别注意以下内容：

迁移期间被静默删除的步骤
丢失或被错误简化的
```
if:
```
条件
未被继承的环境变量
被引用但未映射的密钥（Secret）
被扁平化或丢失的矩阵维度
无等效内容的服务容器
未被保留的Job间工件传递

Step 4: Verify RWX optimizations

步骤4：验证RWX优化

If you don't already have the reference documentation in context, fetch it now. Do NOT use WebFetch — it summarizes and drops critical details. Instead, use Bash to run

rwx docs pull

for each doc and read stdout directly. Run both in a single turn as parallel Bash calls:

rwx docs pull /docs/rwx/migrating/rwx-reference

— full RWX config syntax

rwx docs pull /docs/rwx/migrating/gha-reference

— GHA-to-RWX concept mapping

If you encounter a question not covered by these references, use

rwx docs search "<query>"

to find the relevant documentation page, then

rwx docs pull

the result.

Using the reference documentation, check whether the config takes full advantage of RWX capabilities:

DAG structure: Are tasks that can run in parallel actually parallel, or are there unnecessary sequential dependencies?
Content-based caching: Are cache keys content-based (not hash-based) where possible?
Package substitution: Are there
```
run:
```
steps installing tools that have RWX package equivalents?
Task granularity: Could large monolithic tasks be split into parallel subtasks?
Trigger optimization: Are triggers using path filters and branch filters effectively?

如果你还没有相关参考文档，请立即获取。请勿使用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包等效项？
任务粒度：大型单体任务是否可以拆分为并行子任务？
触发器优化：触发器是否有效使用了路径过滤器和分支过滤器？

Step 5: Validate structure

步骤5：验证结构

Check the RWX config for structural issues:

Required fields are present
YAML is well-formed
Task ordering reflects the DAG (independent tasks first)
No orphaned
```
use
```
references
Run
```
rwx lint .rwx/<name>.yml
```
and review the diagnostics

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

是否存在必填字段
YAML格式是否规范
任务顺序是否反映DAG结构（独立任务优先）
是否存在孤立的
```
use
```
引用
运行
```
rwx lint .rwx/<name>.yml
```
并审查诊断结果

Step 6: Produce the review

步骤6：生成审查报告

Output a structured review with these sections:

Summary: One-line verdict — is this migration correct and ready, or does it need changes?

Issues (if any): A numbered list of problems found, each with:

Severity:
```
blocking
```
(must fix before using) or
```
suggestion
```
(improvement opportunity)
What's wrong
Where in the RWX config it occurs
What the fix should be

Checklist: A markdown checklist showing each source workflow item and whether it was correctly translated:

- [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: Any RWX-specific improvements not yet applied.

If you find blocking issues, offer to fix them directly.

输出包含以下部分的结构化审查报告：

摘要：一句话结论——此次迁移是否正确且可投入使用，还是需要修改？

问题（如有）：发现的问题编号列表，每个问题包含：

严重程度：
```
blocking
```
（使用前必须修复）或
```
suggestion
```
（优化机会）
问题内容
问题在RWX配置中的位置
修复方案

检查清单：Markdown格式的检查清单，显示源工作流的每一项是否被正确转换：

- [x] Job: build — 已正确转换为任务`build`
- [ ] Job: deploy — 缺失，无TODO注释
- [x] Trigger: push to main — 已正确映射
- [ ] Secret: DEPLOY_KEY — 被引用但未在密钥映射中

优化机会：尚未应用的RWX特定改进建议。

如果发现阻塞性问题，可主动提出直接修复。