review-gha-migration

クイックリファレンス

作業を始める前に、チートシートを取得して読んでください。WebFetch は使用しないでください。重要な詳細が要約され、省略されます。代わりに、Bash で rwx docs pull を実行し、標準出力を直接読んでください。

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

レビュープロセス

GitHub Actions ワークフローの移行によって生成された RWX 設定をレビューします。実装者が見落とした問題を見つけることがあなたの役割です。以前の作業を擁護するのではなく、懐疑的なレビュアーとして取り組んでください。

ステップ 1：ファイルを特定する

ユーザーは RWX 設定のパスを $ARGUMENTS として指定します。パスが指定されていない場合は、.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 を実行し、標準出力を直接読んでください。次の両方を、1 ターン内で並列の 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 を実行するもの）は、独立してキャッシュ可能にするため、別々のタスクにする必要があります。
• トリガーの最適化：トリガーでパスフィルターとブランチフィルターを効果的に使用していますか。

Step 5: 構造を検証する

RWX 設定に構造上の問題がないか確認します。

• 必須フィールドが存在する
• YAML の形式が正しい
• タスクの順序が DAG を反映している（独立したタスクが先）
• 孤立した use 参照がない
• rwx lint .rwx/<name>.yml を実行し、診断内容を確認する

Step 6: レビューを作成する

次のセクションを含む構造化されたレビューを出力します。

Summary：1 行の判定 — この移行は正しく、そのまま使用できるか、変更が必要か。

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 固有の改善点。

blocking の問題が見つかった場合は、直接修正することを申し出てください。