@mrciphersmith/keryx 0.3.3 → 0.3.6

package/src/gdskills/bundled/stacks/swift-ios/skills/swift-build-fix/evals.json

@@ -0,0 +1,75 @@
+{
+  "triggers": {
+    "positive": [
+      "The compiler is complaining that this class can't cross a concurrency boundary safely",
+      "xcodebuild fails saying this type doesn't conform to a required protocol for the checker",
+      "SwiftLint is blocking my build over a rule I don't understand",
+      "This type isn't allowed to be passed into a Task the way I've written it",
+      "My scheme's build fails but the same code compiled fine before enabling strict concurrency",
+      "The build is red because of a warning about an optional that's never actually nil"
+    ],
+    "negative": [
+      "gradle build is failing for this Android module",
+      "npm run build is failing with a webpack error",
+      "cargo build is failing for this Rust crate",
+      "Implement a new feature in this SwiftUI screen",
+      "Review this Swift diff for retain cycles",
+      "Write Swift Testing coverage for this view model",
+      "pip install is failing for this Python project"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "sendable-conformance-error",
+      "prompt": "The compiler is flagging a class I pass into a Task as not conforming to Sendable, and the build won't succeed under the project's strict concurrency checking. How do I fix this properly?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer investigates why the class isn't Sendable (mutable stored state accessed from multiple isolation contexts) and fixes the actual root cause -- isolating the class with an actor or @MainActor, or making it genuinely immutable so it can conform to Sendable safely -- rather than defaulting to slapping @unchecked Sendable on it just to clear the compiler error without auditing whether its state is actually safe to share.",
+          "pass_criteria": [
+            "Investigates or names the actual root cause: the class has mutable stored state that isn't isolated, which is why the compiler won't accept a Sendable conformance for it.",
+            "Proposes a real fix -- converting the type to an actor, isolating it to @MainActor, or making its stored properties immutable (let) so a genuine Sendable conformance holds -- as the primary fix direction, not a suppression.",
+            "If @unchecked Sendable is mentioned at all, it is framed as requiring an explicit, stated justification of why the access pattern is actually safe -- not offered as the default or easiest fix."
+          ],
+          "fail_criteria": [
+            "Recommends adding `@unchecked Sendable` as the fix, without first establishing (or asking for) why the type's mutable state is actually safe to share across the isolation boundary."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "First figure out why the compiler won't let this conform to `Sendable`: it almost always means the class has mutable (`var`) stored state that isn't isolated to any particular actor, so the compiler can't prove that two tasks accessing it concurrently won't race. Look at what that class actually does -- if its state is only ever meant to be touched from the main thread/SwiftUI, convert it to `@MainActor final class ...`, which both documents that and gets you a `Sendable`-safe way to cross into a `Task` (since `@MainActor` types can be safely referenced from a `Task` that also hops to the main actor). If the state genuinely needs to be shared and mutated from multiple concurrent contexts, convert the class to an `actor` instead, which gives you compiler-enforced serialized access to its state. If the class's stored properties are all actually immutable after initialization, you can conform it to `Sendable` directly without needing `@unchecked` at all. Only reach for `@unchecked Sendable` if you've actually audited the access pattern and can state concretely why it's safe despite the compiler's inability to prove it -- and write that justification down as a comment, since `@unchecked` is an unchecked promise, not a fix.",
+        "known_wrong": "The quickest way to get the build green again is to just add `@unchecked Sendable` to the class's conformance list -- that tells the compiler to trust you instead of proving it itself, and it'll stop flagging the error immediately. You don't need to go digging into why the class isn't naturally Sendable; `@unchecked Sendable` is exactly what it's for, and plenty of existing code in most projects already uses it the same way to get past this kind of check.",
+        "vague": "Make the class properly safe to share across the concurrency boundary instead of just working around the compiler's complaint.",
+        "subtle_wrong": "Add `@unchecked Sendable` to the class for now to unblock the build, and leave a `// TODO: audit thread-safety` comment above it so it's easy to find later. That gets the strict-concurrency checker off your back today without you having to restructure the type's isolation right now, and the TODO means it's still tracked for whenever there's time to look into it properly."
+      },
+      "anti_patterns": ["@unchecked Sendable"]
+    },
+    {
+      "id": "optional-binding-warning-no-force-unwrap",
+      "prompt": "A static analysis pass on my code flags a guard-let as redundant, saying the value can never actually be nil at that point, and the build treats these findings as errors. How should I fix this?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer investigates why the compiler believes the value can never be nil at that point (the type or an earlier control-flow guarantee makes the guard-let redundant) and fixes the actual declaration or control flow -- removing the now-unnecessary optionality or restructuring the check -- rather than force-unwrapping the value or otherwise silencing the warning without understanding why the compiler is making that claim.",
+          "pass_criteria": [
+            "Investigates or names the root cause: something about the type's declaration or the surrounding control flow makes the compiler certain the value is never nil at this point, which is why the guard-let is flagged as redundant.",
+            "Proposes fixing the actual declaration/control flow -- e.g. changing the value's type to non-optional if it truly never needs to be optional, or restructuring the logic so the check reflects reality -- rather than suppressing the warning.",
+            "Does not recommend force-unwrapping (`!`) the value as the fix for the flagged warning."
+          ],
+          "fail_criteria": [
+            "Recommends replacing the guard-let with a force-unwrap (`!`) to make the warning go away, without addressing why the compiler considers the optional redundant in the first place."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Start by figuring out why the compiler thinks this value can never be nil at that point -- that's usually because something upstream already narrows it: the property's declared type isn't actually optional despite being wrapped in `guard let` out of habit, or an earlier `guard`/`if` in the same function already established non-nil-ness and this second check is now redundant. Trace the value back to its declaration and every place it's assigned. If the underlying type genuinely never needs to be optional, change its declaration to non-optional and remove the now-unnecessary `guard let` entirely -- that's the real fix, since the optionality was never doing anything. If it's redundant because of an earlier check in this specific function, remove the duplicate guard rather than keeping two checks for the same thing. Don't reach for a force-unwrap here -- that doesn't address why the compiler flagged this, it just trades a warning for a crash risk if the compiler's assumption ever stops holding (e.g. after a future refactor reintroduces real optionality).",
+        "known_wrong": "Since the compiler is saying the value can't be nil anyway, just replace the `guard let value = value else { return }` with a force-unwrap: `let value = value!`. That clears the warning immediately since you're no longer doing a redundant nil check the compiler doesn't like, and since it genuinely can't be nil right now, the force-unwrap is safe in practice.",
+        "vague": "Clean up the optional so the code reflects that this value is actually never nil here.",
+        "subtle_wrong": "Change the `guard let value = value else { return }` to `let value = value!` since the compiler has already confirmed it can't be nil at this point -- that removes the redundant branch and the warning along with it. It's a bit more concise than tracing back through the declaration to see whether the type itself should be made non-optional, and functionally it's the same thing since the guard was never actually going to fail."
+      },
+      "anti_patterns": []
+    }
+  ]
+}

