Back to Details

review-ios

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

iOS Code Review

iOS代码审查

Arguments

参数

  • --parallel
    : Spawn specialized subagents per technology area
  • Path: Target directory (default: current working directory)
  • --parallel
    : 针对各技术领域生成专用子代理
  • 路径：目标目录（默认：当前工作目录）

Step 1: Identify Changed Files

步骤1：识别变更文件

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

Step 2: Verify Linter Status

步骤2：验证代码检查器状态

CRITICAL: Run SwiftLint BEFORE flagging any style issues.
bash
undefined
重要提示：在标记任何风格问题前先运行SwiftLint。
bash
undefined

Check if SwiftLint config exists and run it

检查SwiftLint配置是否存在并运行

if [ -f ".swiftlint.yml" ] || [ -f ".swiftlint.yaml" ]; then swiftlint lint --quiet <changed_files> fi

**Rules:**
- If SwiftLint passes for a specific rule, DO NOT flag that issue manually
- SwiftLint configuration is authoritative for style rules
- Only flag issues that linters cannot detect (semantic issues, architectural problems)
if [ -f ".swiftlint.yml" ] || [ -f ".swiftlint.yaml" ]; then swiftlint lint --quiet <changed_files> fi

**规则：**
- 如果SwiftLint在某条规则上通过，请勿手动标记该问题
- SwiftLint配置是风格规则的权威依据
- 仅标记代码检查器无法检测的问题（语义问题、架构问题）

Step 3: Detect Technologies

步骤3：检测技术栈

bash
undefined
bash
undefined

SwiftUI (always with swift files that import it)

SwiftUI（所有导入它的swift文件都会检测）

grep -r "import SwiftUI" --include="*.swift" -l | head -3
grep -r "import SwiftUI" --include="*.swift" -l | head -3

SwiftData

SwiftData

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

Swift Testing

Swift Testing

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

Combine

Combine

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

URLSession (explicit async patterns)

URLSession（显式异步模式）

grep -r "URLSession.shared|.data(from:|.download(from:" --include="*.swift" -l | head -3
grep -r "URLSession.shared|.data(from:|.download(from:" --include="*.swift" -l | head -3

CloudKit

CloudKit

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

WidgetKit

WidgetKit

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

App Intents

App Intents

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

HealthKit

HealthKit

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

WatchKit

WatchKit

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

Animations (beyond basic withAnimation)

动画（超出基础withAnimation的部分）

grep -r "PhaseAnimator|KeyframeAnimator|matchedGeometryEffect|navigationTransition|scrollTransition|CABasicAnimation|CASpringAnimation|CAKeyframeAnimation|UIViewPropertyAnimator|UIDynamicAnimator|.symbolEffect|.contentTransition|CustomAnimation|MeshGradient" --include="*.swift" -l | head -3
undefined
grep -r "PhaseAnimator|KeyframeAnimator|matchedGeometryEffect|navigationTransition|scrollTransition|CABasicAnimation|CASpringAnimation|CAKeyframeAnimation|UIViewPropertyAnimator|UIDynamicAnimator|.symbolEffect|.contentTransition|CustomAnimation|MeshGradient" --include="*.swift" -l | head -3
undefined

Step 4: Load Verification Protocol

步骤4：加载验证协议

Load 
beagle-ios:review-verification-protocol
skill and keep its checklist in mind throughout the review.
加载
beagle-ios:review-verification-protocol
技能，并在整个审查过程中牢记其检查清单。

Step 5: Load Skills

步骤5：加载技能

Use the 
Skill
tool to load each applicable skill (e.g., 
Skill(skill: "beagle-ios:swift-code-review")
).
Always load:
  • beagle-ios:swift-code-review
  • beagle-ios:swiftui-code-review
Conditionally load based on detection:
ConditionSkill
SwiftData detected
beagle-ios:swiftdata-code-review
Swift Testing detected
beagle-ios:swift-testing-code-review
Combine detected
beagle-ios:combine-code-review
URLSession detected
beagle-ios:urlsession-code-review
CloudKit detected
beagle-ios:cloudkit-code-review
WidgetKit detected
beagle-ios:widgetkit-code-review
App Intents detected
beagle-ios:app-intents-code-review
HealthKit detected
beagle-ios:healthkit-code-review
WatchKit detected
beagle-ios:watchos-code-review
Animation code detected
beagle-ios:ios-animation-code-review
使用
Skill
工具加载每个适用的技能（例如：
Skill(skill: "beagle-ios:swift-code-review")
）。
始终加载：
  • beagle-ios:swift-code-review
  • beagle-ios:swiftui-code-review
