Zajebiście Przystępne
Swift Concurrency

Kod asynchroniczny: async/await

Większość tego, co robią aplikacje, to czekanie. Pobierają dane z serwera — czekają na odpowiedź. Odczytują plik z dysku — czekają na bajty. Odpytują bazę danych — czekają na wyniki.

Przed systemem współbieżności Swifta to czekanie wyrażało się za pomocą callbacków, delegatów lub Combine. To działa, ale zagnieżdżone callbacki szybko stają się nieczytelne, a Combine ma stromą krzywą uczenia.

async/await daje Swiftowi nowy sposób obsługi czekania. Zamiast callbacków piszesz kod, który wygląda jak sekwencyjny — wstrzymuje swoje działanie, czeka i je wznawia. Pod spodem środowisko uruchomieniowe Swifta zarządza tymi pauzami w efektywny sposób. Jednak to, czy Twoja aplikacja faktycznie pozostanie responsywna podczas czekania, zależy od tego, gdzie kod jest wykonywany, co omówimy później.

Funkcja async to taka, która może potrzebować zatrzymań. Oznaczasz ją async, a gdy ją wywołujesz, używasz await, żeby powiedzieć „zatrzymaj się tutaj, aż to się skończy":

func fetchUser(id: Int) async throws -> User {
    let url = URL(string: "https://api.example.com/users/\(id)")!
    let (data, _) = try await URLSession.shared.data(from: url)  // Zawiesza wykonywanie tutaj
    return try JSONDecoder().decode(User.self, from: data)
}

// Wywołanie
let user = try await fetchUser(id: 123)
// Kod tutaj wykonuje się po zakończeniu fetchUser

Twój kod zatrzymuje się przy każdym await — nosi to nazwę zawieszenia (suspension). Gdy praca zostaje wykonana, kod zostaje wznowiony dokładnie tam, gdzie doszło do jego zatrzymania. Zawieszenie daje Swiftowi możliwość wykonywania innej pracy w czasie czekania.

Czekanie na nie po kolei

A co, jeśli musisz pobrać kilka rzeczy? Możesz oczekiwać na wyniki ich działania po kolei:

let avatar = try await fetchImage("avatar.jpg")
let banner = try await fetchImage("banner.jpg")
let bio = try await fetchBio()

Jest to jednak wolne — każde zadanie czeka na zakończenie poprzedniego. Użyj async let, żeby uruchomić je równolegle:

func loadProfile() async throws -> Profile {
    async let avatar = fetchImage("avatar.jpg")
    async let banner = fetchImage("banner.jpg")
    async let bio = fetchBio()

    // Wszystkie trzy pobierają się równolegle!
    return Profile(
        avatar: try await avatar,
        banner: try await banner,
        bio: try await bio
    )
}

Każda instrukcja async let startuje natychmiast. await zbiera wyniki.

Zarządzanie pracą: Taski

Task to jednostka pracy asynchronicznej, którą możesz zarządzać. Napisałeś funkcje async, ale to Task faktycznie je uruchamia - to sposób na uruchomienie kodu async z kodu synchronicznego, który daje Ci nad nią kontrolę: pozwala poczekać na wynik zadania, anulować jego wykonanie lub pozwolić mu działać w tle.

Załóżmy, że tworzysz ekran profilu. Załaduj awatar, gdy pojawi się widok, używając modyfikatora .task, który automatycznie anuluje się, gdy widok zniknie:

struct ProfileView: View {
    @State private var avatar: Image?

    var body: some View {
        Group {
            if let avatar {
                avatar
            } else {
                ProgressView()
            }
        }
        .task { avatar = await downloadAvatar() }
    }
}

Jeśli użytkownicy mogą przełączać się między profilami, użyj .task(id:), żeby przeładować dane, gdy wybór się zmieni:

struct ProfileView: View {
    var userID: String
    @State private var avatar: Image?

    var body: some View {
        Group {
            if let avatar {
                avatar
            } else {
                ProgressView()
            }
        }
        .task(id: userID) { avatar = await downloadAvatar(for: userID) }
    }
}

Gdy użytkownik wybierze „Zapisz", utwórz Task ręcznie:

Button("Save") {
    Task { await saveProfile() }
}

Dostęp do wyników Tasku

Gdy tworzysz Task, otrzymujesz referencję do niego. Użyj .value, żeby poczekać na wynik i go pobrać:

let handle = Task {
    return await fetchUserData()
}
let userData = await handle.value  // Zawiesza działanie do zakończenia tasku