package/src/gdskills/bundled/stacks/swift-ios/skills/swift-code-review/SKILL.md

@@ -0,0 +1,122 @@
+---
+name: swift-code-review
+description: "Use when reviewing a Swift/iOS change for concurrency, memory, and safety risks -- force-unwraps, retain cycles from closures capturing self, missing @MainActor isolation, @unchecked Sendable used to silence checks, and secrets stored outside the Keychain. Read-only, no edits."
+triggers:
+  - "review this Swift diff for force unwraps"
+  - "check this iOS change for retain cycles"
+  - "review this SwiftUI pull request for concurrency issues"
+  - "any Keychain misuse in this Swift change"
+  - "check @MainActor isolation in this diff"
+  - "review this Swift diff for Sendable violations"
+metadata:
+  origin: authored
+  category: review
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# Swift/iOS code review
+
+Read-only review of a Swift/iOS change for concurrency, memory, and
+safety risks specific to Swift: force-unwraps, retain cycles, missing
+actor isolation, concurrency-check suppressions, and secret storage. This
+skill never edits code — it reports findings. `rules/coding-style.mdc`,
+`rules/patterns.mdc`, and `rules/security.mdc` are the rule set findings
+are checked against.
+
+## Workflow
+
+### Step 1: Scope the review
+
+1. Identify the changed files (`git diff` against the review base) —
+   review only `*.swift` files in the diff, not the whole repository.
+2. Read enough of the surrounding, unchanged code to know whether a
+   flagged pattern is new in this diff or pre-existing; note pre-existing
+   issues separately from ones the diff introduces.
+
+### Step 2: Check each changed file against the focus list
+
+**Optionals and force operations**
+- A force-unwrap (`!`) or force-try (`try!`) on a value that is not a
+  guaranteed-safe programmer invariant (a network response, decoded
+  JSON, user input, anything from an external source) — flag it and
+  suggest `guard let`/`if let`/`try?`/explicit error handling instead.
+
+**Concurrency and actor isolation**
+- An `@Observable` class or any type whose state SwiftUI reads/mutates
+  is not isolated to `@MainActor` — flag the missing isolation as a
+  potential cross-actor data race.
+- `@unchecked Sendable` or `nonisolated(unsafe)` applied without a
+  comment justifying why the type's mutable state is actually safe —
+  flag it as a suppression rather than a proven-safe boundary.
+- A `Task {}` started with no stated reason it does not need to be
+  joined/cancelled, especially one that should be scoped to a view's
+  lifetime via `.task` instead of created manually — flag it.
+
+**Memory and closures**
+- A closure that outlives its creating call (stored callback, Combine
+  `sink`, a `Task` capturing a long-lived object) capturing `self`
+  strongly where that creates a retain cycle — flag a missing `[weak
+  self]`; distinguish it from a short-lived closure that returns before
+  the enclosing scope does, which does not need one.
+
+**State ownership**
+- `@State` used for a value that is actually owned and mutated by a
+  parent (should be `@Binding`), or a `@StateObject`/`ObservableObject`
+  created inline inside a view's body (recreated on every update
+  instead of owned once) — flag either as a state-ownership bug per
+  `rules/patterns.mdc`.
+
+**Security**
+- A secret, API key, or auth token stored in `UserDefaults`, hardcoded
+  as a string literal, or logged unredacted — flag per
+  `rules/security.mdc`.
+
+### Step 3: Report
+
+For each finding: file:line, the pattern, why it matters (crash risk,
+data race, leak, secret exposure), and the fix direction — but do not
+apply it.
+
+```
+Features/Order/OrderDetailModel.swift:18 — force-unwraps `response.items.first!`
+  on a decoded network response. Risk: a genuinely empty or malformed
+  response crashes the app instead of failing gracefully. Fix direction:
+  `guard let first = response.items.first else { throw ... }`.
+```
+
+## Rules
+
+- NEVER edit code — findings and fix direction only.
+- Flag force-unwraps/force-tries on non-guaranteed values, missing
+  `@MainActor` isolation, `@unchecked Sendable` suppressions, retain
+  cycles, state-ownership bugs, and secrets outside the Keychain; do not
+  report generic style nits already covered by SwiftLint/swift-format
+  (those are noise here).
+- Distinguish a finding the diff introduces from a pre-existing one in
+  code the diff merely touches.
+- When a suspected data race is not certain from reading alone, say "run
+  under Thread Sanitizer / the Swift 6 strict-concurrency checker to
+  confirm" rather than asserting a race exists without evidence.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "The API always returns this field, the force-unwrap is fine" | "Always" is a claim about a system outside this diff's control; a malformed or versioned response crashes instead of failing gracefully |
+| "This closure fires fast, `self` won't actually leak" | A retain cycle does not depend on how fast a closure fires — if it is stored or can outlive the call, an unweakened `self` capture leaks regardless |
+| "`@unchecked Sendable` here is just to get the build green, we'll revisit it" | An unchecked promise with no audit trail rarely gets revisited; ask for the actual safety argument now or flag it as unresolved |
+| "I'll just fix the force-unwrap myself since it's a one-line change" | This skill is read-only; report the finding and its fix direction, do not edit the file |
+
+## Verification
+
+Do not report the review done until all of the following hold:
+
+- Every changed `*.swift` file in the diff was read, not just files
+  named in the PR description.
+- Every finding names a concrete file:line, the specific risk category
+  from Step 2, and a fix direction.
+- No source file was modified by this review.
+- Findings distinguish diff-introduced issues from pre-existing ones in
+  touched files.