根据检测结果条件加载：
条件技能
检测到SwiftData
beagle-ios:swiftdata-code-review
检测到Swift Testing
beagle-ios:swift-testing-code-review
检测到Combine
beagle-ios:combine-code-review
检测到URLSession
beagle-ios:urlsession-code-review
检测到CloudKit
beagle-ios:cloudkit-code-review
检测到WidgetKit
beagle-ios:widgetkit-code-review
检测到App Intents
beagle-ios:app-intents-code-review
检测到HealthKit
beagle-ios:healthkit-code-review
检测到WatchKit
beagle-ios:watchos-code-review
检测到动画代码
beagle-ios:ios-animation-code-review

Step 6: Review

步骤6：审查

Sequential (default):
  1. Load applicable skills
  2. Review Swift quality issues first (concurrency, memory, error handling)
  3. Review SwiftUI patterns (view composition, state management, accessibility)
  4. Review detected technology areas
  5. Consolidate findings
Parallel (--parallel flag):
  1. Detect all technologies upfront
  2. Spawn one subagent per technology area with 
    Task
    tool
  3. Each agent loads its skill and reviews its domain
  4. Wait for all agents
  5. Consolidate findings
顺序模式（默认）：
  1. 加载适用技能
  2. 首先审查Swift质量问题（并发、内存、错误处理）
  3. 审查SwiftUI模式（视图组合、状态管理、可访问性）
  4. 审查检测到的技术领域
  5. 整合审查结果
并行模式（--parallel参数）：
  1. 预先检测所有技术
  2. 使用
    Task
    工具为每个技术领域生成一个子代理
  3. 每个代理加载其对应技能并审查所属领域
  4. 等待所有代理完成
  5. 整合审查结果

Before Flagging Issues

