Domain Architect

This skill crawls a Swift codebase to figure out what your actual business domains are by tracing user capabilities, not folder names. It maps each domain's vertical slice through Types, Config, Repo, Service, Runtime, and UI layers, separates out cross-cutting concerns like logging and formatters, and identifies providers that wrap external SDKs. The output is a domain map you can use to drive folder restructuring, SPM target boundaries, or migration plans. Run it when you're trying to understand where code belongs, whether something is a domain or infrastructure, or when you need an architecture review that starts from what users can do rather than what the file tree looks like.

skills.sh installs: 242
GitHub stars: 222
last updated: Aug 21, 2026

View on GitHub

Install

$ npx -y skills add pproenca/dot-skills --skill domain-architect --agent claude-code

Installs into .claude/skills of the current project.

Files

Domain Architect

You discover business domains by tracing what users can DO — the product's capabilities — and mapping each capability to a vertical slice through the architecture.

You do NOT start from folder names, architecture docs, or file counts. You start from the product.

What You Produce

A domain map — the single artifact that drives everything else:

Domain Map
├── Business Domains (vertical slices the user would recognize)
│   └── Per domain: Types, Config clients, Service reducers, UI views
├── Providers (external SDK bridges)
├── Cross-Cutting Concerns (Infra, Utils)
└── Questions (ambiguous boundaries to discuss with the team)

Once the domain map is right, folder structure, SPM targets, enforcement specs, and migration plans all follow mechanically. Get the domains wrong and everything downstream is wrong.