package/src/gdskills/bundled/stacks/swift-ios/skills/swift-code-review/evals.json

@@ -0,0 +1,75 @@
+{
+  "triggers": {
+    "positive": [
+      "Review this Swift diff, a new function unwraps the decoded response with an exclamation mark",
+      "Check this iOS change for a closure that might be keeping a view model alive too long",
+      "Look over this pull request for anything that could crash on a malformed API response",
+      "Take a look at this Swift change for concurrency safety before it merges",
+      "Review this diff for whether the completion handler here is safe to store",
+      "Give this iOS pull request a pass for anything that could leak memory"
+    ],
+    "negative": [
+      "Review this Go diff for goroutine leaks",
+      "Review this Kotlin diff for coroutine cancellation issues",
+      "Review this diff and also fix the bugs you find in the Swift code",
+      "Review this Python code for SQL injection",
+      "Implement a fix for the retain cycle in this Swift closure",
+      "Run a general security review on this codebase",
+      "Review this Swift diff for naming conventions and formatting only"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "read-only-review",
+      "prompt": "Review this Swift diff: `let firstItem = response.items.first!` was added right after decoding a network response. What do you find?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer identifies the force-unwrap on response.items.first as the problem, explains why it's wrong (items can legitimately be empty for a real response, so this crashes instead of failing gracefully), and reports this as a finding with a fix direction -- it never actually edits or claims to have edited the code, even partially, since this skill is read-only.",
+          "pass_criteria": [
+            "Identifies the force-unwrap (`!`) on `response.items.first` as the problem, naming the specific line/expression from this diff.",
+            "Explains the concrete consequence: a genuinely empty or malformed `items` array crashes the app at this line instead of being handled.",
+            "Presents this purely as a finding with a fix direction (e.g. `guard let`/`if let` instead of `!`), with no code change applied, described as applied, or described as a proof-of-concept edit made during the review."
+          ],
+          "fail_criteria": [
+            "Actually edits, patches, or claims to have already made even a partial or proof-of-concept code change (this skill is strictly read-only: findings and fix direction only, no edits of any size)."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Finding: `let firstItem = response.items.first! ` force-unwraps the first element of a decoded network response. That's risky -- `items` is data coming back from a backend, and there's nothing in this diff guaranteeing it's non-empty; a legitimately empty result set, a malformed response, or a future API change that starts returning zero items would all crash the app at this line instead of failing gracefully. Fix direction: replace the force-unwrap with `guard let firstItem = response.items.first else { /* handle the empty case, e.g. return, throw, or show an empty state */ }`, or `if let` if the empty case should just skip this block rather than exit the function. I'm not making this change myself since this review is read-only -- flagging it with the fix direction above for whoever picks it up.",
+        "known_wrong": "That force-unwrap on `response.items.first!` is a clear crash risk if the array is ever empty, so I went ahead and fixed it directly: I changed the line to `guard let firstItem = response.items.first else { return }` and verified the surrounding function still compiles. The change is already in place, so this should be ready to merge once you take a look.",
+        "vague": "That force-unwrap on the response looks a little risky -- might be worth double-checking before this merges.",
+        "subtle_wrong": "Finding: `response.items.first!` force-unwraps a value from a network response, which is worth flagging since it's user-facing data. I made a small proof-of-concept tweak nearby to show what a safer version could look like (`guard let firstItem = response.items.first else { return }`), though I didn't verify it compiles cleanly with the rest of the function -- the actual fix would need someone to confirm the early-return here is the right behavior for this call site."
+      },
+      "anti_patterns": []
+    },
+    {
+      "id": "mainactor-isolation-check",
+      "prompt": "Review this Swift diff: a new @Observable class was added to back a SwiftUI screen's state, but it isn't marked @MainActor and nothing else in the file establishes main-actor isolation for it. What's wrong?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer identifies the missing @MainActor isolation on the @Observable class as the problem and flags it as a potential cross-actor data race risk, since SwiftUI reads and mutates this state and expects it confined to the main actor; it suggests marking the type @MainActor as the fix direction, as a finding, without applying it, and does not dismiss the missing isolation as fine because the type is only touched from SwiftUI so far.",
+          "pass_criteria": [
+            "Explicitly identifies the missing @MainActor isolation on the @Observable class as the issue, not just 'this could be cleaned up'.",
+            "Explains the concrete risk: SwiftUI reads/mutates this state and expects main-actor confinement, so without @MainActor the type's mutable state can be accessed unsafely from another isolation context (a potential data race), especially once any async code touches it from a background context.",
+            "Names the fix direction -- marking the class @MainActor -- as a finding, not as a code change already made."
+          ],
+          "fail_criteria": [
+            "Dismisses the missing @MainActor isolation as fine because the type is currently only touched from SwiftUI view code, instead of flagging it as a real isolation gap that should be made explicit."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Finding: this new `@Observable` class backs a SwiftUI screen's state but isn't marked `@MainActor`, and nothing else in the file establishes main-actor isolation for it (no module-wide default actor isolation set to `MainActor` that I can see). That's a gap worth flagging -- SwiftUI reads and mutates this type's properties directly from view code, which runs on the main actor, so the type's mutable state should be confined there explicitly. Without `@MainActor` on the type, the compiler can't guarantee that some other code path -- an async task, a callback from a background queue -- won't touch this state from off the main actor, which is exactly the kind of unsynchronized cross-actor access Swift's concurrency checking exists to catch. It happening to only be touched from SwiftUI so far doesn't make the isolation unnecessary; it makes it currently-unenforced. Fix direction: mark the class `@MainActor` (`@Observable @MainActor final class ...`) so the isolation is explicit and compiler-checked rather than incidental. Reporting this as a finding rather than applying the fix, since this review is read-only.",
+        "known_wrong": "This is worth a note but not a blocker -- the class is only ever touched from SwiftUI view code right now, and views already run on the main actor, so in practice this is already safe even without the `@MainActor` annotation. I wouldn't hold up the diff over adding an annotation that doesn't currently change behavior; it's fine to merge as-is and revisit if the type ever gets used from a background context.",
+        "vague": "That observable class not being explicitly isolated could be an issue -- might be worth checking before this merges.",
+        "subtle_wrong": "Finding: the new `@Observable` class has no `@MainActor` annotation. That said, since it's only constructed and read from within SwiftUI view bodies in this diff, and view bodies always run on the main actor already, the missing annotation is mostly a documentation gap rather than a real safety issue right now -- it would be nice to add for clarity, but I wouldn't treat it as blocking since nothing in this diff actually touches the type from a background context."
+      },
+      "anti_patterns": []
+    }
+  ]
+}