Jest to przydatne, gdy potrzebujesz wyniku później lub gdy chcesz przechować referencję tasku i oczekiwać na jego zakończenie w innym miejscu.

A co, jeśli musisz załadować awatar, bio i statystyki jednocześnie? Użyj TaskGroup, żeby pobrać je równolegle:

try await withThrowingTaskGroup(of: Void.self) { group in
    group.addTask { avatar = try await downloadAvatar(for: userID) }
    group.addTask { bio = try await fetchBio(for: userID) }
    group.addTask { stats = try await fetchStats(for: userID) }
    try await group.waitForAll()
}

Taski wewnątrz grupy to taski potomne (child tasks), powiązane z rodzicem. Kilka rzeczy do zapamiętania:

• Anulowanie jest propagowane: anuluj rodzica, a wszystkie dzieci też zostaną anulowane
• Błędy: rzucony błąd anuluje sąsiadujące taski (na tym samym poziomie) lub pozostałe zadania potomne i jest ponownie rzucany, ale dopiero gdy konsumujesz wyniki za pomocą next(), waitForAll() lub iteracji
• Kolejność zakończenia: wyniki przychodzą w kolejności kończenia tasków, nie ich dodawania
• Czeka na wszystkie: grupa nie zwróci rezultatów dopóki każde z dzieci nie zakończy swojego działania lub nie zostanie anulowane

To jest współbieżność strukturalna: praca zorganizowana w strukturę drzewa, którą łatwo zrozumieć i posprzątać.

Gdzie to wszystko się dzieje: Od wątków do domen izolacji

Do tej pory mówiliśmy o tym, kiedy kod się wykonuje (async/await) i jak go organizować (Taski). Teraz: gdzie się wykonuje i jak zapewnić mu bezpieczeństwo?

Stary świat: Wiele opcji, zero bezpieczeństwa

Przed systemem współbieżności Swifta miałeś kilka sposobów zarządzania wykonywaniem:

Wszystkie działały, ale bezpieczeństwo było całkowicie po Twojej stronie. Kompilator nie mógł pomóc, jeśli zapomniałeś dispatchować na main albo jeśli dwie kolejki jednocześnie korzystały z tych samych danych.

Problem: Wyścigi danych (Data Races)

Wyścig danych (data race) zachodzi, gdy dwa wątki jednocześnie uzyskują dostęp do tego samego miejsca w pamięci, a przynajmniej jeden z nich zapisuje:

var count = 0

DispatchQueue.global().async { count += 1 }
DispatchQueue.global().async { count += 1 }

// Niezdefiniowane zachowanie: crash, uszkodzenie pamięci lub zła wartość

Wyścigi danych to niezdefiniowane zachowanie. Mogą crashować, uszkadzać pamięć lub po cichu dawać złe wyniki. Twoja aplikacja działa świetnie w testach, a potem losowo crashuje na produkcji. Tradycyjne mechanizmy, takie jak blokady (locks) i semafory pomagają, ale są ręczne i podatne na błędy.

Zmiana: Od wątków do izolacji

Model współbieżności Swifta zadaje inne pytanie. Zamiast „na jakim wątku to powinno działać?", pyta: „kto ma prawo dostępu do tych danych?"

To jest izolacja. Zamiast ręcznie rozdzielać pracę na wątki, deklarujesz granice wokół danych. Kompilator wymusza przestrzeganie tych granic na etapie kompilacji, a nie w czasie wykonywania programu.

Trzy domeny izolacji

1. MainActor

@MainActor to globalny aktor reprezentujący domenę izolacji głównego wątku. Jest wyjątkowy, bo frameworki UI (UIKit, AppKit, SwiftUI) wymagają dostępu właśnie do wątku głównego.

@MainActor
class ViewModel {
    var items: [Item] = []  // Chronione przez izolację MainActor
}

Gdy oznaczysz coś @MainActor, nie mówisz „dispatchuj to na główny wątek". Mówisz „to należy do domeny izolacji głównego aktora". Kompilator wymusza, żeby wszystko, co używa tego, było albo na MainActor, albo użyło await w celu przekroczenia granicy.

2. Aktorzy (Actors)

Aktor chroni swój własny mutowalny stan. Gwarantuje, że tylko jeden fragment kodu może jednocześnie uzyskać dostęp do jego danych:

actor BankAccount {
    var balance: Double = 0

    func deposit(_ amount: Double) {
        balance += amount  // Bezpieczne: aktor gwarantuje wyłączny dostęp
    }
}

