원클릭으로
tuist-swift-review
// Project-specific PR-review rules for the tuist/tuist Swift codebase (cli). Focuses on the things only this repo knows — preferring value types, the testing framework choice, and migration of XCTest to Swift Testing.
// Project-specific PR-review rules for the tuist/tuist Swift codebase (cli). Focuses on the things only this repo knows — preferring value types, the testing framework choice, and migration of XCTest to Swift Testing.
Project-specific PR-review rules for the tuist/tuist Elixir codebases (server, cache, processor, xcode_processor, tuist_common, noora). Focuses on the things only this repo knows — authorization invariants, tenancy, write-only ClickHouse, Mimic placement, migration timestamptz, data-export updates, marketing changelog entries, and i18n.
Guides day-to-day work in Tuist-generated Xcode workspaces, including generation, build and test commands, and buildable folders. Use when working in a Tuist-generated project or when users mention `tuist generate`, `xcodebuild test`, or generated workspaces.
Migrates existing Xcode projects to Tuist generated workspaces with build and run validation, external dependency mapping, and migration checklists. Use when adopting Tuist for an existing app or converting a hand-edited Xcode project to generated projects.
Analyzes Xcode selective testing effectiveness for a test run, showing which test targets were skipped or ran, and diagnosing regressions in test selection. Can compare two test runs to identify what changed.
Compares two Gradle build runs to identify duration regressions, cache changes, and task outcome differences. Can be invoked with build IDs, dashboard URLs, or branch names.
Compares two Xcode build runs to identify duration regressions, cache changes, and new issues. Can be invoked with build IDs, dashboard URLs, or branch names (e.g. `tuist compare-builds --base main --head feature-branch`).
| name | tuist-swift-review |
| description | Project-specific PR-review rules for the tuist/tuist Swift codebase (cli). Focuses on the things only this repo knows — preferring value types, the testing framework choice, and migration of XCTest to Swift Testing. |
This skill is intentionally narrow. Generic Swift style, formatting, naming, and lint hygiene are already covered by SwiftFormat / SwiftLint in CI — do not flag those. Focus on the rules below.
For each finding, cite path:line and quote the relevant snippet.
Default to struct for new types. Reach for class only when reference
semantics, identity, inheritance, or deinit are actually required.
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.NSObject, XCTestCase,
Operation, etc.) or conform to a protocol that requires reference
semantics.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.@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.
A newly added @unchecked Sendable conformance (whether on a
final class, a struct, or an extension). Recommend one of:
Mutex<State> from Synchronization (Swift 6.0+) for shared
mutable state — wrap the state in a single Mutex and expose
withLock { ... } accessors.OSAllocatedUnfairLock<State> from os for Apple-only code where
Mutex is not yet available.actor when the type can be reached only from async contexts.Sendable stored properties so
the compiler can synthesize Sendable itself.Severity: medium.
@unchecked Sendable conformances the diff does not touch.When suggesting Mutex, point at
cli/Sources/TuistAppleArchiver/AppleArchiver.swift for the in-tree
usage pattern: let state = Mutex(State()) plus
state.withLock { ... }.
New tests must be written with Swift Testing (import Testing,
@Test, #expect, #require). XCTest is legacy in this repo.
When a diff modifies an existing XCTest case (i.e. the test file
already uses XCTestCase / func testXxx() and the PR changes one of
those tests), the test should be rewritten in Swift Testing as part of
the same change rather than patched in place. Touching a test is the
moment to migrate it.
XCTestCase /
XCTAssert* / func testXxx(). Recommend Swift Testing.
Severity: high.@Test / #expect / #require. Severity: medium.XCTAssert* calls inside a Swift Testing @Test (or vice
versa). Pick one framework per test.XCUITest UI automation) — leave those on XCTest.When suggesting the migration, point at the project's Swift Testing
pattern (see cli/AGENTS.md): use @Test(.inTemporaryDirectory) and
FileSystem.temporaryTestDirectory for tests that need a temp dir, and
#require for unwrapping.