swift/SKILL.md
Expert guidance on Swift best practices, patterns, and implementation. Use when developers mention: (1) Swift configuration or environment variables, (2) swift-log or logging patterns, (3) OpenTelemetry or swift-otel, (4) Swift Testing framework or @Test macro, (5) Foundation avoidance or cross-platform Swift, (6) platform-specific code organization, (7) Span or memory safety patterns, (8) non-copyable types (~Copyable), (9) API design patterns or access modifiers.
npx skillsauth add wendylabsinc/claude-skills swiftInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Swift is a modern general-purpose programming language.
Load these files as needed for specific topics:
references/swift-configuration.md - Swift Configuration: reading config from environment variables, files, CLI arguments; provider hierarchy, namespacing, hot reloading, secret handlingreferences/swift-log.md - Swift Log logging API: log levels, structured logging, best practices for libraries, metadata, custom handlersreferences/swift-otel.md - Swift OTel: OpenTelemetry backend for server apps (preferred for Linux); OTLP export for logs, metrics, tracing; framework integrationreferences/swift-testing.md - Swift Testing framework: @Test macro, #expect/#require assertions, traits, parameterized tests, test suites, parallel execution, XCTest migrationreferences/debugging.md - Debugging tips: Terminal UI on Linux (alternate screen buffer), GitHub Actions log analysisPrefer backtick-escaped, sentence-style test function names so the test description lives in the function name:
@Test
func `does something very special in a certain edge case`() async throws {
// ...
}
Use @Test("...") display names only when a separate display name is specifically needed.
Keep types and functions internal unless they need to be public for external use. This prevents accidental exposure of implementation details and makes access level errors easier to fix.
Sort members by visibility in this order:
Public members should come first and be grouped by topic using // MARK: - ... sections that read like Apple API reference groups. Put an empty line both above and below every // MARK: - ... heading. Prefer present-progressive gerund phrases that describe the capability, such as:
// MARK: - Working with Child Items
public func addChild(_ child: Child) { ... }
// MARK: - Managing Life-Cycle
public func start() async throws { ... }
Use visibility markers for non-public sections:
// MARK: - Internal
internal func prepareStorage() { ... }
// MARK: - Private
private func rebuildIndex() { ... }
Do not mix internal or private helpers into public topic sections. If public API has only one obvious topic, there is no need for a // MARK: - <Topic> before the internal/private sections.
Choose conformance placement based on what the protocol means:
public enum BlahError: Error { ... }-able protocol, put the conformance in an extension at the bottom of the same file as the protocol.
// MARK: - <ProtocolName> heading immediately before the extension.public struct Blah { ... }
// MARK: - Codable
extension Blah: Codable {
// Codable-specific implementation
}
Avoid Foundation in core library code when possible:
Data, Date, UUID, etc.) should be avoided in public APIs for libraries targeting:
[UInt8] instead of Data for byte buffersContinuousClock.Instant or custom types instead of DateUUID stringsinternal import Foundation or internal import FoundationEssentials, never public import#if canImport(FoundationEssentials)
internal import FoundationEssentials
#else
internal import Foundation
#endif
When using InternalImportsByDefault in Package.swift, all imports are internal by default unless explicitly marked with public import.
When to use public import:
public import ServiceLifecycle when conforming to ServiceLifecycle.Service in a public typepublic import Foundation - keep Foundation internalUse a +platform suffix convention for platform-specific implementations:
PlatformDeviceDiscovery+macos.swift - macOS implementationPlatformDeviceDiscovery+linux.swift - Linux implementationPlatformDeviceDiscovery+default.swift - Fallback for other platformsWhen adding methods to a protocol, all platform files must be updated to maintain conformance.
Support both Glibc and Musl for Linux compatibility:
#if os(macOS) || os(iOS) || os(tvOS) || os(watchOS)
import Darwin
#elseif canImport(Glibc)
import Glibc
#elseif canImport(Musl)
import Musl
#endif
When selecting from multiple options with preference ordering, use sorting instead of multiple conditional blocks:
Bad - Repetitive:
if !preferBluetooth {
for interface in interfaces {
if case .lan(let device) = interface {
return .lan(device)
}
}
}
for interface in interfaces {
if case .bluetooth(let device) = interface {
return .bluetooth(device)
}
}
if preferBluetooth {
for interface in interfaces {
if case .lan(let device) = interface {
return .lan(device)
}
}
}
Good - Sort once, iterate once:
let sorted = interfaces.sorted { a, b in
if preferBluetooth {
return a.type == "Bluetooth" && b.type != "Bluetooth"
} else {
return a.type == "LAN" && b.type != "LAN"
}
}
for interface in sorted {
switch interface {
case .lan(let device): return .lan(device)
case .bluetooth(let device): return .bluetooth(device)
default: continue
}
}
Swift 6.2 introduces opt-in strict memory safety checking via .strictMemorySafety() in Package.swift.
Span Lifetime Constraints:
Span<T> is lifetime-dependent - it borrows the memory of its backing storageSolution: Asymmetric API Design Use Span for parsing (read-only, synchronous, borrowed) and [UInt8] for writing (owned, can cross boundaries):
public struct Characteristic<Value: Sendable>: Sendable {
// Parsing uses Span - borrowed, synchronous access
internal let parse: @Sendable (borrowing Span<UInt8>) throws -> Value
// Writing uses [UInt8] - owned, can cross closure boundaries
public typealias WithBytes = ([UInt8]) -> Void
internal let write: @Sendable (Value) -> (WithBytes) -> Void
}
Safe Integer Loading from Bytes:
// UNSAFE: unsafeLoad
return span.bytes.unsafeLoad(as: UInt64.self)
// SAFE: Manual byte-by-byte assembly
var value: UInt64 = 0
for i in 0..<8 {
value |= UInt64(span[i]) << (i * 8)
}
return value
_read/_modifyWith the LifetimeDependence experimental feature, computed properties can return non-escapable types like RawSpan and MutableRawSpan using _read and _modify accessors:
// Enable in Package.swift:
swiftSettings: [
.enableExperimentalFeature("LifetimeDependence"),
]
// Read-only span access
public var bytes: RawSpan {
_read {
var mapInfo = GstMapInfo()
guard mapBuffer(&mapInfo) else { fatalError("Failed to map") }
defer { unmapBuffer(&mapInfo) }
yield RawSpan(_unsafeStart: mapInfo.data, byteCount: Int(mapInfo.size))
}
}
// Mutable span access with Copy-on-Write
public var mutableBytes: MutableRawSpan {
_read {
fatalError("Cannot read mutableBytes")
}
_modify {
// Ensure unique ownership before write (CoW)
if !isKnownUniquelyReferenced(&storage) {
storage = storage.copy()!
}
var mapInfo = GstMapInfo()
guard mapBuffer(&mapInfo) else { fatalError("Failed to map") }
defer { unmapBuffer(&mapInfo) }
var span = MutableRawSpan(_unsafeStart: mapInfo.data, byteCount: Int(mapInfo.size))
yield &span
}
}
Known Compiler Issue (Swift 6.2.3): The LifetimeDependenceScopeFixup pass can crash when using span.withUnsafeBytes in certain contexts. Workaround: provide separate closure-based methods for C interop that don't go through the span accessor.
Use ~Copyable for move-only types that should not be duplicated:
public struct ResourceHandle: ~Copyable {
// Can only be moved, not copied
}
public struct ServiceRegistration: @unchecked Sendable, ~Copyable { ... }
tools
Expert guidance on building and deploying apps to WendyOS edge devices. Use when developers mention: (1) Wendy or WendyOS, (2) wendy CLI commands, (3) wendy.json or entitlements, (4) deploying apps to edge devices, (5) remote debugging Swift on ARM64, (6) NVIDIA Jetson or Raspberry Pi apps, (7) cross-compiling Swift for ARM64.
development
Curated Swift package ecosystem for WendyOS and Linux. Use when developers mention: (1) Swift packages for Linux or ARM64/AMD64, (2) choosing a Swift library, (3) Swift Package Index, (4) swiftpackageindex.com, (5) what Swift library to use, (6) Swift on WendyOS dependencies, (7) edge computing Swift libraries.
development
Expert guidance on building WASM apps for Wendy Lite MCU firmware on ESP32-C6. Use when developers mention: (1) Wendy Lite or wendy-lite, (2) WASM apps on ESP32 or microcontrollers, (3) WendyLite Swift package or import WendyLite, (4) building C/Rust/Swift/Zig apps for ESP32, (5) WAMR runtime on embedded devices, (6) GPIO/I2C/SPI/UART/NeoPixel from WASM, (7) Embedded Swift on WASM or wasm32-none-none-wasm, (8) BLE provisioning on ESP32-C6, (9) uploading WASM binaries to MCU, (10) TLS/networking on ESP32 from Swift.
development
Expert guidance on contributing to WendyOS: Yocto builds, agent internals, E2E testing, and system architecture. Use when developers mention: (1) building WendyOS images, (2) meta-wendyos layers or bitbake, (3) wendy-agent development or internals, (4) containerd or nerdctl on WendyOS, (5) E2E tests for wendy-agent, (6) Yocto recipes or bbappend files, (7) mDNS/Avahi service configuration, (8) device identity or UUID generation.