// Z zewnątrz musisz użyć `await`, żeby przekroczyć granicę
await account.deposit(100)

Aktorzy to nie wątki. Aktor to granica izolacji. Środowisko uruchomieniowe Swifta decyduje, który wątek faktycznie wykonuje kod aktora. Nie kontrolujesz tego i nie musisz.

3. Nonisolated

Kod oznaczony nonisolated rezygnuje z izolacji aktora. Może być wywołany z dowolnego miejsca bez await, ale nie może uzyskać dostępu do chronionego stanu aktora:

actor BankAccount {
    var balance: Double = 0

    nonisolated func bankName() -> String {
        "Acme Bank"  // Brak dostępu do stanu aktora, bezpieczne wywołanie z dowolnego miejsca
    }
}

let name = account.bankName()  // Bez await

// Działa na MainActor (domyślnie)
func updateUI() async { }

// Działa na wątku w tle (opcjonalne)
@concurrent func processLargeFile() async { }

Co może przekraczać domeny izolacji: Sendable

Domeny izolacji chronią dane, ale w końcu musi dojść do ich przekazania. Gdy to robisz, Swift sprawdza, czy jest to bezpieczne.

Pomyśl o tym: jeśli przekażesz referencję do mutowalnej klasy z jednego aktora do drugiego, oba mogą ją jednocześnie modyfikować. To dokładnie ten wyścig danych, któremu próbujemy zapobiec, więc Swift musi wiedzieć: czy te dane mogą być bezpiecznie współdzielone?

Odpowiedzią jest protokół Sendable. To marker, który mówi kompilatorowi „ten typ jest bezpieczny do przekazywania przez granice izolacji":

• Typy Sendable mogą bezpiecznie przekraczać granice (typy wartościowe, niemutowalne dane, aktor)
• Typy non-Sendable nie mogą (klasy z mutowalnym stanem)

// Sendable - to typ wartościowy, każde miejsce dostaje kopię
struct User: Sendable {
    let id: Int
    let name: String
}

// Non-Sendable - to klasa z mutowalnym stanem
class Counter {
    var count = 0  // Dwa miejsca modyfikujące to = katastrofa
}

Tworzenie typów Sendable

Swift automatycznie wnioskuje zgodność z Sendable w przypadku wielu typów:

• Struktury i enumy zawierające wyłącznie właściwości Sendable stają się niejawnie Sendable
• typy aktorów są zawsze Sendable, bo chronią swój własny stan
• Typy @MainActor są Sendable, bo MainActor serializuje dostęp

Sytuacja w przypadku klas jest nieco trudniejsza. Klasa może być zgodna z Sendable tylko jeśli jest oznaczona jako final i wszystkie jej przechowywane właściwości są niemutowalne:

final class APIConfig: Sendable {
    let baseURL: URL      // Niemutowalne
    let timeout: Double   // Niemutowalne
}

Jeśli masz klasę, która jest bezpieczna dla wątków dzięki innym mechanizmom (zamki, zmienne atomowe), możesz użyć @unchecked Sendable, żeby powiedzieć kompilatorowi „zaufaj mi":

final class ThreadSafeCache: @unchecked Sendable {
    private let lock = NSLock()
    private var storage: [String: Data] = [:]
}

Jak izolacja jest dziedziczona

Wiesz już, że domeny izolacji chronią dane, a Sendable kontroluje, co między nimi przechodzi. Jednak jak kod w ogóle trafia do domeny izolacji?

Gdy wywołujesz funkcję lub tworzysz domknięcie, izolacja przepływa przez Twój kod. Z Approachable Concurrency Twoja aplikacja startuje na MainActor i jego izolacja jest propagowana do kodu, który wywołujesz, chyba że coś jawnie ją zmieni. Zrozumienie tego przepływu pomaga przewidywać, gdzie kod się wykonuje i dlaczego kompilator czasem narzeka.

Wywołania funkcji

Gdy wywołujesz funkcję, jej izolacja określa, gdzie dochodzi do jej wykonania:

@MainActor func updateUI() { }      // Zawsze działa na MainActor
func helper() { }                    // Dziedziczy domenę izolacji wywołującego
@concurrent func crunch() async { }  // Działa jawnie poza aktorem

Z Approachable Concurrency większość Twojego kodu dziedziczy domenę izolacji MainActor. Funkcja jest wykonywana tam, gdzie jej wywołujący, o ile nie dojdzie do jawnej rezygnacji z tej opcji.

Domknięcia (closures)

