Project Context
- Recent changes: !
git diff --name-only HEAD~3 2>/dev/null || echo "no git history"
- Swift version: !
swift --version 2>&1 | head -1 || echo "swift not found"
- Build target: !
xcodebuild -list -json 2>/dev/null | jq -r '.project.schemes[0]' 2>/dev/null || echo "unknown"
Code Analyzer (Read-Only)
Structured Swift/macOS code analysis protocol. Read-only — no file modifications.
Lifecycle Position
Phase 5 (Review). Load before swiftui-view-refactor for architectural overview. For deep line-by-line analysis, use audit-context-building.
Analysis Protocol
Step 1 — Map the Entry Point
- Find the
@main App struct or entry point
- Identify window scenes (
WindowGroup, Settings, MenuBarExtra)
- Trace the root navigation structure (
NavigationSplitView, TabView)
Step 2 — Trace the Module Graph
- List all Swift source files grouped by directory/feature
- Identify dependencies between modules (imports, protocol conformances)
- Map state ownership: which types own
@Observable models, which receive them
- Identify services/repositories and their injection pattern
Step 3 — Identify Architecture Pattern
Classify the codebase:
- MV (Model-View): Views consume models directly via
@State, @Environment, @Query
- MVVM: Separate ViewModel classes mediate between Model and View
- TCA: Reducers, Store, Actions, State
- Hybrid: Mix of patterns across features
Note consistency — are all features using the same pattern?
Review Checklist
1. Code Organization — PASS / WARN / FAIL
| Check |
What to Look For |
| File structure |
Features grouped by domain, not by type (Views/, Models/, etc.) |
| File size |
Swift files under 300 lines; views under 100 lines |
| Naming |
Types are nouns, methods are verbs, booleans read as questions |
| Access control |
private by default, internal where needed, public only for API surface |
| Extensions |
Used to group protocol conformances and // MARK: sections |
2. State Management — PASS / WARN / FAIL
| Check |
What to Look For |
@Observable vs ObservableObject |
New code uses @Observable; legacy ObservableObject flagged |
@State visibility |
All @State and @StateObject are private |
| Ownership |
Views don't create models they should receive via injection |
@MainActor |
Observable classes and view models are @MainActor |
| Binding direction |
@Binding only where child modifies parent state |
| Nested observables |
No nested ObservableObject (pass directly or use @Observable) |
3. Error Handling — PASS / WARN / FAIL
| Check |
What to Look For |
try without catch |
Unhandled throws that could crash |
Force unwrap (!) |
Every ! must have justification comment or precondition |
Result vs throws |
Consistent error propagation strategy |
| User-facing errors |
Errors surfaced to UI with actionable messages |
| Network errors |
Retry logic, timeout handling, offline state |
4. Performance — PASS / WARN / FAIL
| Check |
What to Look For |
| View body complexity |
No object creation, heavy computation, or side effects in body |
| Lazy containers |
LazyVStack/LazyHStack for lists with >20 items |
| ForEach identity |
Stable id (never .indices for dynamic content) |
GeometryReader |
Guarded with > 0 and .isFinite; prefer containerRelativeFrame() |
| Image loading |
AsyncImage or downsampled thumbnails, not raw UIImage(data:) |
| Glass effects |
Multiple glass views wrapped in GlassEffectContainer |
5. Concurrency — PASS / WARN / FAIL
| Check |
What to Look For |
@MainActor |
UI-bound classes and properties are main actor isolated |
Sendable |
Types crossing isolation boundaries conform to Sendable |
.task modifier |
Async work uses .task {} (auto-cancels on disappear) |
| Actor isolation |
Mutable shared state protected by actors |
| Data races |
No unprotected mutable state accessed from multiple contexts |
6. Security — PASS / WARN / FAIL
| Check |
What to Look For |
| Hardcoded secrets |
No API keys, tokens, or passwords in source |
| Keychain usage |
Sensitive data stored in Keychain, not UserDefaults |
| Sandbox entitlements |
Minimal entitlements; no unnecessary capabilities |
| Input validation |
User input validated before use |
| URL handling |
External URLs validated before opening |
7. Test Coverage — PASS / WARN / FAIL
| Check |
What to Look For |
| Test file existence |
Every feature has corresponding test file |
| Model tests |
Business logic and data transformations tested |
| Edge cases |
Empty states, nil values, boundary conditions covered |
| Async tests |
async test methods with proper expectations |
| SwiftData tests |
In-memory ModelContainer for persistence tests |
Output Format
For each section, provide:
### [Section Name] — [PASS/WARN/FAIL]
**Summary:** One-line assessment.
**Findings:**
- [file_path:line] Description of issue
- [file_path:line] Description of issue
**Recommendation:** What to fix and in what order.
Cross-References
- For SwiftUI-specific review, use the
swiftui-ui-patterns review checklist
- For view structure refactoring, load
swiftui-view-refactor
- For deep line-by-line analysis, load
audit-context-building
1---2name: code-analyzer3description: This skill should be used when the user asks to "review code", "analyze architecture", "assess code quality", "audit the codebase", "review PR", or needs read-only code analysis. Provides structured review checklist for organization, error handling, performance, security, and test coverage.4---56## Project Context78- Recent changes: !`git diff --name-only HEAD~3 2>/dev/null || echo "no git history"`9- Swift version: !`swift --version 2>&1 | head -1 || echo "swift not found"`10- Build target: !`xcodebuild -list -json 2>/dev/null | jq -r '.project.schemes[0]' 2>/dev/null || echo "unknown"`1112# Code Analyzer (Read-Only)1314Structured Swift/macOS code analysis protocol. Read-only — no file modifications.1516## Lifecycle Position1718Phase 5 (Review). Load before `swiftui-view-refactor` for architectural overview. For deep line-by-line analysis, use `audit-context-building`.1920## Analysis Protocol2122### Step 1 — Map the Entry Point23241. Find the `@main` App struct or entry point252. Identify window scenes (`WindowGroup`, `Settings`, `MenuBarExtra`)263. Trace the root navigation structure (`NavigationSplitView`, `TabView`)2728### Step 2 — Trace the Module Graph29301. List all Swift source files grouped by directory/feature312. Identify dependencies between modules (imports, protocol conformances)323. Map state ownership: which types own `@Observable` models, which receive them334. Identify services/repositories and their injection pattern3435### Step 3 — Identify Architecture Pattern3637Classify the codebase:38- **MV (Model-View):** Views consume models directly via `@State`, `@Environment`, `@Query`39- **MVVM:** Separate ViewModel classes mediate between Model and View40- **TCA:** Reducers, Store, Actions, State41- **Hybrid:** Mix of patterns across features4243Note consistency — are all features using the same pattern?4445## Review Checklist4647### 1. Code Organization — PASS / WARN / FAIL4849| Check | What to Look For |50|-------|------------------|51| File structure | Features grouped by domain, not by type (Views/, Models/, etc.) |52| File size | Swift files under 300 lines; views under 100 lines |53| Naming | Types are nouns, methods are verbs, booleans read as questions |54| Access control | `private` by default, `internal` where needed, `public` only for API surface |55| Extensions | Used to group protocol conformances and `// MARK:` sections |5657### 2. State Management — PASS / WARN / FAIL5859| Check | What to Look For |60|-------|------------------|61| `@Observable` vs `ObservableObject` | New code uses `@Observable`; legacy `ObservableObject` flagged |62| `@State` visibility | All `@State` and `@StateObject` are `private` |63| Ownership | Views don't create models they should receive via injection |64| `@MainActor` | Observable classes and view models are `@MainActor` |65| Binding direction | `@Binding` only where child modifies parent state |66| Nested observables | No nested `ObservableObject` (pass directly or use `@Observable`) |6768### 3. Error Handling — PASS / WARN / FAIL6970| Check | What to Look For |71|-------|------------------|72| `try` without `catch` | Unhandled throws that could crash |73| Force unwrap (`!`) | Every `!` must have justification comment or precondition |74| `Result` vs throws | Consistent error propagation strategy |75| User-facing errors | Errors surfaced to UI with actionable messages |76| Network errors | Retry logic, timeout handling, offline state |7778### 4. Performance — PASS / WARN / FAIL7980| Check | What to Look For |81|-------|------------------|82| View body complexity | No object creation, heavy computation, or side effects in `body` |83| Lazy containers | `LazyVStack`/`LazyHStack` for lists with >20 items |84| ForEach identity | Stable `id` (never `.indices` for dynamic content) |85| `GeometryReader` | Guarded with `> 0` and `.isFinite`; prefer `containerRelativeFrame()` |86| Image loading | `AsyncImage` or downsampled thumbnails, not raw `UIImage(data:)` |87| Glass effects | Multiple glass views wrapped in `GlassEffectContainer` |8889### 5. Concurrency — PASS / WARN / FAIL9091| Check | What to Look For |92|-------|------------------|93| `@MainActor` | UI-bound classes and properties are main actor isolated |94| `Sendable` | Types crossing isolation boundaries conform to `Sendable` |95| `.task` modifier | Async work uses `.task {}` (auto-cancels on disappear) |96| Actor isolation | Mutable shared state protected by actors |97| Data races | No unprotected mutable state accessed from multiple contexts |9899### 6. Security — PASS / WARN / FAIL100101| Check | What to Look For |102|-------|------------------|103| Hardcoded secrets | No API keys, tokens, or passwords in source |104| Keychain usage | Sensitive data stored in Keychain, not UserDefaults |105| Sandbox entitlements | Minimal entitlements; no unnecessary capabilities |106| Input validation | User input validated before use |107| URL handling | External URLs validated before opening |108109### 7. Test Coverage — PASS / WARN / FAIL110111| Check | What to Look For |112|-------|------------------|113| Test file existence | Every feature has corresponding test file |114| Model tests | Business logic and data transformations tested |115| Edge cases | Empty states, nil values, boundary conditions covered |116| Async tests | `async` test methods with proper expectations |117| SwiftData tests | In-memory `ModelContainer` for persistence tests |118119## Output Format120121For each section, provide:122123```124### [Section Name] — [PASS/WARN/FAIL]125126**Summary:** One-line assessment.127128**Findings:**129- [file_path:line] Description of issue130- [file_path:line] Description of issue131132**Recommendation:** What to fix and in what order.133```134135## Cross-References136137- For SwiftUI-specific review, use the `swiftui-ui-patterns` review checklist138- For view structure refactoring, load `swiftui-view-refactor`139- For deep line-by-line analysis, load `audit-context-building`
kmshdev