agentleFS
Sign inStart free
molayabmolayab/swift-ai-provider-kit/.claude/skills/swift-architecture-skill/SKILL.md

swift-architecture-skill

Skill1 starsChanged 8 months agoMITView on GitHub

Swift architecture patterns and playbooks for MVVM, TCA, Clean Architecture, and more.

We split this skill into the rules it gives an agent

15 rules. 13 are common, 0 are distinctive, and 2 are very specific to this project.

  • 13

    Common

    Most of the 4 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Common:

    Use this skill to pick the best Swift architecture playbook for SwiftUI/UIKit codebases and apply it to the user’s task.

    line 11
  2. Common:

    Before selecting an architecture, capture:

    line 17
  3. Common:

    If the user explicitly names an architecture, treat it as the initial candidate and run a fit check before committing:

    line 25
  4. Common:

    if it fits, proceed with the requested architecture

    line 27
  5. Very specific:

    if it mismatches key constraints, explicitly explain the mismatch and recommend the closest-fit alternative from …

    line 28
  6. Common:

    if the user still insists on a mismatched architecture, proceed with a risk-mitigated plan and state the risks up front

    line 29
  7. Very specific:

    When no architecture is named, load references/selection-guide.md and infer the best fit from stated constraints (state complexity, team …

    line 31
  8. Common:

    When code already exists:

    line 45
  9. Common:

    Read the selected architecture reference and convert its guidance into deliverables tailored to the user's request:

    line 52
  10. Common:

    Keep recommendations scoped to the requested feature or review task.

    line 67
  11. Common:

    Prefer protocol-based dependency injection and explicit state modeling.

    line 68
  12. Common:

    When writing code, include only the patterns relevant to the task — do not dump entire playbooks.

    line 73
  13. Common:

    Treat reference snippets as illustrative by default.

    line 74
  14. Common:

    Ask only minimum blocking questions.

    line 75
  15. Common:

    When reviewing PRs, use the architecture-specific checklist and call out specific violations with line-level fixes.

    line 76

“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Swift Architecture Skill

Overview

Use this skill to pick the best Swift architecture playbook for SwiftUI/UIKit codebases and apply it to the user’s task.

Workflow

Step 1: Analyze the Request Context

Before selecting an architecture, capture:

  • task type (new feature, refactor, PR review, debugging)
  • UI stack (SwiftUI, UIKit, or mixed)
  • scope (single screen, multi-screen, app-wide)
  • existing conventions to preserve

Step 2: Select the Architecture

If the user explicitly names an architecture, treat it as the initial candidate and run a fit check before committing:

  • validate against UI stack fit (SwiftUI/UIKit/mixed), state complexity, effect orchestration needs, team familiarity, and existing codebase conventions
  • if it fits, proceed with the requested architecture
  • if it mismatches key constraints, explicitly explain the mismatch and recommend the closest-fit alternative from references/selection-guide.md
  • if the user still insists on a mismatched architecture, proceed with a risk-mitigated plan and state the risks up front

When no architecture is named, load references/selection-guide.md and infer the best fit from stated constraints (state complexity, team familiarity, testing goals, effect orchestration needs, and framework preferences). Explain the recommendation briefly.

Architecture reference mapping:

  • MVVM → references/mvvm.md
  • MVI → references/mvi.md
  • TCA → references/tca.md
  • Clean Architecture → references/clean-architecture.md
  • VIPER → references/viper.md
  • Reactive → references/reactive.md
  • MVP → references/mvp.md
  • Coordinator → references/coordinator.md

Step 3: Analyze Existing Codebase (When Applicable)

When code already exists:

  • detect current architecture and DI style
  • note concurrency model (async/await, Combine, GCD, mixed)
  • align recommendations to local conventions

Step 4: Produce Concrete Deliverables

Read the selected architecture reference and convert its guidance into deliverables tailored to the user's request:

  • File and module structure: directory layout with file names specific to the feature
  • State and dependency boundaries: concrete types, protocols, and injection points
  • Async strategy: cancellation, actor isolation, and error paths
  • Testing strategy: what to test, how to stub dependencies, and example test structure
  • Migration path (for refactors): incremental steps to move from current to target architecture
  • UI stack adaptation: where SwiftUI and UIKit guidance should differ for the chosen architecture

Step 5: Validate with Checklist

End with the architecture-specific PR review checklist from the reference file, adapted to the user's feature.

Output Requirements

  • Keep recommendations scoped to the requested feature or review task.
  • Prefer protocol-based dependency injection and explicit state modeling.
  • Flag anti-patterns found in existing code and provide direct fixes.
  • Include cancellation and error handling in all async flows.
  • For explicit architecture requests, include a short fit result (fit or mismatch) with 1-2 reasons.
  • For mismatch cases, include one closest-fit alternative and why it better matches the stated constraints.
  • When writing code, include only the patterns relevant to the task — do not dump entire playbooks.
  • Treat reference snippets as illustrative by default; add full compile scaffolding only if the user asks for runnable code.
  • Ask only minimum blocking questions; otherwise proceed with explicit assumptions stated up front.
  • When reviewing PRs, use the architecture-specific checklist and call out specific violations with line-level fixes.

Download now (ZIP)

  • Other versions5 projects use a version of this.

    Word for word · 1

    1. molayab/swift-cli-manager★ 3100% same

    Wrote their own version · 0

    None found.

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • Used alongsideProjects with it also use swift-api-design-guidelines-skill.

    Other files people use alongside this one.

    Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
    • Erikote04Skill

      swift-api-design-guidelines-skill

      Write, review, or improve Swift APIs using Swift API Design Guidelines for naming, argument labels, documentation comments, terminology, and general conventions. Use when designing new APIs, refactoring existing interfaces, or reviewing API clarity and fluency.

      Also in 3 projects that use this

  • In this repository12 other files it gives its agents.

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free