From swift-api-design
Apply when writing, reviewing, or designing any Swift code — functions, types, protocols, closures, or local functions at any scope level. Enforces the Swift API Design Guidelines with specific callouts, pushback, and suggested rewrites.
How this skill is triggered — by the user, by Claude, or both
Slash command
/swift-api-design:swift-api-designThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Apply the [Swift API Design Guidelines](https://www.swift.org/documentation/api-design-guidelines/) to any Swift code at any scope — public API, internal helpers, local functions, closures. The guidelines apply everywhere Swift is written.
Apply the Swift API Design Guidelines to any Swift code at any scope — public API, internal helpers, local functions, closures. The guidelines apply everywhere Swift is written.
removeElement should be remove since the parameter type already indicates it's an element."This skill is active whenever Swift code is being written, reviewed, or discussed. You do not wait to be asked. When you see a guideline violation, call it out immediately alongside any other feedback.
If you are explaining code, writing new code, or reviewing existing code, run the checklist below against every declaration in scope.
Work through these in order. Every yes is a finding.
remove(_:) when both position and value removal are possible)removeElement, userString, colorValue)string instead of greeting, viewType instead of ContentView)Any, AnyObject, Int, String) missing a noun describing its role?make prefix? (e.g., iterator() instead of makeIterator())Color(havingRed: 32) instead of Color(red: 32))sorted() instead of sort())sort() instead of sorted())empty instead of isEmpty, getIntersection instead of intersects(_:))able/ible/ing suffix? (e.g., Serialize instead of Serializable)Collectable instead of Collection)userSmtpServer instead of userSMTPServer, or HTTPSRequest instead of httpsRequest in a variable)min(x: number1, y: number2) instead of min(number1, number2))Int64(value: someUInt32) instead of Int64(someUInt32))removeBoxes(12) instead of removeBoxes(havingLength: 12))view.addSubview(view: y) instead of view.addSubview(y))view.dismiss(false) instead of view.dismiss(animated: false))Any, AnyObject, or unconstrained generic overload create an ambiguous overload set?For each violation, output:
**[Guideline]** _Section name from the guidelines_
**Found:** `the problematic code`
**Why:** One sentence on what the guideline says and why this breaks it.
**Rewrite:** `the corrected code`
Group findings by declaration when reviewing multiple. Lead with the highest-impact findings (call-site clarity violations before documentation omissions).
Direct and specific. You are applying a clear, published standard — not offering an aesthetic opinion. When pushing back on a name or label, root every objection in the guideline. When suggesting a rewrite, explain what it communicates that the original didn't.
If the user pushes back on a finding, engage with the specific guideline: either defend it or acknowledge a legitimate exception. The guidelines themselves note valid cases where rules are bent (e.g., precedent overrides simplicity for sin(x)).
In scope:
Out of scope:
npx claudepluginhub dylan/claude --plugin swift-api-designWrite, review, or improve Swift APIs using official guidelines for naming, argument labels, documentation, terminology, and conventions. Use for new designs, refactoring, or fluency reviews.
Applies Swift API Design Guidelines to name, label, and document Swift APIs. Covers argument label rules, mutating/nonmutating pairs, side-effect naming, documentation comments, and clarity at call site.
Enforces Swift code style conventions for clean, readable code: CamelCase naming, golden path with early guards, extensions for organization, spacing rules, and idiomatic patterns. Use when writing or reviewing Swift code.