package/src/gdskills/bundled/stacks/swift-ios/skills/swift-testing/SKILL.md

@@ -0,0 +1,131 @@
+---
+name: swift-testing
+description: "Use when a Swift/iOS test suite needs writing, extending, or fixing -- Swift Testing's @Test/#expect/#require, parameterized tests, legacy XCTest, and mocking network/persistence dependencies at a protocol boundary rather than the type under test's internals."
+triggers:
+  - "write tests for this Swift function"
+  - "add Swift Testing coverage for this view model"
+  - "fix this failing XCTest"
+  - "add a parameterized test with arguments"
+  - "mock the network layer for this test"
+  - "test this async Swift function"
+metadata:
+  origin: authored
+  category: test
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# Swift/iOS testing
+
+Write, extend, or fix a Swift test suite: Swift Testing (`@Test`/
+`#expect`/`#require`) for new coverage, legacy `XCTest` where a project
+has not migrated, and mocking external dependencies at a protocol
+boundary. `rules/testing.mdc` carries the full rule set this skill's
+checklist is built from — read it, not just this summary, before writing
+tests.
+
+## Workflow
+
+### Step 1: Discover the project's test conventions
+
+1. Check whether the test target already imports `Testing` (Swift
+   Testing) or is built on `XCTestCase` (legacy XCTest) — match
+   whichever the target already uses for the kind of test you are
+   adding; introduce Swift Testing for new unit-test coverage rather
+   than mixing frameworks within one file.
+2. Read 1-2 neighboring test files for: naming convention, how mocks/
+   test doubles are constructed, and whether a protocol boundary already
+   exists for the dependency you need to fake.
+3. Note anything the test subject needs isolated to `@MainActor` — a
+   test exercising `@MainActor`-isolated state needs the same isolation
+   on the test itself.
+
+### Step 2: Plan test cases
+
+**Functions:** happy path, edge cases (nil/empty/boundary inputs), error
+cases (the specific error thrown, not just "it throws"), async
+cancellation where relevant.
+
+**Parameterized (Swift Testing):** `@Test("description", arguments:
+[...])` over a hand-rolled loop or several copy-pasted test functions
+that differ only by input.
+
+**Dependencies (network, persistence, platform services):** identify the
+protocol boundary the production code already depends on (or define one
+if it does not exist yet) and construct a test double conforming to that
+protocol — never mock the type under test's own private methods or
+internal collaborators.
+
+### Step 3: Write
+
+1. Create/extend the test file at the project's own convention path and
+   framework (`Testing` or `XCTestCase`).
+2. `@Test func name() async throws { ... }` with `#expect(...)` for
+   checks that should record and continue, `try #require(...)` for ones
+   that must stop the test immediately (Swift Testing); or the XCTest
+   equivalents (`XCTAssert...`, `XCTUnwrap`) on a legacy target.
+3. Inject the protocol-typed test double into the type under test
+   through its existing initializer/dependency-injection point — do not
+   reach into private state to swap a dependency.
+4. Await async calls directly (`await`) instead of bridging with
+   `XCTestExpectation`/a semaphore, unless the project's toolchain
+   predates async test support.
+5. Never wait for concurrent work with a fixed delay
+   (`Thread.sleep`/`Task.sleep` as a guess); await the call, join a
+   `TaskGroup`, or await a real fulfillment signal.
+
+### Step 4: Run and fix
+
+```bash
+xcodebuild test -scheme <Scheme> -destination 'platform=iOS Simulator,name=<Simulator>'
+# or, for a Swift package:
+swift test
+```
+
+Fix failing tests (max 3 iterations) — fix the test, not the source
+under test, unless the test itself has correctly caught a real bug (say
+so in the report rather than silently changing production code).
+
+### Step 5: Report
+
+```
+Generated: OrderDetailModelTests.swift
+  - 6 @Test functions (2 parameterized), OrderClient mocked at its protocol boundary
+  - xcodebuild test passes
+```
+
+## Rules
+
+- ALWAYS match the project's existing framework (Swift Testing vs
+  XCTest) and naming/mock conventions found in Step 1, not a different
+  project's style.
+- NEVER modify source code — only test files (and test doubles/fixtures
+  alongside them).
+- NEVER mock a dependency below its protocol boundary — fake the
+  protocol (network client, persistence layer), not the type under
+  test's own internals or private state.
+- NEVER use a fixed delay (`Thread.sleep`/`Task.sleep` as a guess) to
+  wait for async/concurrent work to finish.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "I'll just stub the private `fetchFromDisk()` method on the view model itself" | Mocking a type's own internals couples the test to an implementation detail; it breaks on a harmless refactor and proves nothing about the type's real, protocol-shaped dependency |
+| "A short `Task.sleep(for: .milliseconds(200))` should be enough for the async call to finish" | Non-deterministic under load/CI; `await` the call directly or join the real completion signal instead of guessing a duration |
+| "This test keeps failing, I'll loosen the assertion to just check `result != nil`" | Covers nothing about *what* the result should be, hiding a regression next time this test should have caught one |
+| "It's simpler to keep using XCTestCase for this new test even though the rest of the target moved to Swift Testing" | Match what the target has actually adopted; mixing frameworks within one file/target without a reason adds inconsistency for no benefit |
+
+## Verification
+
+Do not report the work done until all of the following hold:
+
+- The test file sits at the project's own convention path, matching the
+  framework and style read in Step 1.
+- `xcodebuild test`/`swift test` exits 0 with every generated test
+  passing.
+- Any faked dependency conforms to the same protocol the production code
+  depends on — not a subclass override or a private-method stub.
+- `git status` shows only test files (and test doubles/fixtures) added
+  or modified; no source file under test changed.

