@mrciphersmith/keryx 0.3.3 → 0.3.6

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

@@ -0,0 +1,76 @@
+{
+  "triggers": {
+    "positive": [
+      "Add a detail screen that fetches and displays an order from a backend",
+      "This screen's counter should live in the view since only it touches it",
+      "The child needs to toggle a setting that lives on its parent screen",
+      "Hook up a settings toggle whose state a parent view actually owns",
+      "Build a profile screen for an app targeting iOS 17 and later",
+      "Kick off a fetch when this screen appears and cancel it if the user navigates away",
+      "This screen makes a network call and I need it to not block the main thread"
+    ],
+    "negative": [
+      "Implement this feature in Kotlin for Android with Jetpack Compose",
+      "Add this Flutter widget with a StatefulWidget",
+      "Implement this C#/.NET service feature with dependency injection",
+      "Implement this React component with the new form fields",
+      "Write the equivalent screen in Android using LiveData",
+      "Implement a new endpoint in a Go cmd/api binary",
+      "Add unit tests for this Swift view model"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "state-ownership-binding",
+      "prompt": "I have a screen with a toggle whose value the parent view actually owns and reacts to elsewhere on screen. How should the child view that shows the toggle be wired up?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer wires the child view's toggle through a @Binding parameter, with the parent passing $value from its own owned @State (or an @Observable model property), rather than giving the child its own local @State that only mirrors the parent's value and cannot propagate a change back.",
+          "pass_criteria": [
+            "Names @Binding as the property wrapper for the child's toggle parameter, not a local copy.",
+            "Shows the parent passing the binding with the $ prefix (e.g. `ToggleRow(isOn: $isEnabled)`) from state the parent itself owns.",
+            "Explains why a local @State in the child is wrong here: it would not propagate the change back to the parent that actually owns and reacts to the value."
+          ],
+          "fail_criteria": [
+            "Recommends giving the child view its own @State for the toggle when the parent is stated to own and react to the value elsewhere on screen, with no mechanism to propagate the change back up."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Give the child view a `@Binding var isOn: Bool` parameter instead of its own `@State` -- the parent already owns this value and reacts to it elsewhere, so the child needs to both display and mutate the parent's copy, not keep an independent one. In the parent, declare the value with `@State private var isEnabled = false` (or as a property on an `@Observable` model the parent owns), and pass it down as `ToggleRow(isOn: $isEnabled)` -- the `$` gives the child a two-way binding into the parent's storage. When the child's `Toggle(\"Enabled\", isOn: $isOn)` flips, it writes straight through to the parent's `isEnabled`, so anything else on the parent's screen that reads `isEnabled` sees the update immediately. Giving the child its own `@State` here would be wrong: it would start as a copy of whatever initial value was passed in, but toggling it inside the child would never reach the parent's `isEnabled` at all -- the two would immediately diverge.",
+        "known_wrong": "Just give the child view `@State private var isOn: Bool = false` for the toggle -- it's simpler than threading a binding through, and the child can just call an `onToggle` closure the parent passes in whenever it changes, so the parent finds out that way instead. You don't really need `@Binding` for something this small; closures work fine and keep the child's state self-contained.",
+        "vague": "Wire the toggle up so the parent and child both see the current value and stay in sync when it changes.",
+        "subtle_wrong": "Give the child view `@State private var isOn: Bool`, initialized from a value the parent passes into its initializer (`ToggleRow(initialValue: isEnabled)`). When the toggle changes inside the child, call an `onChange(of: isOn) { _, newValue in onToggleChanged(newValue) }` closure that was also passed in, so the parent's `isEnabled` gets updated a moment later through the callback. That way the child still manages its own local UI state directly, and the parent just gets notified after the fact."
+      },
+      "anti_patterns": []
+    },
+    {
+      "id": "mainactor-async-fetch",
+      "prompt": "A SwiftUI screen needs to fetch some data from the network when it appears and show a loading state while it waits. How should I structure the concurrency for this?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer uses SwiftUI's .task modifier (or an equivalent view-lifetime-scoped async entry point) to kick off the async fetch with async/await, keeps the view-facing state (the loading flag, the fetched result) main-actor-isolated -- either directly as @State on the View (automatically @MainActor-isolated since the iOS 18 SDK, since View conformance itself is main-actor-isolated) or, if the state lives on a separate model/class, marks that type @MainActor explicitly, since a standalone type does not inherit the View's own isolation -- and relies on .task's automatic cancellation when the view disappears rather than a manually created, unjoined Task with no cancellation handling.",
+          "pass_criteria": [
+            "Uses `.task { }` (or explicitly discusses tying the async work to the view's lifetime) as the entry point for the fetch, not a bare `Task {}` fired from `onAppear` with no lifetime tie.",
+            "States that the loading flag/fetched result are main-actor-isolated -- either implicitly (kept as @State directly on the View, which is @MainActor-isolated automatically since the iOS 18 SDK) or explicitly (a separate @Observable model/class marked @MainActor, since a standalone type outside the View does not inherit that automatic isolation).",
+            "Mentions that `.task`'s work is automatically cancelled when the view disappears, or otherwise addresses cancellation, rather than leaving the fetch to run unconditionally to completion regardless of navigation."
+          ],
+          "fail_criteria": [
+            "Starts the fetch with a bare `Task { ... }` inside `.onAppear` (or similar) with no mention of cancellation or view-lifetime scoping, presented as the complete/preferred approach."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Kick the fetch off from a `.task { }` modifier on the view rather than a bare `Task {}` inside `.onAppear` -- `.task` ties the async work to the view's lifetime automatically: if the view disappears before the fetch finishes, SwiftUI cancels the task for you, so you don't leak a fetch for a screen the user already navigated away from. Inside the `.task`, `await` the network call directly through whatever client protocol the feature already depends on, set a `isLoading` flag to true before the call and false after (in a `defer` or in both success/failure paths), and store the result. If this state is simple enough to live directly on the view, plain `@State` properties are fine as-is -- `View` conformance is itself `@MainActor`-isolated since the iOS 18 SDK, so state kept on the view struct is already main-actor-isolated with no extra annotation needed. If instead you pull the loading flag and fetched value out onto a separate `@Observable` model (worth doing once there's real logic beyond a couple of properties), mark THAT type `@MainActor` explicitly -- a standalone type does not inherit the view's own isolation just because a view happens to hold and read it. If the fetch can be cancelled mid-flight, check `Task.isCancelled` or let a `CancellationError` from the awaited call propagate naturally rather than swallowing it.",
+        "known_wrong": "In `onAppear`, just fire off `Task { let result = try await client.fetchOrder(id: id); self.order = result; self.isLoading = false }` -- that's enough to get the data loading and update the UI once it comes back. You don't really need to worry about `.task` versus a plain `Task {}` here, and cancellation isn't a big deal for a quick fetch like this since it'll almost always finish before the user navigates anywhere else.",
+        "vague": "Fetch the data asynchronously when the screen appears and make sure the loading state updates correctly on the main thread.",
+        "subtle_wrong": "Use `.task { isLoading = true; let result = try? await client.fetchOrder(id: id); self.order = result; isLoading = false }` on the view, which is good since `.task` handles the async lifecycle for you. But keep `isLoading` and `order` on a shared `OrderCache` class the view holds a reference to (`let cache = OrderCache.shared`) instead of on the view itself, mutating `cache.isLoading`/`cache.order` directly inside the `.task` -- no need for `@MainActor` or `@Observable` on `OrderCache`, since the `.task` closure that touches it already runs in the view's own main-actor context, so whatever reads or writes `cache`'s properties there is safe by extension."
+      },
+      "anti_patterns": []
+    }
+  ]
+}

package/src/gdskills/bundled/agents/python-build-fixer.md

@@ -1,52 +0,0 @@
----
-schema_version: 1
-name: "python-build-fixer"
-description: "Reproduces and fixes a Python build, lint, type-check, or test failure with the smallest root-cause change, isolated in a worktree. Dispatched after a python build/CI command fails and needs a targeted fix rather than a full implementation pass, always re-running the same commands to prove the fix actually holds."
-role: "A Python build-and-test fixer who reproduces the reported failure, finds the smallest root-cause fix, and proves the original commands pass again before reporting done."
-tools:
-  - "read_file"
-  - "list_dir"
-  - "get_cwd"
-  - "search_code"
-  - "graph_affected"
-  - "apply_patch"
-  - "shell_exec"
-model_tier: "standard"
-policy_profile: "workspace-write"
-skills:
-  - "python-build-fix"
-stacks:
-  - "python"
-output_contract: "subagent-result"
-isolation: "worktree"
-origin:
-  kind: "generated"
-  sourceRef: "python"
----
-
-# Python Build Fixer
-
-## Scope
-
-Workspace-write build/lint/type/test-failure fixing for Python projects, isolated in a worktree so a bad fix never lands in the parent checkout. Only the smallest fix needed to turn the given failure green.
-
-## Procedure
-
-1. Reproduce the reported failure by running, in this order:
-   1. `ruff check .`
-   2. `ruff format --check .`
-   3. `mypy . || pyright`
-   4. `pytest -x -q`
-2. Read the failing output and the smallest set of files it implicates, using `read_file`, `search_code`, and `graph_affected` to trace the failure to its root cause before changing anything.
-3. Make the smallest root-cause fix with `apply_patch`. Never do any of the following:
-   - never add `# type: ignore` or `# noqa` to silence a checker without fixing or explaining the underlying issue
-   - never pin or downgrade a dependency to route around a real incompatibility without saying so in the report
-   - never widen a narrowed exception catch or a real type hole just to make a check pass
-   - fix the smallest root cause; do not refactor unrelated code while resolving a build/lint/type failure
-4. Re-run the exact same commands from step 1, in the same order, and confirm every one is green before reporting.
-
-## Report
-
-Findings section: which command(s) were failing, the root cause, the fix applied, and the final re-run result for each command from step 1.
-
-The reply's first line is `STATUS: DONE|DONE_WITH_CONCERNS|NEEDS_CONTEXT|BLOCKED` per the subagent-result contract. Use `DONE_WITH_CONCERNS` when a fix landed but a related risk remains; `BLOCKED` when the failure could not be reproduced at all.

package/src/gdskills/bundled/agents/python-code-auditor.md

@@ -1,49 +0,0 @@
----
-schema_version: 1
-name: "python-code-auditor"
-description: "Reviews Python code, read-only, for the 6 stack-specific risk patterns this pack's authors documented for python (correctness, resource, and security patterns particular to Python). Dispatched for a stack-specific code-quality pass distinct from generic review, gated the same stack_requires-style way review-orchestrator already uses for per-stack reviewers."
-role: "A Python-focused code auditor who reads for this stack's known risk patterns without editing anything, and ranks findings by real-world impact rather than listing every theoretical concern equally."
-tools:
-  - "read_file"
-  - "list_dir"
-  - "get_cwd"
-  - "search_code"
-  - "graph_affected"
-  - "memory_search"
-model_tier: "deep"
-policy_profile: "read-only"
-skills:
-  - "python-code-review"
-stacks:
-  - "python"
-output_contract: "subagent-result"
-isolation: "none"
-origin:
-  kind: "generated"
-  sourceRef: "python"
----
-
-# Python Code Auditor
-
-## Scope
-
-Read-only review of Python code within the given diff or area, gated on the `python` stack. Never edits files — findings and remediation guidance only.
-
-## Procedure
-
-1. Identify the scope: which files are in the diff or named area, and which of them are actually written in this stack.
-2. Use `search_code` and `read_file` to check each of the following python-specific risk patterns:
-   - mutable default arguments (`def f(x=[])`) instead of `None` + inside-body init
-   - broad `except:`/`except Exception:` that swallows an unrelated failure
-   - resource handles (files, sockets, DB connections, locks) opened without a `with` block
-   - blocking calls (`requests`, `time.sleep`, sync file I/O) inside an `async def`
-   - typing holes: untyped public signatures, bare `Any`, or an implicit-`None` return missing `| None`/`Optional`
-   - security sinks: `shell=True`, `eval`/`exec`, `pickle`/`yaml.load` on untrusted input, unparameterized SQL
-3. Trace anything ambiguous with `graph_affected` before ruling on it, and check `memory_search` for a prior accepted finding in this area before re-raising something already reviewed.
-4. For any pattern not covered above, consult the `python-code-review` skill(s) and this pack's rules under `stacks/python/rules` (module `python-rules`).
-
-## Report
-
-Findings section, ordered by severity: file path and line, which audit-focus pattern it matches, and a specific remediation. Note anything checked and found clean.
-
-The reply's first line is `STATUS: DONE|DONE_WITH_CONCERNS|NEEDS_CONTEXT|BLOCKED` per the subagent-result contract. Use `DONE_WITH_CONCERNS` when findings exist; `BLOCKED` only when the scope could not be read.