Domknięcia dziedziczą izolację z kontekstu, w którym zostały zdefiniowane:

@MainActor
class ViewModel {
    func setup() {
        let closure = {
            // Dziedziczy MainActor z ViewModel
            self.updateUI()  // Bezpieczne, ta sama domena izolacji
        }
        closure()
    }
}

Dlatego domknięcia akcji Button w SwiftUI mogą bezpiecznie aktualizować @State: dziedziczą izolację MainActor z widoku.

Zadania (Tasks)

Task { } dziedziczy izolację aktora z miejsca, w którym został utworzony:

@MainActor
class ViewModel {
    func doWork() {
        Task {
            // Dziedziczy domenę izolacji MainActora
            self.updateUI()  // Bezpieczne, bez await
        }
    }
}

To zazwyczaj jest to, czego chcesz. Task działa na tym samym aktorze co kod, który go utworzył.

Przerwanie dziedziczenia: Task.detached

Czasem potrzebujesz zadania, które nie odziedziczy żadnego kontekstu:

@MainActor
class ViewModel {
    func doHeavyWork() {
        Task.detached {
            // Bez izolacji aktora, działa w kooperatywnej puli
            let result = await self.expensiveCalculation()
            await MainActor.run {
                self.data = result  // Jawny skok z powrotem
            }
        }
    }
}

Zachowanie izolacji w narzędziach async

Czasem piszesz ogólną funkcję async, która przyjmuje domknięcie — wrapper, funkcję pomocniczą do ponownych prób, określenia zakresu transakcji. Wywołujący przekazuje domknięcie, Twoja funkcja je uruchamia. Proste, prawda?

func measure<T>(
    _ label: String,
    block: () async throws -> T
) async rethrows -> T {
    let start = ContinuousClock.now
    let result = try await block()
    print("\(label): \(ContinuousClock.now - start)")
    return result
}

Jednak gdy wywołujesz to z kontekstu @MainActor, Swift narzeka:

Co się dzieje? Twoje domknięcie przechwytuje stan z MainActora, ale funkcja measure jest oznaczona jako nonisolated. Swift widzi domknięcie non-Sendable przekraczające granicę izolacji — dokładnie to, czemu ma zapobiegać.

Najprostszym rozwiązaniem jest nonisolated(nonsending). To mówi Swiftowi, że funkcja powinna zostać na tym samym kontekście wykonawczym (executorze), który ją wywołał:

nonisolated(nonsending)
func measure<T>(
    _ label: String,
    block: () async throws -> T
) async rethrows -> T {
    let start = ContinuousClock.now
    let result = try await block()
    print("\(label): \(ContinuousClock.now - start)")
    return result
}

Teraz cała funkcja działa na executorze wywołującego. Wywołaj ją z MainActor, a zostanie na MainActor. Wywołaj z własnego aktora, a zostanie tam. Domknięcie nigdy nie przekracza granicy izolacji, więc żadne sprawdzenie Sendable nie jest potrzebne.

Jeśli potrzebujesz jawnego dostępu do aktora, użyj parametru #isolation:

func measure<T>(
    isolation: isolated (any Actor)? = #isolation,
    _ label: String,
    block: () async throws -> T
) async rethrows -> T {
    let start = ContinuousClock.now
    let result = try await block()
    print("\(label): \(ContinuousClock.now - start)")
    return result
}

Oba podejścia są niezbędne do budowania narzędzi async, które mają być przyjemne w użyciu. Bez nich wywołujący musieliby oznaczać swoje domknięcia jako @Sendable lub kombinować, żeby zadowolić kompilator.

Łączenie wszystkiego w całość

Cofnijmy się i zobaczmy, jak wszystkie elementy do siebie pasują.

Swift Concurrency może wydawać się mnóstwem koncepcji: async/await, Task, aktorzy, MainActor, Sendable, domeny izolacji. Ale tak naprawdę jest tylko jedna idea w centrum tego wszystkiego: izolacja jest domyślnie dziedziczona.

Z włączonym Approachable Concurrency Twoja aplikacja startuje na MainActor. To Twój punkt wyjścia. Stamtąd:

• Każda wywoływana funkcja dziedziczy tę izolację
• Każde tworzone domknięcie przechwytuje tę izolację
• Każdy uruchamiany Task { } dziedziczy tę izolację

Nie musisz niczego oznaczać. Nie musisz myśleć o wątkach. Twój kod działa na MainActorze, a izolacja po prostu jest propagowana automatycznie.

