Skip to content

Releases: eigenfunk/swift-clean-code-agent-skill

v0.2.0 — Inventory mode + P4 (per-frame rendering boundary)

14 May 21:14

Choose a tag to compare

First public release of swift-clean-code — a reviewer-style agent skill for Claude Code that focuses on Swift clean-code in the domain layer (everything that isn't SwiftUI views or framework integration).

It reports only genuine problems (Hudson principle) — no nitpicking, no rephrasing, no inventing issues.

What's in this release

Four reference areas, ten pattern checks

  • M1M3 — mutation discipline. let as default; mutating and inout only when justified; @Observable / @Model / Manager-Store-Coordinator containers exempt from M1.
  • S1S3 — state vs. listener. Single source of truth; listeners only where the system pushes. S3 now covers parallel writes and the associated-value-enum-plus-sibling-property case (an enum is already the source of truth — don't shadow it).
  • P1P4 — pure core / effectful shell. Injected dependencies, no ambient singletons in domain code, Date()/UUID() via DI. New in 0.2: P4 flags per-frame rendering side-effects in domain services (ARSession, MTKView, AVCaptureSession, CADisplayLink mutating render targets directly).

Inventory mode (new)

/swift-clean-code inventory [<path>] is a mechanical hotspot scanner — no LLM review, no reference files loaded. Runs ten rg queries across the codebase, counts pattern matches per file, applies a weighted score (`P1` × 3, `M2`/`M3` × 2, everything else × 1), and emits a sorted markdown table of the top hotspots.

Score adjustments make the ranking honest:

  • @Observable / @Model / ObservableObject / Manager-Store-Coordinator containers → M1 = 0 (framework-prescribed var, not a smell).
  • SwiftUI property wrappers and computed properties subtracted from M1_raw.
  • *Client / *Adapter / *Gateway / *Repository / *Provider files → P1/P3 halved (expected boundary code, not domain pollution).

Use it before the per-file reviewer to direct attention — the goal is which files are worth the token spend, not what's wrong with them.

Two amplifiers from real-world use

  • Sibling-pattern as a strength signal. When a sibling type in the same module already follows the pattern that the reviewed file violates (e.g. CoachService injects a clock, but ExerciseEvaluator calls Date() directly), cite the sibling by file:line. The finding becomes a local-inconsistency observation, not a theoretical purity appeal.
  • Doc-drift counts as a real finding. A comment that documents an invariant the code violates ("only writer of X" while two other functions also write X) gets flagged under the closest matching pattern. Future readers act on the comment, not on the audit.

Slash-command surface

```
/swift-clean-code # full review of working-tree diff (fallback: HEAD~3..HEAD)
/swift-clean-code # review a single Swift file in full
/swift-clean-code Focus on mutation # only mutation.md
/swift-clean-code Focus on state # only state-listener.md
/swift-clean-code Focus on shell # only pure-shell.md
/swift-clean-code inventory [] # hotspot scan
```

Install

```
/plugin marketplace add eigenfunk/swift-clean-code-agent-skill
/plugin install swift-clean-code@swift-clean-code-agent-skill
```

Or as a user-global symlink for development — see the README.

Companion skills

  • healthkit-pro — HealthKit edge cases (workout-finish sequence, route-builder pitfalls, authorization drift)
  • swiftui-pro by Paul Hudson — SwiftUI layer
  • swift-concurrency-pro by Paul Hudson — async/await, Sendable, actor isolation

Roadmap

Method cuts, copy-on-write awareness, and a broader protocol-orientation chapter are open. Contributions welcome — the rule mirrors Hudson's: don't repeat what LLMs already know, focus on edge cases and silent failures.