swift-style
johnrogers/claude-swift-engineering
Swift code style conventions for clean, readable, idiomatic code.
What is swift-style?
A style guide for writing consistent, maintainable Swift code. Use when writing Swift to ensure proper naming conventions, code organization, formatting, and idiomatic patterns that prioritize clarity and readability.
- Defines naming conventions (UpperCamelCase for types, lowerCamelCase for everything else)
- Establishes code organization patterns using extensions and MARK comments
- Provides spacing and formatting rules (braces, blank lines, colons)
- Guides memory management practices with weak self capture patterns
- Explains access control best practices and when to use private vs public
- Identifies common Swift mistakes and how to avoid them
How to install swift-style
npx skills add https://github.com/johnrogers/claude-swift-engineering --skill swift-styleHow to use swift-style
- 1.Review the Core Principles section (Clarity > Brevity > Consistency)
- 2.Apply naming conventions: UpperCamelCase for types/protocols, lowerCamelCase for variables/functions
- 3.Use the golden path pattern with early returns instead of nested conditionals
- 4.Organize code with extensions and MARK comments for protocol conformance
- 5.Follow spacing rules: same-line opening braces, one blank line between methods
- 6.Avoid self unless required by compiler
- 7.Use type inference where clear, explicit annotations for empty collections
- 8.Check against the Common Mistakes section during code review
Use cases
- Ensuring consistent code style across a Swift team or project
- Reviewing and refactoring existing Swift code for readability
- Writing new Swift features with idiomatic patterns
- Establishing project-wide naming and organization standards
- Training developers on Swift best practices
- Swift developers
- iOS/macOS app developers
- Teams establishing code standards
- Code reviewers
swift-style FAQ
Avoid self unless required by the compiler. Only use it when necessary for clarity in capture semantics (like [weak self] in closures) or when the compiler requires it. Mixing self usage makes code harder to scan.
Use extensions with MARK comments. Keep core implementation in the main class body, then add separate extensions for each protocol conformance, each marked with a MARK comment like '// MARK: - UITableViewDataSource'.
Only three universal abbreviations are allowed: URL, ID, and UUID. All other abbreviations should be spelled out (use 'configuration' instead of 'cfg', 'manager' instead of 'mgr', 'context' instead of 'ctx').
No. Omit the get keyword for read-only computed properties. Write the expression directly after the property name and opening brace.
Avoid nesting. Use early returns and guards to keep the happy path left-aligned at the margin. This is called the golden path pattern and makes code easier to follow.
Full instructions (SKILL.md)
Source of truth, from johnrogers/claude-swift-engineering.
name: swift-style description: Swift code style conventions for clean, readable code. Use when writing Swift code to ensure consistent formatting, naming, organization, and idiomatic patterns.
Swift Style Guide
Code style conventions for clean, readable Swift code.
Core Principles
Clarity > Brevity > Consistency
Code should compile without warnings.
Naming
UpperCamelCase— Types, protocolslowerCamelCase— Everything else- Clarity at call site
- No abbreviations except universal (URL, ID)
// Preferred
let maximumWidgetCount = 100
func fetchUser(byID id: String) -> User
Golden Path
Left-hand margin is the happy path. Don't nest if statements.
// Preferred
func process(value: Int?) throws -> Result {
guard let value = value else {
throw ProcessError.nilValue
}
guard value > 0 else {
throw ProcessError.invalidValue
}
return compute(value)
}
Code Organization
Use extensions and MARK comments:
class MyViewController: UIViewController {
// Core implementation
}
// MARK: - UITableViewDataSource
extension MyViewController: UITableViewDataSource { }
Spacing
- Braces open on same line, close on new line
- One blank line between methods
- Colon: no space before, one space after
Self
Avoid self unless required by compiler.
// Preferred
func configure() {
backgroundColor = .systemBackground
}
Computed Properties
Omit get for read-only:
var diameter: Double {
radius * 2
}
Closures
Trailing closure only for single closure parameter.
Type Inference
Let compiler infer when clear. For empty collections, use type annotation:
var names: [String] = []
Syntactic Sugar
// Preferred
var items: [String]
var cache: [String: Int]
var name: String?
Access Control
privateoverfileprivate- Don't add
internal(it's the default) - Access control as leading specifier
Memory Management
resource.request().onComplete { [weak self] response in
guard let self else { return }
self.updateModel(response)
}
Comments
- Explain why, not what
- Use
//or///, avoid/* */ - Keep up-to-date or delete
Constants
Use case-less enum for namespacing:
enum Math {
static let pi = 3.14159
}
Common Mistakes
-
Abbreviations beyond URL, ID, UUID — Abbreviations like
cfg,mgr,ctx,deschurt readability. Spell them out:configuration,manager,context,description. The three exceptions are URL, ID, UUID. -
Nested guard/if statements — Deep nesting makes code hard to follow. Use early returns and guards to keep the happy path left-aligned.
-
Inconsistent self usage — Either always omit
self(preferred) or always use it. Mixing makes code scanning harder and confuses capture semantics. -
Overly generic type names —
Manager,Handler,Helper,Coordinatorare too vague. Names should explain responsibility:PaymentProcessor,EventDispatcher,ImageCache,NavigationCoordinator. -
Implied access control — Don't skip access control. Explicit
private,publichelps future maintainers understand module boundaries.internalis default, so omit it.
Related skills
More from johnrogers/claude-swift-engineering and the wider catalog.

casely
>

docker-best-practices
|

tailwindcss-advanced-layouts
Master CSS Grid, Flexbox, container queries, and advanced positioning with Tailwind CSS.

tailwindcss-animations
Tailwind CSS animations, transitions, and transforms with custom keyframes and accessibility support.

tailwindcss-mobile-first
Mobile-first responsive design patterns with Tailwind CSS v4 breakpoints, container queries, and touch-safe layouts.

journey
Search and install Journey kits — real agent workflows from the Journey registry. Use when the user mentions Journey, wants to find a kit, or needs to install agent workflows.