Gdy musisz przerwać tę sekwencję dziedziczenia, robisz to w sposób jawny:

• @concurrent mówi „uruchom to na wątku w tle"
• actor mówi „ten typ ma swoją własną domenę izolacji"
• Task.detached { } mówi „zacznij od nowa, nie dziedzicz niczego"

A gdy przekazujesz dane między domenami izolacji, Swift sprawdza, czy jest to bezpieczne. Do tego służy Sendable: oznaczanie typów, które mogą bezpiecznie przekraczać granice.

To wszystko. To cały model:

1. Izolacja jest propagowana z MainActora przez Twój kod
2. Jawnie rezygnujesz, gdy potrzebujesz pracy w tle lub oddzielnego stanu
3. Sendable pilnuje granic, gdy dane przekraczają domeny izolacji

Gdy kompilator narzeka, mówi Ci, że jedna z tych reguł została naruszona. Prześledź dziedziczenie: skąd wzięła się izolacja? Gdzie ma dojść do wykonania kodu? Jakie dane przekraczają granicę? Odpowiedź jest zwykle oczywista, gdy zadasz właściwe pytanie.

Co dalej

Dobra wiadomość: nie musisz opanować wszystkiego w jednej chwili.

Większość aplikacji potrzebuje zaledwie podstaw. Oznacz swoje ViewModele jako @MainActor, użyj async/await do zapytań sieciowych i utwórz Task { }, gdy musisz uruchomić asynchroniczne zadanie po naciśnięciu przycisku. To wszystko. To obsługuje 80% przypadków w rzeczywistych aplikacjach. Kompilator powie Ci, jeśli będziesz potrzebować czegoś więcej.

Gdy potrzebujesz pracy równoległej, sięgnij po async let, żeby pobrać wiele rzeczy naraz lub TaskGroup, gdy liczba tasków jest dynamiczna. Naucz się obsługiwać anulowanie z gracją. To obejmuje aplikacje ze złożonym ładowaniem danych lub funkcjami czasu rzeczywistego.

Zaawansowane wzorce przychodzą później, jeśli w ogóle do tego dojdzie. Własne typy aktorów do współdzielenia mutowalnego stanu, @concurrent do przetwarzania intensywnego dla CPU czy głębokie zrozumienie Sendable to tematy związane z kodem frameworków, serwerami w Swift i złożonymi aplikacjami desktopowymi. Większość programistów nigdy nie będzie ich potrzebować.

Uwaga: Częste błędy

Myślenie, że async = działanie w tle

// To NADAL blokuje główny wątek!
@MainActor
func slowFunction() async {
    let result = expensiveCalculation()  // Praca synchroniczna = blokowanie
    data = result
}

async oznacza „możliwe wstrzymanie wykonania". Faktyczna praca nadal wykonuje się tam, gdzie ma się wykonać. Użyj @concurrent (Swift 6.2) lub Task.detached do wytężonej pracy CPU.

Tworzenie zbyt wielu aktorów

// Przekombinowane
actor NetworkManager { }
actor CacheManager { }
actor DataManager { }

// Lepiej - większość obiektów może korzystać z domeny MainActora
@MainActor
class AppState { }

Potrzebujesz własnego aktora tylko wtedy, gdy masz współdzielony mutowalny stan, który nie może korzystać z domeny MainActora. Reguła Matta Massicotte'a: wprowadź aktora wyłącznie gdy (1) masz stan nie-Sendable, (2) operacje na tym stanie muszą być atomowe i (3) operacje te nie mogą zostać wywołane na istniejącym aktorze. Jeśli nie możesz tego uzasadnić, użyj @MainActor.

Oznaczanie wszystkiego jako Sendable

Nie wszystko musi przekraczać granice izolacji. Jeśli dodajesz @unchecked Sendable wszędzie, cofnij się i zapytaj, czy dane faktycznie muszą się przemieszczać między domenami.

Używanie MainActor.run, gdy nie ma takiej konieczności

// Zbędne
Task {
    let data = await fetchData()
    await MainActor.run {
        self.data = data
    }
}

// Lepiej - po prostu oznacz funkcję jako @MainActor
@MainActor
func loadData() async {
    self.data = await fetchData()
}

MainActor.run rzadko jest właściwym rozwiązaniem. Jeśli potrzebujesz izolacji MainActor, oznacz funkcję jako @MainActor. Jest to rozwiązanie bardziej przejrzyste i kompilator może Ci bardziej pomóc. Zobacz opinię Matta na ten temat.

