iOS Clean Architecture Agent Skills

A pragmatic Agent Skill for designing, reviewing, and simplifying Clean Architecture in Swift and iOS applications.

It helps AI coding agents reason about dependency direction, composition roots, Use Cases, Repositories, model boundaries, dependency lifetimes, feature assembly, and Swift module design without reproducing textbook layers mechanically.

Use concrete types by default. Introduce protocols only when a current and explicit requirement justifies them.

The goal is to build the simplest architecture that preserves meaningful boundaries.

What this skill helps with

Use clean-architecture-ios when working on:

• Clean Architecture composition for an iOS feature or application;
• dependency direction between Presentation, Application, Domain, Data, and Infrastructure;
• composition roots, application containers, feature factories, and navigation composition;
• dependency injection without protocol-first design;
• deciding whether a Use Case, Repository, Data Source, mapper, or module adds value;
• identifying thin pass-through layers and speculative abstractions;
• DTO, persistence, domain, and presentation model boundaries;
• external SDK isolation;
• application-, session-, and feature-scoped dependency lifetimes;
• SwiftUI ownership, previews, and test composition;
• logical boundaries and Swift Package modularization.

Core principles

Prefer concrete types by default

Dependency injection does not require protocols. Start with concrete structs, classes, actors, values, functions, and closures.

Introduce a protocol when a current requirement needs one, such as:

• multiple implementations that already exist;
• a known second implementation;
• a real module boundary requiring dependency inversion;
• a stable public or integration contract;
• explicit live, offline, cached, platform, or test implementations;
• an external capability that cannot be isolated more simply.

Do not create protocols only because another implementation may exist someday, every dependency is expected to have a mock, or a naming convention expects Protocol and Default.

Treat layers as optional tools

A simple feature may use:

View
  ↓
ViewModel
  ↓
Concrete service or client

A feature with meaningful data-access policy may use:

View
  ↓
ViewModel
  ↓
Repository
  ↓
API, database, cache, or SDK

A feature with application policy or coordination may use:

View
  ↓
ViewModel
  ↓
Use Case
  ↓
Repository or service

Use only the layers required by the problem.

Define boundaries before folders

Clean Architecture is primarily about dependency direction and ownership, not directory names.