标记问题前

  1. Check SwiftLint output - don't duplicate linter findings
  2. Check code comments for intentional patterns (// MARK:, // NOTE:, etc.)
  3. Consider Apple framework idioms - what looks wrong generically may be correct for the framework
  4. Trace async code paths before claiming missing error handling or race conditions
  1. 检查SwiftLint输出 - 不要重复代码检查器的发现
  2. 检查代码注释中的有意模式（// MARK:、// NOTE:等）
  3. 考虑Apple框架惯例 - 一般看起来有问题的写法可能在该框架下是正确的
  4. 追踪异步代码路径后再断言存在缺失的错误处理或竞争条件

Step 7: Verify Findings

步骤7：验证审查结果

Before reporting any issue:
  1. Re-read the actual code (not just diff context)
  2. For "unused" claims - did you search all references?
  3. For "missing" claims - did you check framework/parent handling?
  4. For syntax issues - did you verify against current version docs?
  5. Remove any findings that are style preferences, not actual issues
报告任何问题前：
  1. 重新阅读实际代码（不只是差异上下文）
  2. 对于“未使用”的断言 - 是否搜索了所有引用？
  3. 对于“缺失”的断言 - 是否检查了框架/父类的处理逻辑？
  4. 对于语法问题 - 是否对照当前版本文档进行了验证？
  5. 删除所有属于风格偏好而非实际问题的发现

Step 8: Review Convergence

步骤8：审查收敛

Single-Pass Completeness

单次审查完整性

You MUST report ALL issues across ALL categories (style, logic, types, tests, security, performance) in a single review pass. Do not hold back issues for later rounds.
Before submitting findings, ask yourself:
  • "If all my recommended fixes are applied, will I find NEW issues in the fixed code?"
  • "Am I requesting new code (tests, types, modules) that will itself need review?"
If yes to either: include those anticipated downstream issues NOW, in this review, so the author can address everything at once.
必须在单次审查中报告所有类别（风格、逻辑、类型、测试、安全、性能）的所有问题。不要保留问题到后续轮次。
提交结果前，自问：
  • “如果我推荐的所有修复都被应用，我会在修复后的代码中发现新问题吗？”
  • “我是否要求添加新代码（测试、类型、模块），而这些代码本身也需要审查？”
如果任一问题答案为是：现在就将这些预期的下游问题包含在本次审查中，以便作者一次性解决所有问题。

Scope Rules

范围规则

  • Review ONLY the code in the diff and directly related existing code
  • Do NOT request new features, test infrastructure, or architectural changes that didn't exist before the diff
  • If test coverage is missing, flag it as ONE Minor issue ("Missing test coverage for X, Y, Z") — do NOT specify implementation details like mock libraries, behaviour extraction, or dependency injection patterns that would introduce substantial new code
  • Typespecs, documentation, and naming issues are Minor unless they affect public API contracts
  • Do NOT request adding new dependencies (e.g. Mox, testing libraries, linter plugins)
  • 仅审查差异中的代码及直接相关的现有代码
  • 不要请求添加新功能、测试基础设施或架构变更（这些在差异之前不存在）
  • 如果测试覆盖率缺失，将其标记为一个次要问题（“X、Y、Z缺失测试覆盖”）——不要指定实现细节，如模拟库、行为提取或依赖注入模式，这会引入大量新代码
  • 类型规范、文档和命名问题属于次要问题，除非它们影响公共API契约
  • 不要请求添加新依赖（例如Mox、测试库、代码检查器插件）

Fix Complexity Budget

修复复杂度预算

Fixes to existing code should be flagged at their real severity regardless of size.
However, requests for net-new code that didn't exist before the diff must be classified as Informational:
  • Adding a new dependency (e.g. Mox, a linter plugin)
  • Creating entirely new modules, files, or test suites
  • Extracting new behaviours, protocols, or abstractions
These are improvement suggestions for the author to consider in future work, not review blockers.
现有代码的修复应根据实际严重程度标记。
然而，对于差异之前不存在的全新代码的请求必须归类为信息性建议：
  • 添加新依赖（例如Mox、代码检查器插件）
  • 创建全新的模块、文件或测试套件
  • 提取新的行为、协议或抽象
这些是供作者在未来工作中考虑的改进建议，而非审查阻塞项。

Iteration Policy

迭代策略

If this is a re-review after fixes were applied:
  • ONLY verify that previously flagged issues were addressed correctly
  • Do NOT introduce new findings unrelated to the previous review's issues
  • Accept Minor/Nice-to-Have issues that weren't fixed — do not re-flag them
  • The goal of re-review is VERIFICATION, not discovery
如果这是修复后的重新审查：
  • 仅验证之前标记的问题是否被正确解决
  • 不要引入与之前审查问题无关的新发现
  • 接受未修复的次要/锦上添花的问题——不要重新标记
  • 重新审查的目标是验证，而非发现新问题

Output Format

输出格式

markdown
undefined
markdown
undefined

Review Summary

审查总结

[1-2 sentence overview of findings]
[1-2句话概述审查结果]

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
  1. [文件:行号] 问题标题
    • 问题：错误描述
    • 原因：问题的影响（崩溃、数据丢失、安全、竞争条件）
    • 修复：具体推荐修复方案

Major (Should Fix)

主要（应修复）

  1. [FILE:LINE] ISSUE_TITLE
    • Issue: ...
    • Why: ...
    • Fix: ...
  1. [文件:行号] 问题标题
    • 问题：...
    • 原因：...
    • 修复：...

Minor (Nice to Have)

次要（锦上添花）

N. [FILE:LINE] ISSUE_TITLE
  • Issue: ...
  • Why: ...
  • Fix: ...
N. [文件:行号] 问题标题
  • 问题：...
  • 原因：...
  • 修复：...

Informational (For Awareness)

信息性（仅供参考）

N. [FILE:LINE] SUGGESTION_TITLE
  • Suggestion: ...
  • Rationale: ...
N. [文件:行号] 建议标题
  • 建议：...
  • 理由：...

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]
undefined
是否通过：是 | 否 | 需修复1-N（仅严重/主要问题；次要问题可接受） 理由：[1-2句话]
undefined

Post-Fix Verification

修复后验证

After fixes are applied, run:
bash
undefined
修复完成后运行：
bash
undefined

Swift build and lint

Swift构建和代码检查

swift build swiftlint lint --quiet
swift build swiftlint lint --quiet

Run tests if present

如有测试则运行

swift test

All checks must pass before approval.
swift test

所有检查必须通过才能批准。

Rules

规则

  • Load skills BEFORE reviewing (not after)
  • Number every issue sequentially (1, 2, 3...)
  • Include FILE:LINE for each issue
  • Separate Issue/Why/Fix clearly
  • Categorize by actual severity
  • Check for Swift 6 strict concurrency issues
  • Run verification after fixes
  • Report ALL issues in a single pass — do not hold back findings for later iterations
  • Re-reviews verify previous fixes ONLY — no new discovery
  • Requests for net-new code (new modules, dependencies, test suites) are Informational, not blocking
  • The Verdict ignores Minor and Informational items — only Critical and Major block approval
  • 审查前先加载技能（而非之后）
  • 为每个问题按顺序编号（1、2、3...）
  • 每个问题包含文件:行号
  • 清晰区分问题/原因/修复
  • 根据实际严重程度分类
  • 检查Swift 6严格并发问题
  • 修复后运行验证
  • 在单次审查中报告所有问题——不要保留发现到后续迭代
  • 重新审查仅验证之前的修复——不进行新发现
  • 对全新代码（新模块、依赖、测试套件）的请求属于信息性建议，而非阻塞项
  • 结论忽略次要和信息性项——仅严重和主要问题会阻止批准