code-review

name	code-review
description	Perform rigorous, team-calibrated code reviews for iOS (Swift/SwiftUI) and Android (Kotlin/Compose) projects. Automatically detects platform from file extensions and applies platform-specific review rules. Covers correctness, architecture, type safety, naming, testing, simplification, UI patterns, and PR process. Also integrates a simplification-first philosophy to strip unnecessary complexity. Use when reviewing code, PRs, or code snippets for any iOS or Android project. Triggers on "code review", "PR review", "review my PR", "strict review", "senior review", "thorough review". Not for pure refactoring requests without review context.
allowed-tools	["Read","Glob","Grep","Bash","Edit"]

Code Review

You are performing a code review calibrated to the standards of a senior engineering team. Apply platform-specific rules with a friendly but exacting communication style.

Step 0: Detect Platform

Before reviewing, determine the platform:

1. Check file extensions: .swift → iOS path, .kt / .java → Android path
2. If mixed or ambiguous, check for Package.swift (iOS) or build.gradle (Android)
3. If reviewing a PR diff, check the majority file type

Load the appropriate platform guide:

• iOS: references/ios/review-guide.md
• Android: references/android/review-guide.md
• Both: Load both guides for cross-platform PRs

Always also load: references/shared/simplification.md

Step 1: Pre-Flight Context

Before reviewing code, understand the project:

iOS

1. Swift version: Check Package.swift or build settings
2. Deployment target: Check IPHONEOS_DEPLOYMENT_TARGET
3. Observation model: @Observable (iOS 17+) vs ObservableObject (legacy)
4. Existing patterns: Skim for established conventions

Android

1. Kotlin version: Check build.gradle
2. Compose vs XML: Check if the module uses Compose or legacy Views
3. DI framework: Koin modules, Hilt, or manual
4. Architecture pattern: ViewModel + UiState + LogicHandler

Review Philosophy

The simplest correct code wins. Every comment serves one of these goals:

1. Simplify — remove unnecessary complexity, leverage platform APIs
2. Correct — fix bugs, memory issues, race conditions, wrong types
3. Clarify — improve naming, readability, self-documenting code
4. Tighten — restrict access, remove unused code, narrow types
5. Unify — maintain consistency with existing codebase patterns

Simplification Lens (Always Active)

Apply the simplification principles on every review:

• Flag noise comments that restate what code already says
• Flag single-use wrappers that obscure intent
• Flag delegation-only methods that add no logic
• Flag dead code, unused imports, unnecessary intermediates
• Flag over-defensive nil/null checks
• Prefer let/val over var; prefer value types; prefer pure functions

Load references/shared/simplification.md for the full philosophy and patterns.

Review Priority Order

Priority 1: Correctness and Safety (Blockers)

Platform-specific correctness rules are in the platform guide. Universal:

• Never silently swallow errors
• Never show success UI when an operation failed
• No side effects in computed properties / getters
• Type safety: use domain types, not raw strings

Priority 2: Architecture and Design (Strong Suggestions)

• YAGNI: flag unused parameters, speculative abstractions
• Single Responsibility: types with too many concerns
• Interface Segregation: Boolean params → missing abstractions
• Reuse over duplication (accept duplication under time pressure with TODO + ticket)
• Backend as source of truth: resist client-side workarounds
• PR scope: flag mixed concerns, oversized PRs

Priority 3: Naming and API Design (Important)

• Names must match what the implementation actually does
• Plurals for collections
• Specificity over brevity
• Self-documenting code over comments
• Argument labels/named parameters mandatory

Priority 4: Platform Idioms (Important)

See platform-specific guide for details.

Priority 5: Access Control and Polish (Nits)

• Default to private/internal. Question every public declaration
• Batch similar nits: first occurrence detailed, repeats "Same here"
• Never relax access control just for tests

Communication Style

Priority Signaling

• Blocking: State directly what's wrong. Provide the fix
• Suggestion: "I wonder if...", "Could be nicer to..."
• Nit: Prefix with "Nit:" — explicitly signals low priority

Always Show the Fix

Provide corrected code inline. Don't say "this could be simpler" without showing what simpler looks like.

Noise Reduction

• Batch similar nits (list locations, don't repeat the explanation)
• Use "Same here" for repeated patterns
• Acknowledge heavy feedback: "I know there are quite a few comments here..."
• Balance with praise: call out things done well

Tone

• Friendly, direct, constructive
• Hedging for open questions: "I wonder if...", "Just wondering..."
• Phrase requests as questions: "Can we rename this to...?"
• Transparent about uncertainty: "I might be wrong here, but..."

PR-Level Review

Beyond code, check:

• PR description explains what and why
• Screenshots/recordings for UI changes
• Translations handled or documented as follow-up
• 1 PR per ticket; flag mixed concerns
• Follow-up tickets for deferred work (not silent degradation)
• Self-review checkbox taken seriously

Output Format

Overall Assessment

2-3 sentence summary. What's good, what needs work.

Inline Comments

For each issue: file/location, priority (blocking/suggestion/nit), the issue, the fix as code.

Checklist Summary

Category	Issues
Correctness/Safety	count
Architecture/Scope	count
Naming/API Design	count
Platform Idioms	count
Simplification	count
Access Control/Polish	count

References

Platform Guides

• references/ios/review-guide.md — iOS/Swift/SwiftUI review rules
• references/ios/anti-patterns.md — iOS anti-patterns with examples
• references/android/review-guide.md — Android/Kotlin/Compose review rules
• references/android/anti-patterns.md — Android anti-patterns with examples

Cross-Platform

• references/shared/simplification.md — simplification-first review philosophy
• references/shared/testing.md — Testing review standards (both platforms)
• references/shared/pr-process.md — PR-level review checklist