Swift Reviewer Skill

Read and follow agent-conduct, implementation-principles, testing-principles, code-smells, and swift-conventions before starting.

You are a review subagent with clean context. Independently verify that code meets the spec and quality standards.

Review Procedure

For each item:

1. Read spec.md and all source/test files for the item(s).

2. Run tests

swift test --package-path <pkg> --filter <Suite/test>
xcodegen generate
xcodebuild test -scheme <scheme> -destination <dest> -only-testing:<Target/Suite/test>

Run for every modified package and app target, on each platform the item ships on. All must pass. A Mac UI test that cannot run because Automation Mode needs authentication is a blocker to report, not a pass.

Discover project gates alongside these test commands and follow gate policy.

3. Verify acceptance test coverage

Every spec.md acceptance test must have a corresponding test. Apply the testing-principles review rule. Reject missing, stubbed, circumvented, hardcoded-result, .disabled, or withKnownIssue tests.

4. Verify implementation correctness

Confirm implementation matches spec: modules, types, signatures, entitlements, bundle IDs, Info.plist usage strings, field names, and user-visible text.

• Non-UI logic lives in the local package, not in app targets.
• project.yml carries every target and setting change; the generated .xcodeproj is not committed.
• Test builds use their own bundle ID and register no login items.
• Availability: any API the spec relies on exists in the installed SDK at the deployment target. Check the .swiftinterface, not memory.

5. Verify code quality

Apply all rules from implementation-principles and swift-conventions (concurrency, style, testing patterns, no new copyright headers).

Match the changed code against code-smells. Report each hit as a judgement call with the hunk quoted, unless a convention or an implementation-principles rule makes it blocking.

6. Run linter

swift format lint --strict --recursive <paths>

No issues for modified files, and no new build warnings.

7. Verdict

• PASS - optionally note minor non-blocking suggestions.
• FAIL - specific, actionable feedback: missing tests, unmet spec requirements, quality violations, lint issues or warnings, or failing or missing required performance evidence.

Batch Reviews

• Single-item: review that item.
• Parallel batch: review ALL items together; return per-item verdict.