swift-library-design/SKILL.md
Expert guidance on Swift library and framework design. Use when developers mention: (1) designing a Swift library or framework, (2) public API design patterns, (3) protocol-oriented architecture or associated types, (4) result builders or DSL design, (5) performance optimization for libraries, (6) @inlinable or @usableFromInline, (7) noncopyable types for APIs, (8) progressive disclosure in API design, (9) ResponseGenerator or builder patterns.
npx skillsauth add wendylabsinc/claude-skills swift-library-designInstall 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.
Patterns and best practices for designing high-quality Swift libraries and frameworks.
Design around protocols with associated types for flexibility and testability. Use generics for type safety with runtime polymorphism.
Leverage Swift's type system to catch errors at compile time. Use noncopyable types, generics, and protocol constraints to make invalid states unrepresentable.
Design APIs that are efficient by default. Use @inlinable for hot paths, avoid unnecessary allocations, and provide zero-copy options.
Simple things should be simple, complex things should be possible. Provide sensible defaults while allowing customization.
public protocol Handler<Context>: Sendable {
associatedtype Context
func handle(input: Input, context: Context) async throws -> Output
}
// Consumers accept any conforming type
public struct Pipeline<Context> {
public func add<H: Handler>(handler: H) where H.Context == Context {
// Type-safe composition
}
}
Allow multiple return types with automatic conversion:
public protocol ResponseGenerator: Sendable {
func response(from request: Request, context: some RequestContext) throws -> Response
}
// Extend standard types
extension String: ResponseGenerator {
public func response(from request: Request, context: some RequestContext) -> Response {
Response(status: .ok, body: .init(string: self))
}
}
extension HTTPResponse.Status: ResponseGenerator {
public func response(from request: Request, context: some RequestContext) -> Response {
Response(status: self)
}
}
@resultBuilder
public enum PipelineBuilder<Context> {
public static func buildExpression<M: Middleware>(_ m: M) -> M
where M.Context == Context { m }
public static func buildPartialBlock<M0: Middleware, M1: Middleware>(
accumulated m0: M0, next m1: M1
) -> CombinedMiddleware<M0, M1> {
CombinedMiddleware(m0, m1)
}
}
// Usage
let pipeline = PipelineBuilder {
LoggingMiddleware()
AuthMiddleware()
RateLimitMiddleware()
}
public struct ServerBuilder: Sendable {
private let build: @Sendable () throws -> Server
public static func http1(config: HTTP1Config = .init()) -> ServerBuilder {
.init { HTTP1Server(config: config) }
}
public static func http2(tlsConfig: TLSConfiguration) -> ServerBuilder {
.init { HTTP2Server(tlsConfig: tlsConfig) }
}
}
// Fluent usage
let server = Application(server: .http1(config: .init(idleTimeout: .seconds(30))))
references/api-patterns.md - Protocol design, result builders, builder pattern, error handling, parameter extractionreferences/performance.md - Inlining, noncopyable types, data structures, lock-free patterns, state machinesdevelopment
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.
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.