review-ios
Comprehensive iOS/SwiftUI code review with optional parallel agents
Install via CLI (Recommended)
clawhub install openclaw/skills/skills/anderskev/review-iosiOS Code Review
Arguments
--parallel: Spawn specialized subagents per technology area- Path: Target directory (default: current working directory)
Hard gates
Complete in order before writing Issues in the output (empty scope is allowed; fabricated findings are not).
- Scope gate: You have an explicit list of
.swiftpaths under review (from Step 1 or a user-provided path). Pass: List captured in working notes or one line:No Swift files in scope— then stop with no Issues. - Linter gate (style): Step 2 commands ran for this tree; if no
.swiftlint.yml/.swiftlint.yaml, note that in one line. Pass: You do not report a style issue that SwiftLint would already enforce for that line when config exists andswiftlintsucceeds. - Protocol gate:
beagle-ios:review-verification-protocolis loaded before Step 6. Pass: If you report any Issues, at least one finding was checked against that checklist (name the item in Review Summary or on that Issue); if you report zero Issues, stateProtocol applied; no issuesin Review Summary. - Evidence gate (Critical/Major): For each Critical or Major item, you re-read the file at
FILE:LINE(full surrounding context, not only the diff hunk). Pass: The Issue text matches observable code at that location.
Do not begin Step 6 until Gates 1–3 are satisfied (skills load order stays Steps 4–5).
Step 1: Identify Changed Files
git diff --name-only $(git merge-base HEAD main)..HEAD | grep -E '\.swift$'
Step 2: Verify Linter Status
CRITICAL: Run SwiftLint BEFORE flagging any style issues.
# Check if SwiftLint config exists and run it
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)
Step 3: Detect Technologies
# 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
Metadata
Not sure this is the right skill?
Describe what you want to build — we'll match you to the best skill from 16,000+ options.
Find the right skillPaste this into your clawhub.json to enable this plugin.
{
"plugins": {
"official-anderskev-review-ios": {
"enabled": true,
"auto_update": true
}
}
}Related Skills
explanation-docs
Explanation documentation patterns for understanding-oriented content - conceptual guides that explain why things work the way they do
tutorial-docs
Tutorial patterns for documentation - learning-oriented guides that teach through guided doing
pytest-code-review
Reviews pytest test code for async patterns, fixtures, parametrize, and mocking. Use when reviewing test_*.py files, checking async test functions, fixture usage, or mock patterns.
reference-docs
Reference documentation patterns for API and symbol documentation. Use when writing reference docs, API docs, parameter tables, or technical specifications. Triggers on reference docs, API reference, function reference, parameters table, symbol documentation.
serde-code-review
Reviews serde serialization code for derive patterns, enum representations, custom implementations, and common serialization bugs. Use when reviewing Rust code that uses serde, serde_json, toml, or any serde-based serialization format. Covers attribute macros, field renaming, and format-specific pitfalls.