Blokowanie kooperatywnej puli wątków

// NIGDY tego nie rób - ryzyko zakleszczenia (deadlocka)
func badIdea() async {
    let semaphore = DispatchSemaphore(value: 0)
    Task {
        await doWork()
        semaphore.signal()
    }
    semaphore.wait()  // Blokuje wątek kooperatywny!
}

Kooperatywna pula wątków Swifta ma ograniczoną liczbę wątków. Blokowanie jednego za pomocą DispatchSemaphore, DispatchGroup.wait() lub podobnych wywołań może doprowadzić do zakleszczenia (deadlock). Jeśli musisz połączyć kod synchroniczny z asynchronicznym, użyj async let lub zrefaktoryzuj rozwiązanie, aby działało w pełni asynchronicznie.

func doWork() async {

    // zwróci wynik, gdy wszystkie zadania potomne (subtaski) zakończą swoje działanie
    let result = try await withThrowingTaskGroup() { group in
        group.addTask {
            try await self.performAsyncOperation1()
        }
        group.addTask {
            try await self.performAsyncOperation2()
        }
        // poczekaj na wyniki tasków i zbierz je tutaj
    }
}

func performAsyncOperation1() async throws -> Int {
    return 1
}
func performAsyncOperation2() async throws -> Int {
    return 2
}

var sum = 0
for await result in group {
    sum += result
}
// sum == 3

struct ContentView: View {

    @State private var shouldLoadImage = false

    var body: some View {
        Button("Click Me !") {
            // przełącz flagę
            shouldLoadImage = !shouldLoadImage
        }
        // Widok zarządza subtaskiem
        // startuje przed wyświetleniem widoku
        // i zatrzymuje się gdy widok jest ukryty
        .task(id: shouldLoadImage) {
            // gdy wartość flagi się zmieni, SwiftUI restartuje task
            guard shouldLoadImage else { return }
            await loadImage()
        }
    }
}

Ściągawka: Szybki przegląd

Dalsza lektura

Umiejętność agenta AI

Chcesz, żeby Twój asystent kodowania AI rozumiał Swift Concurrency? Udostępniamy plik SKILL.md, który pakuje te modele mentalne dla agentów AI takich jak Claude Code, Codex, Amp, OpenCode i inne.

Inne umiejętności

• Open-source'owy skill Swift Concurrency dla agentów od Antoine'a

Jak używać

Wybierz swojego agenta i uruchom poniższe komendy:

# Osobista umiejętność (wszystkie Twoje projekty)
mkdir -p ~/.claude/skills/swift-concurrency
curl -o ~/.claude/skills/swift-concurrency/SKILL.md https://fuckingapproachableswiftconcurrency.com/SKILL.md
# Umiejętność projektu (tylko ten projekt)
mkdir -p .claude/skills/swift-concurrency
curl -o .claude/skills/swift-concurrency/SKILL.md https://fuckingapproachableswiftconcurrency.com/SKILL.md

# Instrukcje projektu (zalecane)
curl -o AGENTS.md https://fuckingapproachableswiftconcurrency.com/SKILL.md

# Globalne instrukcje (wszystkie Twoje projekty)
curl -o ~/.codex/AGENTS.md https://fuckingapproachableswiftconcurrency.com/SKILL.md
# Instrukcje projektu (tylko ten projekt)
curl -o AGENTS.md https://fuckingapproachableswiftconcurrency.com/SKILL.md

# Globalne reguły (wszystkie Twoje projekty)
mkdir -p ~/.kiro/steering
curl -o ~/.kiro/steering/swift-concurrency.md https://fuckingapproachableswiftconcurrency.com/SKILL.md
# Reguły projektu (tylko ten projekt)
mkdir -p .kiro/steering
curl -o .kiro/steering/swift-concurrency.md https://fuckingapproachableswiftconcurrency.com/SKILL.md

# Globalne reguły (wszystkie Twoje projekty)
mkdir -p ~/.config/opencode
curl -o ~/.config/opencode/AGENTS.md https://fuckingapproachableswiftconcurrency.com/SKILL.md
# Reguły projektu (tylko ten projekt)
curl -o AGENTS.md https://fuckingapproachableswiftconcurrency.com/SKILL.md

Umiejętność zawiera analogię biurowca, wzorce izolacji, wskazówki dotyczące Sendable, częste błędy i tabele do szybkiego przeglądu. Twój agent będzie automatycznie korzystać z tej wiedzy, gdy pracujesz z kodem Swift Concurrency.