swift-api-design-guidelines
Apply Swift API Design Guidelines to name, label, and document Swift APIs. Covers argument label rules (prepositional phrase rule, grammatical phrase rule, first-label omission), mutating/nonmutating pair naming (-ed/-ing participle pattern, form- prefix, sort/sorted, formUnion/union), side-effect naming (noun for pure, verb for mutating), documentation comment structure (summary by declaration kind, O(1) complexity rule), clarity at call site, role-based naming, protocol naming (-able/-ible/-ing), default arguments over method families, casing conventions, and terminology. Use when designing
Profile →npx skills add dpearson2699/swift-ios-skills --skill swift-api-design-guidelines --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
# Swift API Design Guidelines Apply the Swift API Design Guidelines to naming, labels, documentation, and call-site clarity. For mixed requests, handle the API-design portion here and route language/type-system work to `swift-language`, concurrency to `swift-concurrency`, and lint configuration to `swiftlint`. ## Contents - [Argument Label Rules](#argument-label-rules) - [Side-Effect Naming](#side-effect-naming) - [Mutating and Nonmutating Pairs](#mutating-and-nonmutating-pairs) - [Documentation Comments](#documentation-comments) - [Clarity and Naming](#clarity-and-naming) - [Fluent Usage and Protocols](#fluent-usage-and-protocols) - [General Conventions](#general-conventions) - [Common Mistakes](#common-mistakes) - [Review Checklist](#review-checklist) - [References](#references) ## Argument Label Rules Argument labels determine how a call site reads. Apply the first matching row: | Situation | Rule | Example | |-----------|------|---------| | First arg completes grammatical phrase | Omit label, merge words into base name | `addSubview(y)` | | Value-preserving init conversion | Omit first label | `Int64(someUInt32)` | | Arguments are indistinguishable peers | Omit all labels | `mi
- Contents
- Argument Label Rules
- Side-Effect Naming
- Mutating and Nonmutating Pairs
- Documentation Comments
- Summary rules by declaration kind
- Symbol markup
- O(1) complexity rule
- Clarity and Naming
- Fluent Usage and Protocols
- General Conventions
- Common Mistakes
- Review Checklist
- Argument Labels
What does the swift-api-design-guidelines skill do?
Apply Swift API Design Guidelines to name, label, and document Swift APIs. Covers argument label rules (prepositional phrase rule, grammatical phrase rule, first-label omission), mutating/nonmutating pair naming (-ed/-ing participle pattern, form- prefix, sort/sorted, formUnion/union), side-effect naming (noun for pure, verb for mutating), documentation comment structure (summary by declaration kind, O(1) complexity rule), clarity at call site, role-based naming, protocol naming (-able/-ible/-ing), default arguments over method families, casing conventions, and terminology. Use when designing
How do I install it?
Run `npx skills add dpearson2699/swift-ios-skills --skill swift-api-design-guidelines --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From dpearson2699/swift-ios-skills, a repository with 963 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.