opencode-skills-antigravity 1.0.12 → 1.0.14

package/bundled-skills/snowflake-development/SKILL.md

@@ -0,0 +1,233 @@
+---
+name: snowflake-development
+description: "Comprehensive Snowflake development assistant covering SQL best practices, data pipeline design (Dynamic Tables, Streams, Tasks, Snowpipe), Cortex AI functions, Cortex Agents, Snowpark Python, dbt integration, performance tuning, and security hardening."
+category: data-engineering
+risk: safe
+source: community
+date_added: "2026-03-24"
+---
+
+# Snowflake Development
+
+You are a Snowflake development expert. Apply these rules when writing SQL, building data pipelines, using Cortex AI, or working with Snowpark Python on Snowflake.
+
+## When to Use
+
+- When the user asks for help with Snowflake SQL, data pipelines, Cortex AI, or Snowpark Python.
+- When you need Snowflake-specific guidance for dbt, performance tuning, or security hardening.
+
+## SQL Best Practices
+
+### Naming and Style
+
+- Use `snake_case` for all identifiers. Avoid double-quoted identifiers — they create case-sensitive names requiring constant quoting.
+- Use CTEs (`WITH` clauses) over nested subqueries.
+- Use `CREATE OR REPLACE` for idempotent DDL.
+- Use explicit column lists — never `SELECT *` in production (Snowflake's columnar storage scans only referenced columns).
+
+### Stored Procedures — Colon Prefix Rule
+
+In SQL stored procedures (BEGIN...END blocks), variables and parameters **must** use the colon `:` prefix inside SQL statements. Without it, Snowflake raises "invalid identifier" errors.
+
+BAD:
+```sql
+CREATE PROCEDURE my_proc(p_id INT) RETURNS STRING LANGUAGE SQL AS
+BEGIN
+    LET result STRING;
+    SELECT name INTO result FROM users WHERE id = p_id;
+    RETURN result;
+END;
+```
+
+GOOD:
+```sql
+CREATE PROCEDURE my_proc(p_id INT) RETURNS STRING LANGUAGE SQL AS
+BEGIN
+    LET result STRING;
+    SELECT name INTO :result FROM users WHERE id = :p_id;
+    RETURN result;
+END;
+```
+
+### Semi-Structured Data
+
+- VARIANT, OBJECT, ARRAY for JSON/Avro/Parquet/ORC.
+- Access nested fields: `src:customer.name::STRING`. Always cast: `src:price::NUMBER(10,2)`.
+- VARIANT null vs SQL NULL: JSON `null` is stored as `"null"`. Use `STRIP_NULL_VALUE = TRUE` on load.
+- Flatten arrays: `SELECT f.value:name::STRING FROM my_table, LATERAL FLATTEN(input => src:items) f;`
+
+### MERGE for Upserts
+
+```sql
+MERGE INTO target t USING source s ON t.id = s.id
+WHEN MATCHED THEN UPDATE SET t.name = s.name, t.updated_at = CURRENT_TIMESTAMP()
+WHEN NOT MATCHED THEN INSERT (id, name, updated_at) VALUES (s.id, s.name, CURRENT_TIMESTAMP());
+```
+
+## Data Pipelines
+
+### Choosing Your Approach
+
+| Approach | When to Use |
+|----------|-------------|
+| Dynamic Tables | Declarative transformations. **Default choice.** Define the query, Snowflake handles refresh. |
+| Streams + Tasks | Imperative CDC. Use for procedural logic, stored procedure calls. |
+| Snowpipe | Continuous file loading from S3/GCS/Azure. |
+
+### Dynamic Tables
+
+```sql
+CREATE OR REPLACE DYNAMIC TABLE cleaned_events
+    TARGET_LAG = '5 minutes'
+    WAREHOUSE = transform_wh
+    AS
+    SELECT event_id, event_type, user_id, event_timestamp
+    FROM raw_events
+    WHERE event_type IS NOT NULL;
+```
+
+Key rules:
+- Set `TARGET_LAG` progressively: tighter at top, looser at bottom.
+- Incremental DTs **cannot** depend on Full refresh DTs.
+- `SELECT *` breaks on schema changes — use explicit column lists.
+- Change tracking must stay enabled on base tables.
+- Views cannot sit between two Dynamic Tables.
+
+### Streams and Tasks
+
+```sql
+CREATE OR REPLACE STREAM raw_stream ON TABLE raw_events;
+
+CREATE OR REPLACE TASK process_events
+    WAREHOUSE = transform_wh
+    SCHEDULE = 'USING CRON 0 */1 * * * America/Los_Angeles'
+    WHEN SYSTEM$STREAM_HAS_DATA('raw_stream')
+    AS INSERT INTO cleaned_events SELECT ... FROM raw_stream;
+
+-- Tasks start SUSPENDED — you MUST resume them
+ALTER TASK process_events RESUME;
+```
+
+## Cortex AI
+
+### Function Reference
+
+| Function | Purpose |
+|----------|---------|
+| `AI_COMPLETE` | LLM completion (text, images, documents) |
+| `AI_CLASSIFY` | Classify into categories (up to 500 labels) |
+| `AI_FILTER` | Boolean filter on text/images |
+| `AI_EXTRACT` | Structured extraction from text/images/documents |
+| `AI_SENTIMENT` | Sentiment score (-1 to 1) |
+| `AI_PARSE_DOCUMENT` | OCR or layout extraction |
+| `AI_REDACT` | PII removal |
+
+**Deprecated (do NOT use):** `COMPLETE`, `CLASSIFY_TEXT`, `EXTRACT_ANSWER`, `PARSE_DOCUMENT`, `SUMMARIZE`, `TRANSLATE`, `SENTIMENT`, `EMBED_TEXT_768`.
+
+### TO_FILE — Common Error Source
+
+Stage path and filename are **SEPARATE** arguments:
+
+```sql
+-- BAD: TO_FILE('@stage/file.pdf')
+-- GOOD:
+TO_FILE('@db.schema.mystage', 'invoice.pdf')
+```
+
+### Use AI_CLASSIFY for Classification (Not AI_COMPLETE)
+
+```sql
+SELECT AI_CLASSIFY(ticket_text,
+    ['billing', 'technical', 'account']):labels[0]::VARCHAR AS category
+FROM tickets;
+```
+
+### Cortex Agents
+
+```sql
+CREATE OR REPLACE AGENT my_db.my_schema.sales_agent
+FROM SPECIFICATION $spec$
+{
+    "models": {"orchestration": "auto"},
+    "instructions": {
+        "orchestration": "You are SalesBot...",
+        "response": "Be concise."
+    },
+    "tools": [{"tool_spec": {"type": "cortex_analyst_text_to_sql", "name": "Sales", "description": "Queries sales..."}}],
+    "tool_resources": {"Sales": {"semantic_model_file": "@stage/model.yaml"}}
+}
+$spec$;
+```
+
+Agent rules:
+- Use `$spec$` delimiter (not `$$`).
+- `models` must be an object, not an array.
+- `tool_resources` is a separate top-level object, not nested inside tools.
+- Do NOT include empty/null values in edit specs — clears existing values.
+- Tool descriptions are the #1 quality factor.
+- Never modify production agents directly — clone first.
+
+## Snowpark Python
+
+```python
+from snowflake.snowpark import Session
+import os
+
+session = Session.builder.configs({
+    "account": os.environ["SNOWFLAKE_ACCOUNT"],
+    "user": os.environ["SNOWFLAKE_USER"],
+    "password": os.environ["SNOWFLAKE_PASSWORD"],
+    "role": "my_role", "warehouse": "my_wh",
+    "database": "my_db", "schema": "my_schema"
+}).create()
+```
+
+- Never hardcode credentials.
+- DataFrames are lazy — executed on `collect()`/`show()`.
+- Do NOT use `collect()` on large DataFrames — process server-side.
+- Use **vectorized UDFs** (10-100x faster) for batch/ML workloads instead of scalar UDFs.
+
+## dbt on Snowflake
+
+Dynamic table materialization (streaming/near-real-time marts):
+```sql
+{{ config(materialized='dynamic_table', snowflake_warehouse='transforming', target_lag='1 hour') }}
+```
+
+Incremental materialization (large fact tables):
+```sql
+{{ config(materialized='incremental', unique_key='event_id') }}
+```
+
+Snowflake-specific configs (combine with any materialization):
+```sql
+{{ config(transient=true, copy_grants=true, query_tag='team_daily') }}
+```
+
+- Do NOT use `{{ this }}` without `{% if is_incremental() %}` guard.
+- Use `dynamic_table` materialization for streaming/near-real-time marts.
+
+## Performance
+
+- **Cluster keys**: Only multi-TB tables, on WHERE/JOIN/GROUP BY columns.
+- **Search Optimization**: `ALTER TABLE t ADD SEARCH OPTIMIZATION ON EQUALITY(col);`
+- **Warehouse sizing**: Start X-Small, scale up. `AUTO_SUSPEND = 60`, `AUTO_RESUME = TRUE`.
+- **Separate warehouses** per workload.
+- Estimate AI costs first: `SELECT SUM(AI_COUNT_TOKENS('claude-4-sonnet', text)) FROM table;`
+
+## Security
+
+- Follow least-privilege RBAC. Use database roles for object-level grants.
+- Audit ACCOUNTADMIN regularly: `SHOW GRANTS OF ROLE ACCOUNTADMIN;`
+- Use network policies for IP allowlisting.
+- Use masking policies for PII columns and row access policies for multi-tenant isolation.
+
+## Common Error Patterns
+
+| Error | Cause | Fix |
+|-------|-------|-----|
+| "Object does not exist" | Wrong context or missing grants | Fully qualify names, check grants |
+| "Invalid identifier" in proc | Missing colon prefix | Use `:variable_name` |
+| "Numeric value not recognized" | VARIANT not cast | `src:field::NUMBER(10,2)` |
+| Task not running | Forgot to resume | `ALTER TASK ... RESUME` |
+| DT refresh failing | Schema change or tracking disabled | Use explicit columns, check change tracking |

package/bundled-skills/swift-concurrency-expert/SKILL.md

@@ -0,0 +1,113 @@
+---
+name: swift-concurrency-expert
+description: Review and fix Swift concurrency issues such as actor isolation and Sendable violations.
+risk: safe
+source: "Dimillian/Skills (MIT)"
+date_added: "2026-03-25"
+---
+
+# Swift Concurrency Expert
+
+## Overview
+
+Review and fix Swift Concurrency issues in Swift 6.2+ codebases by applying actor isolation, Sendable safety, and modern concurrency patterns with minimal behavior changes.
+
+## When to Use
+
+- When the user asks to review Swift concurrency usage or fix compiler diagnostics.
+- When you need guidance on actor isolation, `Sendable`, `@MainActor`, or async migration.
+
+## Workflow
+
+### 1. Triage the issue
+
+- Capture the exact compiler diagnostics and the offending symbol(s).
+- Check project concurrency settings: Swift language version (6.2+), strict concurrency level, and whether approachable concurrency (default actor isolation / main-actor-by-default) is enabled.
+- Identify the current actor context (`@MainActor`, `actor`, `nonisolated`) and whether a default actor isolation mode is enabled.
+- Confirm whether the code is UI-bound or intended to run off the main actor.
+
+### 2. Apply the smallest safe fix
+
+Prefer edits that preserve existing behavior while satisfying data-race safety.
+
+Common fixes:
+- **UI-bound types**: annotate the type or relevant members with `@MainActor`.
+- **Protocol conformance on main actor types**: make the conformance isolated (e.g., `extension Foo: @MainActor SomeProtocol`).
+- **Global/static state**: protect with `@MainActor` or move into an actor.
+- **Background work**: move expensive work into a `@concurrent` async function on a `nonisolated` type or use an `actor` to guard mutable state.
+- **Sendable errors**: prefer immutable/value types; add `Sendable` conformance only when correct; avoid `@unchecked Sendable` unless you can prove thread safety.
+
+### 3. Verify the fix
+
+- Rebuild and confirm all concurrency diagnostics are resolved with no new warnings introduced.
+- Run the test suite to check for regressions — concurrency changes can introduce subtle runtime issues even when the build is clean.
+- If the fix surfaces new warnings, treat each one as a fresh triage (return to step 1) and resolve iteratively until the build is clean and tests pass.
+
+### Examples
+
+**UI-bound type — adding `@MainActor`**
+
+```swift
+// Before: data-race warning because ViewModel is accessed from the main thread
+// but has no actor isolation
+class ViewModel: ObservableObject {
+    @Published var title: String = ""
+    func load() { title = "Loaded" }
+}
+
+// After: annotate the whole type so all stored state and methods are
+// automatically isolated to the main actor
+@MainActor
+class ViewModel: ObservableObject {
+    @Published var title: String = ""
+    func load() { title = "Loaded" }
+}
+```
+
+**Protocol conformance isolation**
+
+```swift
+// Before: compiler error — SomeProtocol method is nonisolated but the
+// conforming type is @MainActor
+@MainActor
+class Foo: SomeProtocol {
+    func protocolMethod() { /* accesses main-actor state */ }
+}
+
+// After: scope the conformance to @MainActor so the requirement is
+// satisfied inside the correct isolation context
+@MainActor
+extension Foo: SomeProtocol {
+    func protocolMethod() { /* safely accesses main-actor state */ }
+}
+```
+
+**Background work with `@concurrent`**
+
+```swift
+// Before: expensive computation blocks the main actor
+@MainActor
+func processData(_ input: [Int]) -> [Int] {
+    input.map { heavyTransform($0) }   // runs on main thread
+}
+
+// After: hop off the main actor for the heavy work, then return the result
+// The caller awaits the result and stays on its own actor
+nonisolated func processData(_ input: [Int]) async -> [Int] {
+    await Task.detached(priority: .userInitiated) {
+        input.map { heavyTransform($0) }
+    }.value
+}
+
+// Or, using a @concurrent async function (Swift 6.2+):
+@concurrent
+func processData(_ input: [Int]) async -> [Int] {
+    input.map { heavyTransform($0) }
+}
+```
+
+## Reference material
+
+- See `references/swift-6-2-concurrency.md` for Swift 6.2 changes, patterns, and examples.
+- See `references/approachable-concurrency.md` when the project is opted into approachable concurrency mode.
+- See `references/swiftui-concurrency-tour-wwdc.md` for SwiftUI-specific concurrency guidance.

package/bundled-skills/swift-concurrency-expert/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Swift Concurrency Expert"
+  short_description: "Review and fix Swift concurrency"
+  default_prompt: "Use $swift-concurrency-expert to review this Swift code for concurrency issues and fix the relevant diagnostics."

package/bundled-skills/swift-concurrency-expert/references/approachable-concurrency.md

@@ -0,0 +1,63 @@
+## Approachable Concurrency (Swift 6.2) - project mode quick guide
+
+Use this reference when the project has opted into the Swift 6.2 approachable
+concurrency settings (default actor isolation / main-actor-by-default).
+
+## Detect the mode
+
+Check Xcode build settings under "Swift Compiler - Concurrency":
+- Swift language version (must be 6.2+).
+- Default actor isolation / Main Actor by default.
+- Strict concurrency checking level (Complete/Targeted/Minimal).
+
+For SwiftPM, inspect Package.swift swiftSettings for the same flags.
+
+## Behavior changes to expect
+
+- Async functions stay on the caller's actor by default; they don't hop to a
+  global concurrent executor unless the implementation chooses to.
+- Main-actor-by-default reduces data race errors for UI-bound code and global
+  state, because mutable state is implicitly protected.
+- Protocol conformances can be isolated (e.g., `extension Foo: @MainActor Bar`).
+
+## How to apply fixes in this mode
+
+- Prefer minimal annotations; let main-actor-by-default do the work when the
+  code is UI-bound.
+- Use isolated conformances instead of forcing `nonisolated` workarounds.
+- Keep global or shared mutable state on the main actor unless there is a clear
+  performance need to offload it.
+
+## When to opt out or offload work
+
+- Use `@concurrent` on async functions that must run on the concurrent pool.
+- Make types or members `nonisolated` only when they are truly thread-safe and
+  used off the main actor.
+- Continue to respect Sendable boundaries when values cross actors or tasks.
+
+## Common pitfalls
+
+- `Task.detached` ignores inherited actor context; avoid it unless you truly
+  need to break isolation.
+- Main-actor-by-default can hide performance issues if CPU-heavy work stays on
+  the main actor; move that work into `@concurrent` async functions.
+
+## Keywords (from source cheat sheet)
+
+| Keyword | What it does |
+| --- | --- |
+| `async` | Function can pause |
+| `await` | Pause here until done |
+| `Task { }` | Start async work, inherits context |
+| `Task.detached { }` | Start async work, no inherited context |
+| `@MainActor` | Runs on main thread |
+| `actor` | Type with isolated mutable state |
+| `nonisolated` | Opts out of actor isolation |
+| `Sendable` | Safe to pass between isolation domains |
+| `@concurrent` | Always run on background (Swift 6.2+) |
+| `async let` | Start parallel work |
+| `TaskGroup` | Dynamic parallel work |
+
+## Source
+
+https://fuckingapproachableswiftconcurrency.com/en/

package/bundled-skills/swift-concurrency-expert/references/swift-6-2-concurrency.md

@@ -0,0 +1,272 @@
+## Concurrent programming updates in Swift 6.2
+
+Concurrent programming is hard because sharing memory between multiple tasks is prone to mistakes that lead to unpredictable behavior.
+
+## Data-race safety
+
+ Data-race safety in Swift 6 prevents these mistakes at compile time, so you can write concurrent code without fear of introducing hard-to-debug runtime bugs. But in many cases, the most natural code to write is prone to data races, leading to compiler errors that you have to address. A class with mutable state, like this `PhotoProcessor` class, is safe as long as you don’t access it concurrently.
+
+```swift
+class PhotoProcessor {
+  func extractSticker(data: Data, with id: String?) async -> Sticker? {     }
+}
+
+@MainActor
+final class StickerModel {
+  let photoProcessor = PhotoProcessor()
+
+  func extractSticker(_ item: PhotosPickerItem) async throws -> Sticker? {
+    guard let data = try await item.loadTransferable(type: Data.self) else {
+      return nil
+    }
+
+    // Error: Sending 'self.photoProcessor' risks causing data races
+    // Sending main actor-isolated 'self.photoProcessor' to nonisolated instance method 'extractSticker(data:with:)'
+    // risks causing data races between nonisolated and main actor-isolated uses
+    return await photoProcessor.extractSticker(data: data, with: item.itemIdentifier)
+  }
+}
+```
+
+ It has an async method to extract a `Sticker` by computing the subject of the given image data. But if you try to call `extractSticker` from UI code on the main actor, you’ll get an error that the call risks causing data races. This is because there are several places in the language that offload work to the background implicitly, even if you never needed code to run in parallel.
+
+Swift 6.2 changes this philosophy to stay single threaded by default until you choose to introduce concurrency.
+
+```swift
+class PhotoProcessor {
+  func extractSticker(data: Data, with id: String?) async -> Sticker? {     }
+}
+
+@MainActor
+final class StickerModel {
+  let photoProcessor = PhotoProcessor()
+
+  func extractSticker(_ item: PhotosPickerItem) async throws -> Sticker? {
+    guard let data = try await item.loadTransferable(type: Data.self) else {
+      return nil
+    }
+
+    // No longer a data race error in Swift 6.2 because of Approachable Concurrency and default actor isolation
+    return await photoProcessor.extractSticker(data: data, with: item.itemIdentifier)
+  }
+}
+```
+
+The language changes in Swift 6.2 make the most natural code to write data race free by default. This provides a more approachable path to introducing concurrency in a project.
+
+When you choose to introduce concurrency because you want to run code in parallel, data-race safety will protect you.
+
+First, we've made it easier to call async functions on types with mutable state. Instead of eagerly offloading async functions that aren't tied to a specific actor, the function will continue to run on the actor it was called from. This eliminates data races because the values passed into the async function are never sent outside the actor. Async functions can still offload work in their implementation, but clients don’t have to worry about their mutable state.
+
+Next, we’ve made it easier to implement conformances on main actor types. Here I have a protocol called `Exportable`, and I’m trying to implement a conformance for my main actor `StickerModel` class. The export requirement doesn’t have actor isolation, so the language assumed that it could be called from off the main actor, and prevented `StickerModel` from using main actor state in its implementation.
+
+```swift
+protocol Exportable {
+  func export()
+}
+
+extension StickerModel: Exportable { // error: Conformance of 'StickerModel' to protocol 'Exportable' crosses into main actor-isolated code and can cause data races
+  func export() {
+    photoProcessor.exportAsPNG()
+  }
+}
+```
+
+Swift 6.2 supports these conformances. A conformance that needs main actor state is called an *isolated* conformance. This is safe because the compiler ensures a main actor conformance is only used on the main actor.
+
+```swift
+// Isolated conformances
+
+protocol Exportable {
+  func export()
+}
+
+extension StickerModel: @MainActor Exportable {
+  func export() {
+    photoProcessor.exportAsPNG()
+  }
+}
+```
+
+ I can create an `ImageExporter` type that adds a `StickerModel` to an array of any `Exportable` items as long as it stays on the main actor.
+
+```swift
+ // Isolated conformances
+
+@MainActor
+struct ImageExporter {
+  var items: [any Exportable]
+
+  mutating func add(_ item: StickerModel) {
+    items.append(item)
+  }
+
+  func exportAll() {
+    for item in items {
+      item.export()
+    }
+  }
+}
+```
+
+But if I allow `ImageExporter` to be used from anywhere, the compiler prevents adding `StickerModel` to the array because it isn’t safe to call export on `StickerModel` from outside the main actor.
+
+```swift
+// Isolated conformances
+
+nonisolated
+struct ImageExporter {
+  var items: [any Exportable]
+
+  mutating func add(_ item: StickerModel) {
+    items.append(item) // error: Main actor-isolated conformance of 'StickerModel' to 'Exportable' cannot be used in nonisolated context
+  }
+
+  func exportAll() {
+    for item in items {
+      item.export()
+    }
+  }
+}
+```
+
+With isolated conformances, you only have to solve data race safety issues when the code indicates that it uses the conformance concurrently.
+
+## Global State
+
+Global and static variables are prone to data races because they allow mutable state to be accessed from anywhere.
+
+```swift
+final class StickerLibrary {
+  static let shared: StickerLibrary = .init() // error: Static property 'shared' is not concurrency-safe because non-'Sendable' type 'StickerLibrary' may have shared mutable state
+}
+```
+
+The most common way to protect global state is with the main actor.
+
+```swift
+final class StickerLibrary {
+  @MainActor
+  static let shared: StickerLibrary = .init()
+}
+```
+
+ And it’s common to annotate an entire class with the main actor to protect all of its mutable state, especially in a project that doesn’t have a lot of concurrent tasks.
+
+```swift
+@MainActor
+final class StickerLibrary {
+  static let shared: StickerLibrary = .init()
+}
+```
+
+You can model a program that's entirely single-threaded by writing `@MainActor` on everything in your project.
+
+```swift
+@MainActor
+final class StickerLibrary {
+  static let shared: StickerLibrary = .init()
+}
+
+@MainActor
+final class StickerModel {
+  let photoProcessor: PhotoProcessor
+
+  var selection: [PhotosPickerItem]
+}
+
+extension StickerModel: @MainActor Exportable {
+  func export() {
+    photoProcessor.exportAsPNG()
+  }
+}
+```
+
+To make it easier to model single-threaded code, we’ve introduced a mode to infer main actor by default.
+
+```swift
+// Mode to infer main actor by default in Swift 6.2
+
+final class StickerLibrary {
+  static let shared: StickerLibrary = .init()
+}
+
+final class StickerModel {
+  let photoProcessor: PhotoProcessor
+
+  var selection: [PhotosPickerItem]
+}
+
+extension StickerModel: Exportable {
+  func export() {
+    photoProcessor.exportAsPNG()
+  }
+}
+```
+
+ This eliminates data-race safety errors about unsafe global and static variables, calls to other main actor functions like ones from the SDK, and more, because the main actor protects all mutable state by default. It also reduces concurrency annotations in code that’s mostly single-threaded. This mode is great for projects that do most of the work on the main actor, and concurrent code is encapsulated within specific types or files. It’s opt-in and it’s recommended for apps, scripts, and other executable targets.
+
+## Offloading work to the background
+
+Offloading work to the background is still important for performance, such as keeping apps responsive when performing CPU-intensive tasks.
+
+Let’s look at the implementation of the `extractSticker` method on `PhotoProcessor`.
+
+```swift
+// Explicitly offloading async work
+
+class PhotoProcessor {
+  var cachedStickers: [String: Sticker]
+
+  func extractSticker(data: Data, with id: String) async -> Sticker {
+      if let sticker = cachedStickers[id] {
+        return sticker
+      }
+
+      let sticker = await Self.extractSubject(from: data)
+      cachedStickers[id] = sticker
+      return sticker
+  }
+
+  // Offload expensive image processing using the @concurrent attribute.
+  @concurrent
+  static func extractSubject(from data: Data) async -> Sticker { }
+}
+```
+
+It first checks whether it already extracted a sticker for an image, so it can return the cached sticker immediately. If the sticker hasn’t been cached, it extracts the subject from the image data and creates a new sticker. The `extractSubject` method performs expensive image processing that I don’t want to block the main actor or any other actor.
+
+I can offload this work using the `@concurrent` attribute. `@concurrent` ensures that a function always runs on the concurrent thread pool, freeing up the actor to run other tasks at the same time.
+
+### An example
+
+Say you have a function called `process` that you would like to run on a background thread. To call that function on a background thread you need to:
+
+- make sure the structure or class is `nonisolated`
+- add the `@concurrent` attribute to the function you want to run in the background
+- add the keyword `async` to the function if it is not already asynchronous
+- and then add the keyword `await` to any callers
+
+Like this:
+
+```swift
+nonisolated struct PhotoProcessor {
+
+    @concurrent
+    func process(data: Data) async -> ProcessedPhoto? { ... }
+}
+
+// Callers with the added await
+processedPhotos[item.id] = await PhotoProcessor().process(data: data)
+```
+
+
+## Summary
+
+These language changes work together to make concurrency more approachable.
+
+You start by writing code that runs on the main actor by default, where there’s no risk of data races. When you start to use async functions, those functions run wherever they’re called from. There’s still no risk of data races because all of your code still runs on the main actor. When you’re ready to embrace concurrency to improve performance, it’s easy to offload specific code to the background to run in parallel.
+
+Some of these language changes are opt-in because they require changes in your project to adopt. You can find and enable all of the approachable concurrency language changes under the Swift Compiler - Concurrency section of Xcode build settings. You can also enable these features in a Swift package manifest file using the SwiftSettings API.
+
+ Swift 6.2 includes migration tooling to help you make the necessary code changes automatically. You can learn more about migration tooling at swift.org/migration.