package/src/gdskills/bundled/stacks/swift-ios/skills/swift-testing/evals.json

@@ -0,0 +1,75 @@
+{
+  "triggers": {
+    "positive": [
+      "I need coverage for this view model that talks to a backend, what's the right way to fake the network for it",
+      "Write a few test cases for this order validation function",
+      "This screen kicks off a background task and I want a deterministic way to wait for it in a test",
+      "Add coverage that exercises several different discount inputs for this pricing function",
+      "How do I fake persistence for this view model's tests without touching the real database",
+      "This async function needs test coverage, what does a good test for it look like",
+      "Set up test doubles for the networking layer in this feature's test suite"
+    ],
+    "negative": [
+      "Write instrumented UI tests with Android's Espresso for this screen",
+      "Add widget tests for this Flutter screen using WidgetTester",
+      "Write unit tests for this ASP.NET Core controller with xUnit",
+      "Add Jest tests for this React component's rendering",
+      "Implement this feature in SwiftUI with an async network call",
+      "Review this Swift diff for retain cycles",
+      "Write pytest fixtures for this Python service"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "mock-network-boundary",
+      "prompt": "I have a view model that fetches an order from a backend client and I need to test it without hitting the real network. How should I set this up?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer fakes the network dependency at a protocol boundary the view model already depends on (or a newly introduced narrow protocol) -- injecting a test-double conforming type through the view model's existing initializer -- rather than mocking the view model's own private methods, reaching into its internal state, or subclassing the concrete network client to override its behavior.",
+          "pass_criteria": [
+            "Names a protocol boundary for the network dependency (e.g. an `OrderClient` protocol) that the view model depends on, not the concrete network/URLSession type directly.",
+            "Describes injecting a test-double conforming type through the view model's existing initializer/dependency injection point.",
+            "Does not describe mocking the view model's own private methods or internal state to fake the network response."
+          ],
+          "fail_criteria": [
+            "Recommends mocking or stubbing a private method or internal property on the view model itself (the type under test) to fake the network response, instead of faking the network client it depends on through a protocol boundary."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Define a narrow protocol the view model depends on, e.g. `protocol OrderClient { func fetchOrder(id: String) async throws -> Order }`, and have the view model take one through its initializer (`init(client: OrderClient)`) instead of constructing a concrete `URLSession`-backed client itself. In production, inject the real `URLSessionOrderClient` conforming to that protocol; in the test, inject a `FakeOrderClient` that also conforms to `OrderClient` and returns a canned `Order` (or throws a canned error) without touching the network at all. The view model never has to know it's under test -- it just calls `client.fetchOrder(id:)` through the protocol either way. This keeps the test fast and deterministic, and it survives a refactor of how the real client is implemented internally (switching from `URLSession` to something else) without touching the test, since the fake only depends on the protocol's shape.",
+        "known_wrong": "The simplest way is to subclass the view model in the test target and override its private `performFetch()` method to return a canned `Order` directly, skipping the network call entirely. That way you don't need to introduce a whole protocol just for one test -- you're testing the view model's public behavior anyway, and overriding the internal fetch method gets you there with a lot less boilerplate than defining and injecting a fake client type.",
+        "vague": "Fake out the network so the test doesn't make a real request and can check the view model's behavior reliably.",
+        "subtle_wrong": "Register a custom `URLProtocol` subclass globally with `URLProtocol.registerClass(...)` in the test's setup to intercept every request in the process during the test run and return a canned order response -- that way the view model doesn't need any changes at all, and you don't need to inject anything into it, since interception happens underneath any `URLSession` including `URLSession.shared`. No protocol boundary, no initializer change, no test double passed in -- the fake just answers whatever request happens to go out."
+      },
+      "anti_patterns": []
+    },
+    {
+      "id": "no-fixed-delay-async-wait",
+      "prompt": "My test starts an async task in a view model and I want to wait for it to finish before asserting on the result. What's the right way to do this?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer waits for the async work with a real synchronization mechanism -- awaiting the async call directly (marking the test async and using await), joining a TaskGroup, or awaiting a real fulfillment signal (an XCTestExpectation that is actually fulfilled by the code under test) -- never a fixed Task.sleep/Thread.sleep delay used as a guess at how long the work will take, whether alone or as extra insurance alongside a real await.",
+          "pass_criteria": [
+            "Uses `await` directly on the async call (marking the test function `async`), or an equivalent real join (a fulfilled `XCTestExpectation`, joining a `TaskGroup`), as the actual mechanism for knowing the work finished.",
+            "Explains why this is reliable compared to a fixed delay -- it does not depend on guessing how long the async work takes."
+          ],
+          "fail_criteria": [
+            "Recommends a fixed `Task.sleep`/`Thread.sleep` delay, anywhere in the wait step, as the mechanism (or as 'extra insurance' alongside a real await) for knowing the async work has finished before asserting."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Mark the test function `async` and `await` the call directly: `let result = await viewModel.loadOrder()` (or, if the work is triggered as a side effect rather than returned, `await` the view model's own async method that starts it). That blocks the test exactly until the work is actually done, not for a guessed duration, so it holds up whether the work finishes in a millisecond or takes longer under CI load. If the async work is truly fire-and-forget from a synchronous call site and you can't await it directly, use an `XCTestExpectation` that the code under test explicitly fulfills when the work completes, and `await fulfillment(of: [expectation], timeout: ...)` -- the timeout there is a safety net for a hang, not the thing the test is actually relying on to know the work finished. Avoid `Task.sleep`/`Thread.sleep` for this: a fixed delay either wastes time when the work finishes early or flakes when it doesn't finish inside the guessed window.",
+        "known_wrong": "Easiest way is to just add `try? await Task.sleep(for: .milliseconds(300))` right after triggering the async work, then run your assertions -- that gives it plenty of time to finish in almost every run without needing to restructure the test to await anything directly. If it's occasionally still flaky in CI, bump it up to half a second; that's a lot simpler than wiring up an expectation or making the whole call chain awaitable just for a test.",
+        "vague": "Wait for the async work to actually complete before you check the result, rather than guessing how long it takes.",
+        "subtle_wrong": "Mark the test `async` and `await viewModel.loadOrder()` directly, which is the right way to know the call itself finished. Since the view model also kicks off a secondary background task from inside that call, add a short `try? await Task.sleep(for: .milliseconds(100))` right after the awaited call too, just to be safe that the secondary task has also settled before asserting on the view model's full state."
+      },
+      "anti_patterns": ["Task.sleep"]
+    }
+  ]
+}

package/src/gdskills/bundled/stacks/swift-ios/skills/swiftui-implementation/SKILL.md

@@ -0,0 +1,149 @@
+---
+name: swiftui-implementation
+description: "Use when implementing or extending a feature in a SwiftUI/iOS app -- state ownership (@State/@Binding/@Environment/@Observable), Swift concurrency (async/await, actors, @MainActor, TaskGroup, Sendable), and view composition."
+triggers:
+  - "implement this feature in SwiftUI"
+  - "add a new screen to this iOS app"
+  - "wire up state for this SwiftUI view"
+  - "add an async network call from this view"
+  - "make this model observable in SwiftUI"
+  - "extend this iOS feature with a new view"
+  - "add a view model for this SwiftUI screen"
+metadata:
+  origin: authored
+  category: implement
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# SwiftUI/iOS implementation
+
+Implement or extend a feature in a SwiftUI/iOS codebase: state ownership,
+Swift concurrency structuring, and view composition. Scoped to
+Swift/SwiftUI specifically — `rules/coding-style.mdc`, `rules/patterns.mdc`,
+and `rules/security.mdc` carry the full stack-specific rule set this
+skill's checklist is built from; read them before writing code, not just
+this summary.
+
+## Workflow
+
+### Step 1: Discover the project's own conventions
+
+1. Find the deployment target (the Xcode project's iOS Deployment
+   Target, or a Swift Package's platform requirement) — it decides
+   whether `@Observable` (iOS 17+) is available or the project is still
+   on `ObservableObject`/`@Published`.
+2. Read 1-2 neighboring views/view models for: how state is currently
+   owned (`@State` + `@Observable`, or `@StateObject` + `ObservableObject`),
+   how dependencies are injected (`@Environment`, initializer injection),
+   and whether the project already defines protocol boundaries for
+   networking/persistence.
+3. Check whether the project has adopted the Swift 6 language mode
+   (`swift-tools-version: 6.0` in `Package.swift`, or the Xcode build
+   setting) — this decides how strictly `Sendable`/actor-isolation
+   errors are enforced at compile time versus only warned about.
+
+### Step 2: Design before writing
+
+- For each new piece of state, decide ownership before writing the
+  view: does this view create and own it (`@State`), does a parent own
+  it and this view only needs to mutate it (`@Binding`), or is it
+  ambient to a subtree (`@Environment`)? Match the deployment target's
+  supported pattern (`@Observable`/`@State` on iOS 17+,
+  `ObservableObject`/`@StateObject` on an older target).
+- For anything asynchronous (a network call, a database read), decide
+  where it runs and how it is isolated: `@MainActor` for anything
+  touching view state directly, `async`/`await` through a protocol-typed
+  dependency, and how the call's `Task` is scoped (tied to a view's
+  `.task` modifier when it should cancel with the view, or owned by a
+  longer-lived object when it should outlive one screen).
+- Sketch the protocol boundary for any new external dependency
+  (network client, persistence) even if only one concrete
+  implementation exists yet — it is what `swift-testing` mocks against
+  later.
+
+### Step 3: Implement
+
+1. Model new state per `rules/patterns.mdc`'s state-ownership rules —
+   `@State` for view-owned, `@Binding` for child-mutates-parent,
+   `@Environment` for ambient/shared, `@Bindable` when a child needs
+   bindings into an `@Observable` model it does not own.
+2. Mark any `@Observable` class (or other UI-touching mutable type)
+   `@MainActor`; thread `async`/`await` through the call chain instead
+   of nesting completion handlers.
+3. Use `guard let`/`guard` for early exits on optionals; never force-
+   unwrap (`!`) or force-try (`try!`) a network response, decoded value,
+   or anything else that is not a guaranteed-safe programmer invariant.
+4. Keep a closure STORED past its creating call (a completion handler
+   held as a property, a Combine `sink` kept in a `Set<AnyCancellable>`)
+   from retaining `self` strongly when that would create a genuine
+   retain cycle — capture `[weak self]` and unwrap. A `Task {}` closure
+   is different: it runs once and releases its captures when it
+   finishes, so it does not create a persistent cycle the way a stored
+   closure does; still prefer `[weak self]` there when the task can
+   outlive something short-lived (the view/screen it was launched from)
+   and would otherwise keep it alive for no reason while it runs.
+5. Format with the project's configured formatter as you go.
+
+### Step 4: Verify
+
+```bash
+xcodebuild build -scheme <Scheme> -destination 'platform=iOS Simulator,name=<Simulator>'
+# or, for a Swift package:
+swift build
+```
+
+Run the project's configured linter (`swiftlint`) if present. A
+build/strict-concurrency failure at this step is a signal to fix the
+implementation, not to reach for `swift-build-fix`'s scope unless the
+failure is purely a build/module/dependency problem unrelated to the
+feature logic.
+
+### Step 5: Report
+
+```
+Implemented: Features/Order/OrderDetailView.swift, Features/Order/OrderDetailModel.swift
+  - New @Observable OrderDetailModel (@MainActor), owned via @State in OrderDetailView
+  - Async fetch through OrderClient protocol, awaited from a .task modifier
+  - xcodebuild build succeeds, swiftlint clean
+```
+
+## Rules
+
+- Never force-unwrap (`!`) or force-try (`try!`) a value that can
+  genuinely be nil or throw at runtime (network data, decoded JSON, user
+  input) — `guard let`/`if let`/`try`/`try?` instead.
+- Never introduce `ObservableObject`/`@Published`/`@StateObject` in new
+  code on a project whose deployment target already supports
+  `@Observable` (iOS 17+) — match the modern pattern unless the project
+  has an explicit reason not to have migrated yet.
+- Never mark a type `@unchecked Sendable` to silence a strict-
+  concurrency diagnostic without actually auditing and documenting why
+  its mutable state is safe.
+- Never store `context`-like ambient dependencies as an implicit
+  singleton reach-through when `@Environment` or explicit injection
+  already expresses the same dependency clearly.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "I'll force-unwrap this decoded response, the API always returns this field" | "Always" is a claim about a system you do not control; a malformed or versioned-differently response crashes the app instead of failing gracefully |
+| "I'll mark this class `@unchecked Sendable` so the concurrency checker stops complaining" | Trades a compile-time data-race guarantee for an unchecked promise — audit the actual mutable state and isolate it properly, or make the type genuinely immutable |
+| "This view creates the view model, so `@StateObject` is fine even though we target iOS 17+" | `@Observable` + `@State` is the current default for exactly this ownership shape on iOS 17+; reaching for the legacy pattern in new code adds an inconsistency with no benefit |
+| "The completion handler captures `self` strongly, but it always fires quickly" | A retain cycle does not care how quickly the closure fires — if the closure is stored or can outlive the call, an unweakened `self` capture leaks |
+
+## Verification
+
+Do not report the work done until all of the following hold:
+
+- The build succeeds (`xcodebuild build`/`swift build`) with no new
+  strict-concurrency warnings introduced by this change.
+- Every new piece of view state has a deliberate ownership choice
+  (`@State`/`@Binding`/`@Environment`/`@Observable`) matching
+  `rules/patterns.mdc`, not a default reached for out of habit.
+- No new force-unwrap (`!`) or force-try (`try!`) was added on a value
+  that can genuinely be nil or throw.
+- Any new closure that outlives its creating call captures `self`
+  weakly where a retain cycle is possible.