# Tuist Swift Review

Project-specific pull request review rules for the tuist/tuist Swift codebases.

- Repository: https://github.com/tuist/tuist (5859 stars)
- Category: Testing
- License: see repository
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add tuist/tuist --skill tuist-swift-review -g -a claude-code -y`
Codex: `npx skills add tuist/tuist --skill tuist-swift-review -g -a codex -y`
Cursor: `npx skills add tuist/tuist --skill tuist-swift-review -g -a cursor -y`
Gemini CLI: `npx skills add tuist/tuist --skill tuist-swift-review -g -a gemini-cli -y`

## Description

Project-specific pull request review rules for the tuist/tuist Swift codebases. Focuses on the things only this repo knows, including preferring value types, the testing framework choice, and migration of XCTest to Swift Testing.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Tuist Swift Review

This skill is intentionally narrow. **Generic Swift style, formatting,
naming, and lint hygiene are already covered by SwiftFormat and SwiftLint
in continuous integration. Do not flag those.** Focus on the rules below.

For each finding, cite `path:line` and quote the relevant snippet.

---

## 1. Prefer structs over classes

Default to `struct` for new types. Reach for `class` only when reference
semantics, identity, inheritance, or `deinit` are actually required.

### Flag

- **A new `class` declaration that has no stored mutable identity, no
  inheritance, no `deinit`, and is not bridged to an Objective-C / Cocoa
  API.** Recommend converting it to a `struct`. **Severity: medium.**

### Do not flag

- Existing classes left unchanged by the diff.
- Classes that subclass a framework type (`NSObject`, `XCTestCase`,
  `Operation`, etc.) or conform to a protocol that requires reference
  semantics.
- Types that genuinely need reference identity (caches, long-lived
  coordinators, actors-with-state-shared-by-reference).
- **`final class` declarations whose `Sendable` conformance is backed by
  a stored `Synchronization.Mutex<State>` (or another `~Copyable`
  synchronization primitive).** `Mutex` cannot be a stored property of a
  `Copyable` struct, the compiler emits `stored property '...' of
  'Copyable'-conforming struct '...' has non-Copyable type 'Mutex<...>'`, and a `~Copyable` struct cannot be captured by a `@Sendable` closure.
  A `final class` with the `Mutex` and `Sendable` conformance is the
  correct expression of this pattern.

## 2. Avoid `@unchecked Sendable`

`@unchecked Sendable` opts out of the compiler's concurrency safety
checks and shifts the burden of correctness onto every reader. Prefer
proper synchronization primitives that the compiler can verify.

### Flag

The rest: https://github.com/tuist/tuist/blob/HEAD/.blick/skills/tuist-swift-review/SKILL.md