review-ios

iOS コードレビュー

引数

• --parallel：エージェントがサブエージェントに対応している場合、技術領域ごとに特化したサブエージェントを 1 つずつ割り当てます
• パス：対象ディレクトリ（デフォルト：現在の作業ディレクトリ）

必須ゲート

出力の問題点を書く前に、以下を順番に完了してください（対象範囲が空でも構いません。指摘を捏造してはいけません）。

1. 対象範囲ゲート： レビュー対象となる .swift パスの明示的な一覧を用意します（ステップ 1 またはユーザーが指定したパスから取得）。合格条件： 作業メモに一覧を記録するか、1 行で No Swift files in scope と記して、その後は問題点を挙げずに終了します。
2. リンターゲート（スタイル）： このツリーに対してステップ 2 のコマンドを実行します。.swiftlint.yml / .swiftlint.yaml がない場合は、その旨を 1 行で記録します。合格条件： 設定ファイルがあり、swiftlint が正常に実行された場合、SwiftLint が該当箇所に対してすでに適用するスタイル上の問題を報告しません。
3. プロトコルゲート： ステップ 6 の前に review-verification-protocol を読み込みます。合格条件： 問題点を報告する場合、チェックリストに照らして少なくとも 1 つの指摘を確認し、その項目名をレビュー概要または該当する問題点に記載します。問題点が 0 件の場合は、レビュー概要に Protocol applied; no issues と記します。
4. 証拠ゲート（重大／大）： 重大または大の各項目について、FILE:LINE のファイルを再読します（差分の該当部分だけではなく、前後を含む全体的な文脈も確認します）。合格条件： 問題点の記述が、その位置で確認できるコードと一致していること。

ゲート 1～3を満たすまで、ステップ 6 を開始しないでください（スキルの読み込み順はステップ 4～5 のままです）。

ステップ 1：変更されたファイルを特定する

git diff --name-only $(git merge-base HEAD main)..HEAD | grep -E '\.swift$'

ステップ 2：リンターの状態を確認する

重要：スタイル上の問題を指摘する前に、SwiftLint を実行してください。

# Check if SwiftLint config exists and run it
if [ -f ".swiftlint.yml" ] || [ -f ".swiftlint.yaml" ]; then
    swiftlint lint --quiet <changed_files>
fi

ルール：

• 特定のルールについて SwiftLint が問題なしと判定した場合、その問題を手動で指摘してはいけません
• スタイルルールについては、SwiftLint の設定が優先されます
• リンターで検出できない問題（意味上の問題、アーキテクチャ上の問題）のみを指摘してください

ステップ 3：技術を検出する

# SwiftUI (always with swift files that import it)
grep -r "import SwiftUI" --include="*.swift" -l | head -3

# SwiftData
grep -r "import SwiftData\|@Model\|@Query" --include="*.swift" -l | head -3

# Swift Testing
grep -r "import Testing\|@Test\|#expect" --include="*.swift" -l | head -3

# Combine
grep -r "import Combine\|AnyPublisher\|@Published" --include="*.swift" -l | head -3

# URLSession (explicit async patterns)
grep -r "URLSession\.shared\|\.data(from:\|\.download(from:" --include="*.swift" -l | head -3

# CloudKit
grep -r "import CloudKit\|CKContainer\|CKRecord" --include="*.swift" -l | head -3

# WidgetKit
grep -r "import WidgetKit\|TimelineProvider\|WidgetFamily" --include="*.swift" -l | head -3

# App Intents
grep -r "import AppIntents\|@AppIntent\|AppEntity" --include="*.swift" -l | head -3

# HealthKit
grep -r "import HealthKit\|HKHealthStore\|HKQuery" --include="*.swift" -l | head -3

# WatchKit
grep -r "import WatchKit\|WKExtension\|WKInterfaceController" --include="*.swift" -l | head -3

# Animations (beyond basic withAnimation)
grep -r "PhaseAnimator\|KeyframeAnimator\|matchedGeometryEffect\|navigationTransition\|scrollTransition\|CABasicAnimation\|CASpringAnimation\|CAKeyframeAnimation\|UIViewPropertyAnimator\|UIDynamicAnimator\|\.symbolEffect\|\.contentTransition\|CustomAnimation\|MeshGradient" --include="*.swift" -l | head -3

ステップ 4：検証プロトコルを読み込む

review-verification-protocol スキルを読み込み、レビュー全体を通じてチェックリストを意識してください。

ステップ 5：スキルを読み込む

以下の該当するスキルをそれぞれ読み込みます（SKILL.md を読んでください）。

必ず読み込む：

• swift-code-review
• swiftui-code-review

検出内容に応じて読み込む：

条件	スキル
SwiftData が検出された	swiftdata-code-review
Swift Testing が検出された	swift-testing-code-review
Combine が検出された	combine-code-review
URLSession が検出された	urlsession-code-review
CloudKit が検出された	cloudkit-code-review
WidgetKit が検出された	widgetkit-code-review
App Intents が検出された	app-intents-code-review
HealthKit が検出された	healthkit-code-review
WatchKit が検出された	watchos-code-review
アニメーションコードが検出された	ios-animation-code-review

ステップ 6：レビュー

エージェントがサブエージェントに対応している場合（かつ --parallel が指定されている場合）は、技術領域ごとにサブエージェントを 1 つずつ並列に割り当てます。それ以外の場合は順次実行します。どちらの方法でも、同じ統合済みの指摘を含む同一の出力を生成します。

順次実行（デフォルト）：

