A review rule should have a narrow predicate, a useful explanation and fixtures that define its limits. Adding a pattern without a false-positive example makes future maintenance harder.
- 1Pattern candidate
- 2Positive fixture
- 3Negative fixture
- 4Located finding
Work through the example
Inspect a neighboring analyzer and preserve its result shape. Add a test for a context that looks similar but must not trigger.
Start with a disposable branch and synthetic data. Write the expected outcome before changing the implementation, then keep the first failing result. This prevents a later repair from quietly redefining the task. The procedure below is grounded in the repository reference; its examples must still be checked against your project and installed toolchain.
Implementation reference
The following focused section is adapted from the maintained project guide. It preserves the source’s examples and limitations.
review_swift_concurrency
| Rule | Severity |
|---|---|
observable-without-mainactor |
🔴 |
type-named-task |
🔴 |
task-detached |
🟠 |
dispatchqueue-main-async |
🟠 |
unchecked-sendable |
🟠 |
task-in-onappear |
🟠 |
empty-catch |
🟠 |
redundant-mainactor-run |
🟡 |
nonisolated-unsafe |
🟡 |
observable-not-final |
🟡 |
Background: ../swift/swift-concurrency.md, ../../patterns/mvvm.md.
Acceptance and failure review
| Checkpoint | What to inspect | If it does not match |
|---|---|---|
| Pattern candidate | Confirm the input and environment | Preserve the failure and return to this step |
| Positive fixture | Inspect the intermediate artifact | Preserve the failure and return to this step |
| Negative fixture | Run the focused check | Preserve the failure and return to this step |
| Located finding | Record the observed result | Preserve the failure and return to this step |
Ask the agent to explain the smallest change that resolves the observed mismatch. Keep unrelated refactors out of the repair. A change that makes a warning disappear is not enough if the behavior or ownership contract has changed. Re-run the same acceptance check so the before and after results are comparable.
Evidence and limits
An explanatory example is not a newly shipped analyzer; rule changes require their own tests.
This is an educational guide. Its presence in the series does not certify a completed client-specific lab. The series evidence record separates executed checks from exercises and blocked environments.
Inspect the source used in this lesson.
Related reading
- How can I catch Swift concurrency review findings before accepting an agent’s changes?
A real before-and-after MCP review with file and line evidence, plus the limits of text-based concurrency checks.
- Review AI-generated Swift before you trust it
A focused review, a small patch and a real test beat a confident completion message.
What to do next
Next: Writing your own skill for a Swift project: SKILL.md structure that agents follow