はじめに
iOSのコードレビューは、毎回確認すべき観点が地味に多いです。
チケット要件と実装が合っているか、force unwrap や nil 参照でクラッシュしないか、retain cycle や Combine の購読解除漏れはないか、iOS 15 でも動くか、既存機能への影響はないか、VoiceOver や Dynamic Type に響かないか、テスト項目や受け入れ基準が整理できているか。
このあたりを毎回手で確認していると、レビュー担当者によって確認の粒度がぶれます。「見たけど問題なかった」のか「そもそも見ていない」のか、レポートからは区別がつかないことも多いです。
そこで、iOSコードレビュー用のCodex Skillとして review-and-fix を作りました。
このSkillは、指定したコミット範囲を対象に、Redmineチケット情報の確認、コードレビュー、重大・高リスク問題の修正、Xcodeビルド確認、テスト項目作成、受け入れ基準作成、レポート保存、Slack通知までを1つの流れとして定義しています。
本記事は Codex CLI の Skill 機能を前提にしています。Codex の Skill は ~/.agents/skills/（リポジトリ配下なら .agents/skills/）に SKILL.md を置くと、$skill名 での明示呼び出し、または description にマッチしたときの自動呼び出しで読み込まれます。Skill 機能は導入当初フィーチャーフラグ管理だったため、トリガーされない場合は後述の有効化手順を確認してください。
対象読者
- CodexでiOSコードレビューを効率化したい人
- レビュー観点をチーム内で標準化したい人
- RedmineチケットとGit差分を照合してレビューしたい人
- レビュー結果・テスト項目・受け入れ基準を毎回同じ形式で出したい人
- RedmineやSlackをMCP経由でCodexから扱う運用に興味がある人
- Codex Skillの具体的な作成例を見たい人
今回作るもの
作るSkillは review-and-fix です。役割はこうです。
指定したコミット範囲を対象に、
Redmineチケット情報を確認し、
iOS観点でコードレビューし、
重大・高リスクの問題があれば修正し、
ビルド確認し、
テスト項目・受け入れ基準・最終レポートを保存し、
Slackへ完了通知する。
主な成果物は次の3つです。
~/Documents/test-cases/{チケット番号}/{チケット番号}_テスト項目.md
~/Documents/test-cases/{チケット番号}/{チケット番号}_レポート.md
~/Documents/test-cases/{チケット番号}/{チケット番号}_受け入れ基準.md
Codex Skillにする理由
Skillとして定義しておくと、レビュー手順を毎回プロンプトに貼り直す必要がなくなります。
Skill内に、Skill名・説明・入力仕様・レビュー観点・リスク評価基準・修正方針・ビルド確認ルール・テスト項目の出力形式・受け入れ基準の作成ルール・最終レポートの形式・Slack通知の形式を、まとめて固定できます。
レビューは属人化しやすい作業です。レビューの型をSkillとして固定すれば、確認観点の抜け漏れを減らし、品質を平準化しやすくなります。
前提
この記事は以下を前提にしています。
- Codex CLIを利用できる
- 対象のiOSプロジェクトをローカルで操作できる
- Gitのコミット範囲を指定できる
- Xcodeビルドをローカルで実行できる
- RedmineとSlackをMCP経由で利用できる環境がある
RedmineやSlackのMCP環境がなくても、コード差分レビュー・テスト項目作成・受け入れ基準作成・レポート保存までは動きます。その場合、Redmineチケット取得とSlack通知は「失敗時の分岐」として扱う設計にしています。
ディレクトリ構成
個人用Skillとして、~/.agents/skills 配下に置きます。
~/.agents/skills/review-and-fix/
└── SKILL.md
Skill作成コマンド
以下をターミナルにまとめて貼り付けて実行すると、SKILL.md が作成されます。cat << 'EOF' から最後の EOF までを一括で貼り付けてください。
外側を4バッククォートで囲っているのは、SKILL.md 内部にコードブロック（3バッククォート）が含まれるためです。
mkdir -p ~/.agents/skills/review-and-fix
cat << 'EOF' > ~/.agents/skills/review-and-fix/SKILL.md
---
name: review-and-fix
description: iOSアプリのコミット範囲をRedmineチケットと照合し、コードレビュー、重大/高リスク修正、Xcodeビルド、テスト項目、受け入れ基準、最終レポート作成、Slack通知まで実施する。ユーザーが「レビューして修正」「review-and-fix」「Redmineチケットと差分をレビュー」「iOS差分レビュー」などを依頼したときに使用する。
---
# review-and-fix
あなたは熟練した iOS コードレビュー担当です。
Swift / Objective-C / SwiftUI / UIKit / Xcode / 署名 / 依存関係管理 / 配布 / App Store 審査まで理解している前提で対応してください。
## 入力の扱い
ユーザーの依頼文から以下を特定してください。
- コミット範囲: `..` を含む要素。例: `abc12345..def67890`, `origin/main..HEAD`
- チケット番号: `TICKET_ID=408408`, `#408408`, `408408` など
- チケット番号が明示されていない場合は、コミット範囲の `git log` から抽出する
実行例:
```text
$review-and-fix abc12345..def67890
```
この形式では、`abc12345..def67890` をコミット範囲として扱い、チケット番号は対象コミットのメッセージから抽出してください。
チケット番号を明示する場合:
```text
$review-and-fix COMMIT_RANGE=abc12345..def67890 TICKET_ID=408408
```
ブランチ名を使う場合:
```text
$review-and-fix origin/develop..HEAD
```
## 重要ルール
- 入力に存在しない事実を前置しない
- 不明な項目は「未確認」と明記する
- 推測は必ず「(推測です)」と明記する
- Redmine / Slack は利用可能な MCP ツールがある場合のみ使用する
- MCPツール名を決め打ちしない。利用可能なMCPツール一覧から、Redmine・Slackに対応するツールを特定して使用する
- RedmineまたはSlackのMCPが利用できない場合は、その旨を報告し、可能な範囲で処理を継続する
- 重大・高リスク以外の修正は、ユーザーから追加指示がない限り実施しない
- 元のコード意図を尊重し、修正は最小限にする
- 作業前に現在のブランチ、未コミット差分、コミット範囲を確認する
- 既存の未コミット差分がある場合は、ユーザーの変更を破壊しないように扱う
---
# Step 1: チケット番号の特定とRedmineチケット内容の確認
1. ユーザー入力からコミット範囲を特定する。
- `COMMIT_RANGE=...` があればそれを使う
- なければ `..` を含む要素をコミット範囲として扱う
- 例: `abc12345..def67890`
2. チケット番号を特定する。
- `TICKET_ID=...` があればそれを使う
- `#408408` のような形式があれば数値部分を使う
- 明示的なチケット番号がない場合は、以下のようにレビュー対象コミットのメッセージから抽出する
```bash
git log --format=%s <コミット範囲>
```
注意:
- `A..B` の場合、開始コミット `A` は基点でありレビュー対象外
- `git log A..B` の対象コミットメッセージのみからチケット番号を抽出する
- チケット番号が複数ある場合は、最初に見つかったものを使用する
- 単なる数値を安易にチケット番号と断定しない
- `#123456`、`refs #123456`、`Redmine 123456`、`チケット 123456` など、チケット文脈があるものを優先する
3. 特定したチケット番号でMCP経由でRedmineからチケット情報を取得する。
4. 以下を日本語で要約する。
- チケットのタイトル・概要
- 改修の目的・背景
- 受け入れ条件（記載がある場合）
- 関連チケット（記載がある場合）
- RedmineのベースURL（取得できる場合）
5. チケット番号が見つからない場合、またはRedmineからの取得に失敗した場合は、以下を報告する。
```text
チケット情報の取得に失敗しました
```
その場合、Step 2以降はコード差分のみで判断する。
---
# Step 2: コードレビュー
1. コミット範囲の差分を取得する。
```bash
git diff --stat <コミット範囲>
git diff --name-only <コミット範囲>
git diff <コミット範囲>
```
2. Step 1で取得できたチケットの目的・受け入れ条件と照らし合わせてレビューする。
3. 以下の必須チェック観点を全て確認する。
該当なしの場合も、必ず「該当なし」と明記する。
## 必須チェック観点
1. **チケット要件との整合性**: Step 1 のチケット目的・受け入れ条件を満たしているか
2. **クラッシュリスク**: force unwrap、配列範囲外アクセス、nil 参照、メインスレッド違反
3. **メモリリスク**: retain cycle、weak/unowned の使い分け、Combine の sink 解放漏れ
4. **iOSバージョン互換**: iOS 15 で動作するか、@available 漏れがないか
5. **既存コードへの影響**: 呼び出し元・呼び出し先への影響範囲
6. **テスタビリティ**: 単体テストが書ける構造か
7. **命名・可読性**: Swift API Design Guidelines への準拠
8. **エラーハンドリング**: do-catch の網羅性、Result 型の活用
9. **非同期処理**: async/await の適切な使用、Task のキャンセル考慮
10. **アクセシビリティ**: VoiceOver、Dynamic Type 対応への影響
## リスク評価基準
問題点は以下の基準で分類する。
- 🔴 重大: 起動不能、重大クラッシュ、署名や Bundle ID の重大不整合、重大な審査リスク
- 🟠 高: 権限設定不備の可能性が高い、広範囲回帰、依存関係の破壊的変更
- 🟡 中: 局所的回帰、保守性低下、異常系の懸念、運用リスク
- 🟢 低: 影響範囲が限定的で、入力上は重大な懸念が確認できない
---
# Step 3: コード修正
- 🔴 重大 または 🟠 高 の問題について修正を実施する
- 修正は最小限にする
- 既存仕様が不明な場合は「未確認」と明記し、危険な修正は避ける
- 修正後、変更ファイル一覧と差分要約を確認する
```bash
git diff --name-only
git diff
```
修正内容を日本語で報告する。
---
# Step 4: ビルド確認
1. リポジトリのビルド方法を確認する。
- `AGENTS.md`
- `README.md`
- `.xcodeproj`
- `.xcworkspace`
- `Package.swift`
- 既存のCI設定
- `xcodebuild -list`
2. Xcodeでビルドを実行する。
優先順位:
- リポジトリにビルド手順が明記されている場合は、それに従う
- `.xcworkspace` がある場合は workspace を優先する
- `.xcodeproj` のみの場合は project を使う
- scheme が複数あり判断できない場合は「未確認」として報告する
3. ビルドエラーがあれば修正を試み、再度ビルドする。
4. ビルド試行は最大3回まで。
3回失敗した場合は以下を報告して次のStepに進む。
- 最後のエラーメッセージ全文
- 試した修正内容の履歴
- 推測される原因（「(推測です)」と明記）
- 人間によるデバッグが必要である旨
5. 最終的なビルド結果を報告する。
---
# Step 5: テスト項目作成
改修内容およびStep 1のチケット情報に基づき、以下の観点でテストケースを作成する。
## 正常系
- 改修で追加・変更された機能が期待通り動作するケース
- チケットの受け入れ条件を満たすケース
## 異常系
- 不正な入力、ネットワークエラー、未認証状態など異常条件でのケース
## 回帰テスト
- 改修の影響範囲にある既存機能が壊れていないことを確認するケース
## 出力形式
以下のMarkdown表で出力する。
| # | 分類 | テスト項目 | 操作手順 | 期待結果 | 優先度 |
|---|------|-----------|---------|---------|-------|
優先度は以下で分類する。
- 🔴 P0（必須）
- 🟡 P1（重要）
- 🟢 P2（推奨）
改修差分から読み取れる範囲のみ記載し、推測は「(推測です)」と明記する。
---
# Step 6: 受け入れ基準の作成
Step 1 のチケット情報と Step 2 のコード差分に基づき、このチケットの受け入れ基準を作成する。
## 作成ルール
- チケットに既存の受け入れ基準がある場合は、それをベースに不足分を補完する
- 既存の受け入れ基準がない場合は、新規に作成する
- 実装内容から確認すべき動作条件を箇条書きで列挙する
- 技術的な補足が必要な項目には「Note:」を付記する
- 確認方法が未確定の項目には「[TBD]」を付記する
- Redmineのチケットにそのまま貼り付けられる形式で出力する
## 観点
- 改修で追加・変更された機能が正しく動作すること
- アプリの状態別（フォアグラウンド／バックグラウンド／プロセス無し）の動作
- 既存ユーザーへの影響（アップデート時の挙動）
- 異常系での動作（通信断、不正値など）
- 既存機能への回帰影響
---
# Step 7: 最終レポート
以下の構成で最終結果をMarkdownとしてまとめる。
## 最終レポート
### チケット情報
- チケット番号:
- タイトル:
- コミット範囲:
### レビュー結果
| # | リスク | 観点カテゴリ | ファイル:行 | 問題内容 | 推奨対応 | 修正実施 |
|---|--------|------------|-----------|---------|---------|---------|
ルール:
- 「観点カテゴリ」は Step 2 の必須チェック観点 1〜10 のいずれかを記載する
- 「修正実施」は ✅ / ❌ / -（対象外）で記載する
- 問題が1件もない場合は、表の代わりに「該当なし」と明記する
### 実施した修正
- 修正内容の一覧
- Before/After のコード差分を含める
### ビルド結果
- ✅ 成功 または ❌ 失敗
- 失敗の場合は最後のエラーメッセージを併記する
### 残課題
- あれば記載
- なければ「なし」と明記する
---
# Step 8: テスト項目をファイルに保存
1. Step 5 で作成したテストケースをMarkdownファイルとして保存する。
2. 保存用IDを決定する。
- チケット番号が特定できた場合: チケット番号を使う
- チケット番号が見つからなかった場合: `test-cases-YYYYMMDD-HHmmss` を使う
3. 保存先:
```text
~/Documents/test-cases/{保存用ID}/
```
4. ファイル名:
- チケット番号あり: `{チケット番号}_テスト項目.md`
- チケット番号なし: `{保存用ID}_テスト項目.md`
例:
```text
~/Documents/test-cases/408408/408408_テスト項目.md
```
5. 同名ファイルが既に存在する場合は、以下の形式にする。
```text
{保存用ID}_テスト項目-YYYYMMDD-HHmmss.md
```
6. 保存先ディレクトリが存在しない場合は `mkdir -p` で作成する。
7. ファイルの冒頭にチケット番号とコミット範囲を記載する。
8. 保存完了後、ファイルの絶対パスを報告する。
---
# Step 9: 最終レポートをファイルに保存
1. Step 7 で構成した最終レポートを別ファイルとして保存する。
2. 保存先:
```text
~/Documents/test-cases/{保存用ID}/
```
3. ファイル名:
- チケット番号あり: `{チケット番号}_レポート.md`
- チケット番号なし: `{保存用ID}_レポート.md`
例:
```text
~/Documents/test-cases/408408/408408_レポート.md
```
4. 同名ファイルが既に存在する場合は、以下の形式にする。
```text
{保存用ID}_レポート-YYYYMMDD-HHmmss.md
```
5. 保存完了後、ファイルの絶対パスを報告する。
---
# Step 10: 受け入れ基準をファイルに保存
1. Step 6 で作成した受け入れ基準を別ファイルとして保存する。
2. 保存先:
```text
~/Documents/test-cases/{保存用ID}/
```
3. ファイル名:
- チケット番号あり: `{チケット番号}_受け入れ基準.md`
- チケット番号なし: `{保存用ID}_受け入れ基準.md`
例:
```text
~/Documents/test-cases/408408/408408_受け入れ基準.md
```
4. 同名ファイルが既に存在する場合は、以下の形式にする。
```text
{保存用ID}_受け入れ基準-YYYYMMDD-HHmmss.md
```
5. 保存完了後、ファイルの絶対パスを報告する。
6. 最後に以下を案内する。
```text
内容を確認の上、Redmineのチケットに貼り付けてください。
```
---
# Step 11: Slackへの完了通知
MCP経由でSlackに完了通知を送信する。
## 送信先
```text
D3225KYB1
```
## メッセージ形式
Redmineのチケット情報とベースURLが取得できた場合:
```text
<{RedmineのベースURL}/issues/{チケット番号}|#{チケット番号}「{チケットタイトル}」> のレビューが完了しました。
成果物:
• {チケット番号}_テスト項目.md（テスト項目）
• {チケット番号}_レポート.md（最終レポート）
• {チケット番号}_受け入れ基準.md（受け入れ基準）
```
RedmineのベースURLが取得できない場合:
```text
#{チケット番号}「{チケットタイトル}」のレビューが完了しました。
成果物:
• {チケット番号}_テスト項目.md（テスト項目）
• {チケット番号}_レポート.md（最終レポート）
• {チケット番号}_受け入れ基準.md（受け入れ基準）
```
チケット番号またはタイトルが取得できない場合は、取得できた情報のみで構成する。
## 送信後の報告
送信完了後、以下を報告する。
- 送信先
- 送信内容
送信に失敗した場合は、以下を報告する。
```text
Slack通知の送信に失敗しました
```
そのうえで、手動での通知を案内する。
---
# 最終出力ルール
最後に必ず以下をまとめる。
- チケット情報の取得結果
- レビュー結果
- 修正有無
- ビルド結果
- 保存したファイルの絶対パス
- Slack通知結果
- 残課題
EOF
使い方
Codexを対象リポジトリで起動します。
cd /path/to/your-ios-project
codex --sandbox workspace-write --add-dir "$HOME/Documents/test-cases"
その後、Codexにこう依頼します。
$review-and-fix abc12345..def67890
この形式では、.. を含む abc12345..def67890 をコミット範囲として扱います。abc12345 が比較元の基点、def67890 が比較先です。レビュー対象は、基本的に abc12345 には含まれず def67890 には含まれるコミットになります。
チケット番号を引数で明示していない場合、Skillは対象コミットのメッセージからチケット番号を抽出します。たとえば、コミットメッセージに以下のような記載があれば、408408 をチケット番号として扱います。
refs #408408 LINE連携画面の表示条件を修正
#408408 クーポン表示ロジックを修正
チケット408408 対応
Redmine 408408 対応
より確実に指定したい場合は、こうします。
$review-and-fix COMMIT_RANGE=abc12345..def67890 TICKET_ID=408408
ブランチ名を使う場合は、こうも書けます。
$review-and-fix origin/develop..HEAD
実務で、チケット番号の誤検出を避けたいなら、次の形が最も安全です。
$review-and-fix COMMIT_RANGE=origin/develop..HEAD TICKET_ID=408408
Skillがトリガーされないとき
Codexの環境によっては、Skill機能を明示的に有効化する必要があります。
Skill機能は導入当初フィーチャーフラグで管理されていました。$review-and-fix が反応しない場合は、codex --enable skills で機能を有効化してから新しいセッションを開始してください。SKILL.md を追加・更新した直後に認識されない場合は、Codexを再起動するとメタデータが再読み込みされます。
--add-dir を付ける理由
このSkillは、成果物を作業リポジトリ外の ~/Documents/test-cases/{チケット番号}/ に保存します。Codexのサンドボックス設定によっては、リポジトリ外のディレクトリに書き込めない場合があります。
そのため、起動時に書き込み先を許可しておくと安全です。
--add-dir "$HOME/Documents/test-cases"
出力される成果物
このSkillでは、以下の3ファイルを保存します。
~/Documents/test-cases/{チケット番号}/{チケット番号}_テスト項目.md
~/Documents/test-cases/{チケット番号}/{チケット番号}_レポート.md
~/Documents/test-cases/{チケット番号}/{チケット番号}_受け入れ基準.md
それぞれの役割は次のとおりです。
| ファイル | 内容 |
|---|---|
{チケット番号}_テスト項目.md |
正常系・異常系・回帰テストの確認項目 |
{チケット番号}_レポート.md |
レビュー結果、修正内容、ビルド結果、残課題 |
{チケット番号}_受け入れ基準.md |
Redmineに貼り付ける受け入れ基準 |
レビュー観点
このSkillでは、iOSアプリ開発で特に見落としやすい観点を固定しています。
| # | 観点 | 確認内容 |
|---|---|---|
| 1 | チケット要件との整合性 | Redmineの目的・受け入れ条件と差分が一致しているか |
| 2 | クラッシュリスク | force unwrap、配列範囲外アクセス、nil参照など |
| 3 | メモリリスク | retain cycle、weak/unowned、Combineの解放漏れなど |
| 4 | iOSバージョン互換 | iOS 15で動作するか、@available 漏れがないか |
| 5 | 既存コードへの影響 | 呼び出し元・呼び出し先に副作用がないか |
| 6 | テスタビリティ | 単体テストしやすい構造か |
| 7 | 命名・可読性 | Swift API Design Guidelinesに沿っているか |
| 8 | エラーハンドリング | 異常系が握りつぶされていないか |
| 9 | 非同期処理 |
async/await、Task、キャンセル考慮が適切か |
| 10 | アクセシビリティ | VoiceOver、Dynamic Typeへの影響がないか |
ポイントは、問題がない観点も「該当なし」と出力させることです。これで「見ていない」のか「見たうえで問題なし」なのかを区別できます。
リスク分類
レビュー結果は以下の4段階で分類します。
| リスク | 意味 |
|---|---|
| 🔴 重大 | 起動不能、重大クラッシュ、署名やBundle IDの重大不整合、重大な審査リスク |
| 🟠 高 | 権限設定不備の可能性が高い、広範囲回帰、依存関係の破壊的変更 |
| 🟡 中 | 局所的回帰、保守性低下、異常系の懸念、運用リスク |
| 🟢 低 | 影響範囲が限定的で、重大な懸念が確認できない |
このSkillでは、原則として 🔴 重大 または 🟠 高 の問題だけを修正対象にしています。レビュー用Skillに過剰な自動修正をさせると、元の実装意図を壊す可能性があるためです。
Redmine / Slack / MCPについて
このSkillは、RedmineとSlackをMCP経由で使う前提です。MCPを使うことで、Codexから外部システムにアクセスし、チケット情報の取得やSlack通知ができます。
ただし、環境によってMCPツール名は異なります。そこで、Skill内では次の方針にしています。
MCPツール名を決め打ちしない。
利用可能なMCPツール一覧から、Redmine・Slackに対応するツールを特定して使用する。
これで環境差分に少し強くなります。Redmine MCPが使えない場合はチケット情報なしでコード差分のみをレビューし、Slack MCPが使えない場合は通知文面を出力して手動通知に切り替えます。
実務で使うときの注意点
1. 最初は修正なしレビューとして試す
初回から自動修正まで任せず、まずはレビュー結果だけを見る運用も有効です。必要なら、Skill内のStep 3を次のように変更します。
🔴 重大 または 🟠 高 の問題について、修正案のみ提示する。
ユーザーが明示的に依頼した場合のみ修正する。
安全性を優先するチームでは、この形のほうが導入しやすいです。
2. ビルドコマンドはプロジェクトごとに調整する
iOSプロジェクトでは、.xcodeproj か .xcworkspace か、scheme名、configuration、simulator指定、CocoaPods / Swift Package Manager / Carthage の利用有無、証明書や署名設定によって、ビルドコマンドが変わります。
Skill側で自動判定するようにしていますが、安定運用するならプロジェクトの AGENTS.md にビルド手順を書いておくのが確実です。
# Build
```bash
xcodebuild \
-workspace BookLive.xcworkspace \
-scheme BookLive \
-configuration Debug \
-destination 'platform=iOS Simulator,name=iPhone 16' \
build
```
3. チケット番号は明示したほうがよい
コミットメッセージからチケット番号を抽出することもできますが、誤検出の可能性があります。たとえば、以下のような数値はチケット番号とは限りません。
iOS15対応
20250615 表示不具合修正
ver 1.2.3 対応
そのため、実務では次のように明示するのが安全です。
$review-and-fix COMMIT_RANGE=abc12345..def67890 TICKET_ID=408408
4. 成果物の保存先に注意する
保存先を ~/Documents/test-cases/ にしているため、Codexの実行権限によっては書き込めない場合があります。その場合は、起動時に --add-dir を使うか、保存先をリポジトリ配下に変更します。
./review-results/{チケット番号}/
チームで共有するなら、リポジトリ配下や作業用ディレクトリに出すほうが扱いやすい場合があります。
5. RedmineとSlackのMCP設定は別途必要
このSkillは、RedmineとSlackのMCPが使える前提で手順を定義しています。Skillを作成しただけでは、Redmineチケット取得やSlack通知は動作しません。実際に使う場合は、Codex側でRedmineとSlackに対応するMCP設定を別途用意してください。
この記事のポイント
iOSコードレビュー用のCodex Skillとして review-and-fix を作りました。Redmineチケット確認、Git差分レビュー、iOS観点のリスク確認、重大・高リスク問題の最小修正、Xcodeビルド確認、テスト項目作成、受け入れ基準作成、最終レポート作成、Markdownファイル保存、Slack通知までを、1つの流れとして定義しています。
特に、次のようなコミット範囲だけの指定にも対応できるようにしています。
$review-and-fix abc12345..def67890
この場合、コミット範囲は引数から特定し、チケット番号は対象コミットメッセージから抽出します。
レビュー業務では、毎回同じ観点を確認することが大事です。Codex Skillとしてレビュー手順を定義しておけば、作業のたびに長い指示を書く必要がなくなり、レビュー観点をSkill側に固定できるので品質のばらつきも抑えやすくなります。
まとめ
iOS開発では、クラッシュリスク、iOSバージョン互換、非同期処理、アクセシビリティなど、見落とすと後から問題になりやすい観点が多くあります。それらをSkillとして定義しておくことで、レビュー時の確認漏れを減らし、品質を安定させやすくなります。
Redmineチケット、Git差分、テスト項目、受け入れ基準、最終レポート、Slack通知までを一連の流れで扱えるようにしておくと、レビュー後の確認作業や共有作業も進めやすくなります。
$review-and-fix abc12345..def67890 のようにコミット範囲だけで呼び出せる形にしておけば、日常のレビュー依頼でも使いやすくなります。