1. 該当するスキルを読み込む
2. まず Swift の品質上の問題（並行処理、メモリ、エラー処理）をレビューする
3. SwiftUI のパターン（ビューの構成、状態管理、アクセシビリティ）をレビューする
4. 検出された技術領域をレビューする
5. 指摘を統合する

並列実行（対応している場合、--parallel を使用）：

1. すべての技術を事前に検出する
2. 技術領域ごとにサブエージェントを 1 つずつ割り当てる
3. 各エージェントがスキルを読み込み、担当領域をレビューする
4. すべてのエージェントの完了を待つ
5. 指摘を統合する

問題を指摘する前に

1. SwiftLint の出力を確認する — リンターの指摘を重複して報告しないでください
2. コードコメントを確認する（// MARK:、// NOTE: など）— 意図的なパターンがないか確認してください
3. Apple フレームワークの慣用的な書き方を考慮する — 一般的には誤りに見えるコードでも、フレームワークでは正しい場合があります
4. エラー処理の欠如や競合状態を指摘する前に、非同期コードの経路を追跡する

ステップ 7：指摘事項を検証する

問題を報告する前に、次の点を確認してください。

1. 実際のコードを読み直す（差分のコンテキストだけで判断しない）
2. 「未使用」と指摘する場合 — すべての参照を検索しましたか？
3. 「不足」と指摘する場合 — フレームワークや親側で処理されているか確認しましたか？
4. 構文の問題を指摘する場合 — 現行バージョンのドキュメントで確認しましたか？
5. 実際の問題ではなく、スタイルの好みにすぎない指摘は削除する

ステップ 8：レビューの収束

1 回のレビューでの網羅性

すべてのカテゴリ（スタイル、ロジック、型、テスト、セキュリティ、パフォーマンス）にわたるすべての問題を、1 回のレビューで必ず報告してください。後のラウンドに問題を持ち越さないでください。

指摘を提出する前に、次の点を自問してください。

• 「推奨した修正がすべて適用された場合、修正後のコードに新たな問題が見つかりませんか？」
• 「新しいコード（テスト、型、モジュール）を要求しており、それ自体にもレビューが必要ではありませんか？」

どちらかの答えが「はい」の場合は、作成者が一度にすべて対応できるよう、予想される後続の問題も今回のレビューに含めてください。

スコープのルール

• 差分内のコードと、直接関連する既存コードのみをレビューしてください
• 差分より前には存在しなかった新機能、テスト基盤、アーキテクチャの変更を要求しないでください
• テストカバレッジが不足している場合は、「X、Y、Z のテストカバレッジが不足しています」という Minor の指摘を 1 件だけ挙げてください — モックライブラリ、振る舞いの抽出、依存性注入のパターンなど、大規模な新規コードにつながる実装の詳細は指定しないでください
• Typespec、ドキュメント、命名の問題は、公開 API の契約に影響しない限り Minor としてください
• 新しい依存関係（Mox、テストライブラリ、リンタープラグインなど）の追加を要求しないでください

修正の複雑さに関する基準

既存コードの修正は、規模にかかわらず実際の重大度で指摘してください。

ただし、差分より前には存在しなかった新規コードの追加要求は Informational に分類する必要があります。

• 新しい依存関係（Mox、リンタープラグインなど）の追加
• まったく新しいモジュール、ファイル、テストスイートの作成
• 新しい振る舞い、プロトコル、抽象化の抽出

これらはレビューのブロッカーではなく、今後の作業で作成者が検討する改善提案です。

イテレーションの方針

修正適用後の再レビューの場合：

• 以前に指摘した問題が正しく修正されたかどうかのみを確認する
• 以前の指摘と無関係な新しい指摘を追加しない
• 修正されていない Minor／Nice-to-Have の問題は受け入れ、再度指摘しない
• 再レビューの目的は新たな問題の発見ではなく、修正の検証です

出力形式

## Review Summary

[1-2 sentence overview of findings]

## Issues

### Critical (Blocking)

1. [FILE:LINE] ISSUE_TITLE
   - Issue: Description of what's wrong
   - Why: Why this matters (crash, data loss, security, race condition)
   - Fix: Specific recommended fix

### Major (Should Fix)

2. [FILE:LINE] ISSUE_TITLE
   - Issue: ...
   - Why: ...
   - Fix: ...

### Minor (Nice to Have)

N. [FILE:LINE] ISSUE_TITLE
   - Issue: ...
   - Why: ...
   - Fix: ...

### Informational (For Awareness)

N. [FILE:LINE] SUGGESTION_TITLE
   - Suggestion: ...
   - Rationale: ...

## Good Patterns

- [FILE:LINE] Pattern description (preserve this)

## Verdict

Ready: Yes | No | With fixes 1-N (Critical/Major only; Minor items are acceptable)
Rationale: [1-2 sentences]

修正後の検証

修正を適用した後、次を実行してください。

# Swift build and lint
swift build
swiftlint lint --quiet

# Run tests if present
swift test

承認前に、すべてのチェックが通過する必要があります。

ルール

• レビュー前にスキルを読み込む（レビュー後ではなく）
• すべての問題に連番を付ける（1、2、3...）
• すべての問題に FILE:LINE を記載する
• Issue／Why／Fix を明確に分ける
• 実際の重大度に基づいて分類する
• Swift 6 の厳格な並行処理に関する問題を確認する
• 修正後に検証を実行する
• すべての問題を 1 回のレビューで報告する — 後のイテレーションに指摘を持ち越さない
• 再レビューでは以前の修正のみを検証する — 新たな問題を発見しない
• 新規コード（新しいモジュール、依存関係、テストスイート）の追加要求は、ブロッカーではなく Informational とする
• Verdict では Minor と Informational を無視する — 承認を妨げるのは Critical と Major のみ