@mrciphersmith/keryx 0.3.3 → 0.3.5

package/src/gdskills/bundled/stacks/kotlin-android/skills/compose-implementation/evals.json

@@ -0,0 +1,77 @@
+{
+  "triggers": {
+    "positive": [
+      "I need to add a save button on this screen that persists a form to the backend",
+      "Add an expandable settings section with a toggle to this app screen",
+      "Hook up loading and error states from the repository call to the UI",
+      "Build a new profile edit screen that reads from and writes to our data layer",
+      "This screen needs a snackbar to show up once after a background save finishes",
+      "Add pagination to this list screen backed by a paging data source",
+      "Wire a search field on this screen to filter a list as the user types"
+    ],
+    "negative": [
+      "Implement this feature with a SwiftUI view backed by @State and @Published",
+      "Add a StatefulWidget in Flutter that manages this form's local state",
+      "Implement this ASP.NET Core minimal API endpoint for saving a record",
+      "Add a new React component with useState and useEffect for this form",
+      "Write a Django view that handles this form submission",
+      "Fix this failing Gradle build after bumping the Compose Compiler version",
+      "Review this Kotlin diff for goroutine-style concurrency leaks before merge"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "state-hoisting-scope",
+      "prompt": "On a settings screen I'm building, there's a card with an arrow icon that expands to reveal a couple of extra options underneath. Nothing else on the screen needs to know whether it's expanded. Where should that expanded/collapsed flag live?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer keeps the expanded/collapsed flag as local composable state, created with `remember { mutableStateOf(false) } ` inside the card composable itself, rather than pushing it up into a ViewModel or a parent screen's own state holder -- since nothing else needs to read or drive it, hoisting it further only adds indirection with no benefit. It should not leave the flag as a bare `var` with no `remember`, since that value would be lost on every recomposition.",
+          "pass_criteria": [
+            "States the flag should be local to the card composable via `remember` (or `rememberSaveable` if the answer wants it to survive rotation), not pushed into the ViewModel.",
+            "Explains that hoisting further (to a parent screen or the ViewModel) is unnecessary here specifically because nothing else needs to read or change the value.",
+            "Shows or names the concrete construct (`remember { mutableStateOf(false) }`), not just 'keep it local'."
+          ],
+          "fail_criteria": [
+            "Recommends putting the expanded/collapsed flag into the ViewModel or a shared/hoisted state holder even though nothing else needs it.",
+            "Describes storing the flag as a bare `var` inside the composable with no `remember` wrapper, which would reset on every recomposition."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Since nothing outside this card needs to read or drive that flag, keep it local: `var expanded by remember { mutableStateOf(false) }` right inside the card's own composable function, and flip it in the arrow icon's `onClick`. There's no reason to hoist it to a parent screen or push it into the ViewModel -- hoisting only earns its keep when a sibling composable or the caller actually needs to observe or control the value, and here nothing does. If you later want the card to stay expanded across a screen rotation, swap `remember` for `rememberSaveable`, but that's a separate decision from where the state lives.",
+        "known_wrong": "Put it in the ViewModel as part of the screen's UiState, something like `isSectionExpanded: Boolean` on the state data class, and toggle it through a `ViewModel` function the composable calls on click. That way everything about the screen's state lives in one place and is easier to find later, even though only this one card actually reads it right now.",
+        "vague": "Keep the state close to where it's used and make sure it's remembered properly across recompositions.",
+        "subtle_wrong": "You can just declare `var expanded = false` at the top of the card's composable function and flip it in the click handler -- that's simpler than wiring up `remember`, and since it's just a UI toggle it doesn't need to go through the ViewModel."
+      }
+    },
+    {
+      "id": "viewmodel-save-coroutine-scope",
+      "prompt": "I'm wiring up a save button in this ViewModel. Clicking it should call a suspend function on the repository to persist some data. How should I launch that call?",
+      "strictness": "high",
+      "expected_behavior": [
+        { "grader": "regex", "value": "viewModelScope" },
+        {
+          "grader": "judge",
+          "rubric": "A correct answer launches the repository save call inside `viewModelScope.launch { ... }` from the ViewModel, not `GlobalScope.launch`, because viewModelScope is cancelled automatically when the ViewModel is cleared, while a GlobalScope coroutine keeps running (and can still mutate state) after the screen and ViewModel are gone.",
+          "pass_criteria": [
+            "Names `viewModelScope.launch` (or `viewModelScope.launch { }` with the repository call inside it) as the concrete launch mechanism.",
+            "Explains why: viewModelScope ties the coroutine's lifetime to the ViewModel, cancelling it when the ViewModel is cleared, unlike an unscoped or globally-scoped coroutine."
+          ],
+          "fail_criteria": [
+            "Recommends `GlobalScope.launch` (or an equivalent unstructured, unscoped coroutine) for the save call. Mentioning GlobalScope only to explain why it should be avoided here is not a failure.",
+            "Recommends launching the coroutine with no scope tied to the ViewModel's lifecycle at all, or launching it from a Composable's `rememberCoroutineScope()` instead of the ViewModel that owns the save action."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Launch it inside `viewModelScope.launch { repository.save(data) }` right in the ViewModel function the button click calls. `viewModelScope` is already tied to this ViewModel's lifecycle -- Jetpack's `ViewModel` cancels it automatically in `onCleared()`, so if the user navigates away mid-save the coroutine gets cancelled along with everything else, instead of continuing to run against a repository call whose result no screen is left to observe. Don't reach for `GlobalScope.launch` here: nothing would cancel it when the ViewModel goes away, so it can keep running -- and potentially push a state update or trigger a side effect -- well after the screen that started it is gone.",
+        "known_wrong": "Just fire it with `GlobalScope.launch { repository.save(data) }` inside the click handler -- it's a simple save call, and using GlobalScope means you don't have to worry about scope lifetimes at all, it'll just run in the background regardless of what the ViewModel or screen is doing.",
+        "vague": "Launch the save call in a coroutine tied to the ViewModel's own lifecycle so it doesn't leak.",
+        "subtle_wrong": "Since this ViewModel already exposes a `CoroutineScope` field you constructed yourself with `CoroutineScope(Dispatchers.IO)` in its init block, just launch the save call on that: `scope.launch { repository.save(data) }`. It keeps the save logic off viewModelScope so a slow save doesn't interact with anything else the ViewModel launches on viewModelScope."
+      },
+      "anti_patterns": ["GlobalScope"]
+    }
+  ]
+}

package/src/gdskills/bundled/stacks/kotlin-android/skills/kotlin-android-build-fix/SKILL.md

@@ -0,0 +1,151 @@
+---
+name: kotlin-android-build-fix
+description: "Use when a Gradle Android build, ktlintCheck, detekt, or lint task fails, or a Kotlin compile/type error blocks the build -- resolves Gradle/AGP/Kotlin version mismatches, Compose Compiler mismatches, unresolved dependencies, and lint/detekt findings with the smallest root-cause fix."
+triggers:
+  - "the Android build is failing"
+  - "gradle sync is broken after this change"
+  - "detekt is failing on this module"
+  - "lint is flagging this Android change"
+  - "this Kotlin file won't compile"
+  - "resolve this dependency conflict in build.gradle"
+metadata:
+  origin: authored
+  category: build-fix
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# Kotlin/Android build fix
+
+Resolve a Gradle/Android build failure: a Kotlin compile error, a
+Gradle/AGP/Kotlin/Compose-Compiler version mismatch, an unresolved
+dependency, or a `ktlint`/`detekt`/`lint` failure — with the smallest
+change that fixes the actual root cause. `rules/coding-style.mdc` and
+`rules/security.mdc` govern what a "correct" fix looks like; this skill
+never reaches for a suppression instead of a fix.
+
+## Workflow
+
+### Step 1: Reproduce and classify
+
+```bash
+./gradlew assembleDebug
+./gradlew lint
+```
+
+Run the project's configured static-analysis task if present
+(`./gradlew ktlintCheck` or `./gradlew detekt`, checked via a
+`.editorconfig`/`ktlint`/`detekt.yml` config file). Read the exact error
+text and classify it:
+
+- **Compile error** (unresolved reference, type mismatch, wrong argument
+  count, an unhandled `when` branch on a sealed type).
+- **Version/toolchain mismatch** (Kotlin/AGP/Gradle/Compose-Compiler
+  versions incompatible with each other, or with the project's declared
+  `compileSdk`/`minSdk`).
+- **Dependency resolution failure** (a missing/conflicting artifact
+  version in `build.gradle(.kts)`, a version-catalog entry that doesn't
+  resolve).
+- **Lint finding** (`./gradlew lint`'s own Android Lint checks).
+- **ktlint/detekt finding** (a style or static-analysis rule violation).
+
+### Step 2: Fix by category
+
+**Version/toolchain mismatch:** since Kotlin 2.0, the Compose Compiler ships
+via the `org.jetbrains.kotlin.plugin.compose` Gradle plugin versioned
+IDENTICALLY to the Kotlin version itself (`version.ref = "kotlin"` in the
+version catalog) — there is no separate compiler-to-Kotlin compatibility
+matrix to consult on a current project; a mismatch here usually means the
+plugin's declared version drifted from the Kotlin version, or (pre-2.0
+project) an old `composeOptions { kotlinCompilerExtensionVersion }`
+declaration left over from before the plugin migration. Align the plugin
+version to match Kotlin exactly, or migrate off `kotlinCompilerExtensionVersion`
+to the plugin. Only bump `compileSdk`/`minSdk` when the failure actually
+requires the newer API, and say so in the report.
+
+**Dependency resolution failure:** run `./gradlew :module:dependencies
+--configuration <config>` to see the actual resolved tree before pinning
+a version by hand; prefer aligning versions through the project's version
+catalog (`libs.versions.toml`) over an ad hoc `resolutionStrategy` force,
+unless the conflict is a genuine, documented incompatibility that needs
+one.
+
+**Lint finding:** fix the underlying issue the finding names (a real
+resource/API-level issue, a missing content description, an exported
+component with no permission). Never add a blanket `lint {
+abortOnError = false }`/`disable` entry (the current Android Gradle Plugin
+DSL block is `lint { }`; the older `lintOptions { }` block is deprecated)
+or a file-level `@Suppress` whose only purpose is to make the check stop
+complaining without addressing what it found; a narrowly-scoped, justified
+suppression at the single call site (with a comment explaining why) is the
+last resort, not the first move.
+
+**ktlint/detekt finding:** fix the actual style/complexity issue the rule
+names. Never disable the rule project-wide in `.editorconfig`/
+`detekt.yml` to silence one occurrence without discussing it in the
+report.
+
+**Compile error (sealed `when` not exhaustive):** add the missing branch
+handling the new/overlooked case — never an `else -> {}` branch that
+silently swallows a case a sealed hierarchy was specifically designed to
+force you to handle.
+
+### Step 3: Verify
+
+```bash
+./gradlew assembleDebug
+./gradlew testDebugUnitTest
+./gradlew lint
+```
+
+Re-run the project's `ktlintCheck`/`detekt` task if it was part of the
+original failure. All must exit 0 before reporting done.
+
+### Step 4: Report
+
+```
+Fixed: Compose Compiler plugin version mismatch in gradle/libs.versions.toml
+  - Root cause: org.jetbrains.kotlin.plugin.compose left pinned to the old
+    Kotlin version after a Kotlin bump (the plugin must track Kotlin exactly
+    since Kotlin 2.0, not a separate compatibility pairing)
+  - Set the plugin's version.ref to the same catalog entry as kotlin
+  - ./gradlew assembleDebug/testDebugUnitTest/lint all pass
+```
+
+State the root cause in one sentence, not just "build now passes."
+
+## Rules
+
+- Find and fix the smallest change that addresses the actual root cause —
+  never widen a fix beyond what the failure requires.
+- NEVER add a blanket `@Suppress`, `lint { abortOnError = false }`,
+  or a project-wide `detekt`/`ktlint` rule disable to silence a finding
+  instead of fixing what it found.
+- NEVER bump `compileSdk`, `minSdk`, or a major Gradle/Kotlin/AGP version
+  just to make an error disappear without understanding why it changed.
+- NEVER replace a non-exhaustive sealed `when`'s missing branch with a
+  catch-all `else` that discards the case it exists to force you to
+  handle.
+- NEVER delete or skip a failing test to reach a green build.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "I'll add `@Suppress(\"..\")` at the top of the file so detekt stops complaining" | Silences every finding of that type in the whole file instead of fixing the one the build actually flagged; fix the underlying issue at the specific site instead |
+| "I'll bump compileSdk to the latest to make this dependency resolve" | Changes the module's target API surface for every consumer to dodge one dependency conflict; check the actual required version first |
+| "I'll add an `else -> {}` branch so this `when` compiles" | Defeats the reason the state was modeled as sealed in the first place — a genuinely new case now silently does nothing instead of failing to compile |
+| "This lint check is annoying, I'll just disable it in the module's lint block" | Turns off the check for every future file in the module, not just this one finding; fix the finding or scope a suppression narrowly with a reason |
+
+## Verification
+
+Do not report the fix done until all of the following hold:
+
+- `./gradlew assembleDebug`, `./gradlew testDebugUnitTest`, and
+  `./gradlew lint` all exit 0.
+- The project's `ktlintCheck`/`detekt` task (if configured) exits 0.
+- The change is the smallest one that addresses the stated root cause —
+  no unrelated files touched.
+- The report states the root cause in one sentence, not just "build now
+  passes."

package/src/gdskills/bundled/stacks/kotlin-android/skills/kotlin-android-build-fix/evals.json

@@ -0,0 +1,76 @@
+{
+  "triggers": {
+    "positive": [
+      "Gradle sync is red after I touched this module's build file",
+      "The build broke right after bumping a library version",
+      "assembleDebug is failing and I can't tell why",
+      "Something in this module won't compile since the merge",
+      "CI is red on the Android job, can you sort it out",
+      "This module's static analysis task is blocking the build",
+      "The app won't build after pulling the latest changes"
+    ],
+    "negative": [
+      "Xcode build is failing after this Swift package bump",
+      "Flutter's pub get is failing after this dependency change",
+      "dotnet build is failing after this NuGet package update",
+      "npm run build is failing after this dependency bump",
+      "pip install is failing after this requirements.txt change",
+      "Implement a new screen for the checkout flow",
+      "Review this diff for goroutine-style leaks before merging"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "non-exhaustive-sealed-when",
+      "prompt": "After adding a new `ProfileUiState.RateLimited` variant to our sealed interface, the `when (state)` in ProfileScreen.kt no longer compiles because it's not exhaustive. What's the right way to fix it?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct fix adds a real branch to the when block that handles the new RateLimited state with its own appropriate UI/behavior, keeping the when exhaustive by design; it does not add a catch-all else branch that silently does nothing or reuses an unrelated existing branch, since that would defeat the reason the state is modeled as a sealed hierarchy in the first place -- to force every case to be handled.",
+          "pass_criteria": [
+            "States that a dedicated branch for RateLimited should be added to the when, not a generic else/catch-all.",
+            "Names or sketches what that branch should actually do (show a rate-limit specific message/UI, or otherwise something specific to that state), not just 'handle it'.",
+            "Explains why an else/catch-all branch would be the wrong fix here: it would silently swallow this case (and any future new case) instead of forcing it to be handled."
+          ],
+          "fail_criteria": [
+            "Recommends adding an `else -> {}` (or equivalent catch-all) branch to make the when compile without giving RateLimited its own real handling.",
+            "Recommends reverting or removing the new RateLimited variant just to make the existing when compile again."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Add a real `is ProfileUiState.RateLimited ->` branch to the `when (state)` in `ProfileScreen.kt` that renders whatever this state should actually show -- most likely a message telling the user to try again later, similar in shape to how the `Error` branch is handled but with rate-limit-specific copy. Don't reach for `else -> {}` to make the compiler stop complaining: the whole point of modeling `ProfileUiState` as a sealed interface is that adding a new variant forces every `when` over it to be updated, and an `else` branch throws that guarantee away -- the next new state added later would silently fall into the same catch-all with no one noticing.",
+        "known_wrong": "Easiest fix: add `else -> {}` at the bottom of the `when (state)` block. It makes the compiler happy immediately and you can come back and add real handling for `RateLimited` later once there's time to design the UI for it.",
+        "vague": "Add a branch for the new state so the when compiles properly.",
+        "subtle_wrong": "Add `is ProfileUiState.RateLimited -> { /* reuse existing error UI for now */ }` that just falls through to whatever the `Error` branch already renders, without adding a distinct case -- that satisfies the exhaustiveness check without having to design new UI right now, and you can split it out into its own real branch in a follow-up."
+      }
+    },
+    {
+      "id": "detekt-suppress-vs-root-cause",
+      "prompt": "detekt is failing on a new `ProfileRepository.kt` file with a `TooGenericExceptionCaught` finding on a broad `catch (e: Exception)` block that just logs and returns a default value. How should this get fixed?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct fix narrows the catch to the specific exception type(s) the call can actually throw (or a small, deliberate set of them) instead of catching the broad Exception type, so the underlying issue detekt is flagging -- a catch clause wide enough to also swallow unrelated bugs -- is actually addressed; it does not add a blanket @Suppress(\"TooGenericExceptionCaught\") annotation or disable the rule in detekt.yml to make the finding disappear without changing the catch itself.",
+          "pass_criteria": [
+            "States that the catch clause should be narrowed to the specific exception type(s) the call can actually throw, not left as a broad catch (e: Exception).",
+            "Explicitly rejects silencing the finding via @Suppress or a detekt.yml rule disable as the fix.",
+            "The fix addresses the actual catch block detekt flagged, not an unrelated part of the file."
+          ],
+          "fail_criteria": [
+            "Recommends adding @Suppress(\"TooGenericExceptionCaught\") to the function or catch block to make the finding disappear.",
+            "Recommends disabling the TooGenericExceptionCaught rule in detekt.yml (project-wide or for this file) instead of narrowing the catch."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Narrow the `catch (e: Exception)` to whatever this call can actually throw -- for a repository call that's usually something like `IOException`/`HttpException` from the network client, possibly alongside a serialization exception if parsing happens in the same block. Kotlin has no multi-catch syntax (unlike Java's `catch (IOException | HttpException e)`), so catch each specific type in its own `catch` block, or catch a real common supertype the thrown types actually share -- not `Exception` as a stand-in for one. That way a genuine, unrelated bug elsewhere in that block (a `NullPointerException` from a real logic error) doesn't get silently swallowed and turned into 'just return the default' along with the network failures you actually meant to handle. Don't add `@Suppress(\"TooGenericExceptionCaught\")` here -- that keeps the broad catch exactly as risky as detekt flagged it, just with the warning turned off.",
+        "known_wrong": "Add `@Suppress(\"TooGenericExceptionCaught\")` right above the function -- the broad catch is intentional here since we want to return a default value no matter what goes wrong, and the annotation tells detekt that's a deliberate choice.",
+        "vague": "Tighten up the exception handling so it's not catching more than it should.",
+        "subtle_wrong": "Leave the broad `catch (e: Exception)` as is, but add a `detekt.yml` exclusion for this one file under the `TooGenericExceptionCaught` rule's `excludes` list -- that keeps the rule active for the rest of the module while acknowledging this specific file's catch is intentionally broad."
+      }
+    }
+  ]
+}

package/src/gdskills/bundled/stacks/kotlin-android/skills/kotlin-android-code-review/SKILL.md

@@ -0,0 +1,139 @@
+---
+name: kotlin-android-code-review
+description: "Use when reviewing a Kotlin/Android change for coroutine, Compose, and null-safety risks -- GlobalScope usage, side effects fired directly in a composable body, forced-unwrap on external data, mutable state leaked from a ViewModel, and exported manifest components. Read-only, no edits."
+triggers:
+  - "review this Android diff for coroutine leaks"
+  - "check this Compose change for recomposition bugs"
+  - "any null-safety issues in this Kotlin PR"
+  - "review this ViewModel change for state leaks"
+  - "check the manifest changes in this Android diff"
+  - "review this mobile feature branch before merge"
+metadata:
+  origin: authored
+  category: review
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# Kotlin/Android code review
+
+Read-only review of a Kotlin/Android change for coroutine, Compose, and
+null-safety risks specific to this stack: unstructured coroutine scopes,
+side effects fired outside `LaunchedEffect`/`DisposableEffect`, forced
+null-unwraps on external data, leaked mutable state, and manifest
+exposure. 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 `*.kt`/`*.kts` files (and `AndroidManifest.xml` when
+   touched) 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
+
+**Coroutines**
+- Any `GlobalScope.launch`/`GlobalScope.async` in the diff — flag it;
+  the fix direction is `viewModelScope`/`lifecycleScope`/a passed-in
+  scope.
+- A new coroutine (`launch`/`async`) with no scope tied to a lifecycle
+  owner, or a fire-and-forget `launch` whose result/exception is silently
+  dropped.
+- A suspend call awaited with no cancellation awareness inside a loop
+  that should stop early (missing `ensureActive()`/`isActive` check in a
+  long-running or CPU-bound loop).
+
+**Compose**
+- A suspend call, navigation event, `Toast`, or analytics call written
+  directly in a composable's body instead of inside `LaunchedEffect`/
+  `DisposableEffect` — flag it; it can re-fire on every recomposition or
+  run at the wrong time.
+- A composable parameter of an unstable type (a plain mutable `List`, a
+  class with public `var`s and no `@Stable`/`@Immutable`) in a
+  performance-sensitive position (a `LazyColumn` item, a frequently
+  recomposing parent) — under the strong skipping mode default since
+  Kotlin 2.0.20 this no longer defeats skipping outright (the compiler
+  falls back to instance-identity comparison), but a NEW instance built on
+  every call (a `List` rebuilt each recomposition) still can't compare
+  equal and skip; flag it as a likely unnecessary-recomposition risk, not
+  a hard skip defeat.
+- State read/written with a bare `var` inside a composable body with no
+  `remember`/`rememberSaveable` wrapper — flag it; the value will not
+  survive recomposition as intended.
+
+**Null safety**
+- `!!` on a value sourced from outside this function's own prior checks —
+  a network response field, an `Intent` extra, a `savedStateHandle`
+  lookup, a `find`/`firstOrNull` result — flag it; the fix direction is a
+  safe call, Elvis operator, or `requireNotNull` with a message.
+
+**State exposure**
+- A `ViewModel` exposing a `MutableStateFlow`/`MutableLiveData` (not the
+  read-only view) on its public surface — flag it; any collector outside
+  the `ViewModel` can then push a new value.
+
+**Manifest and security**
+- A new or changed `<activity>`/`<service>`/`<receiver>`/`<provider>`
+  entry with `android:exported="true"` and no permission attribute — flag
+  it, and check whether the component actually needs to be reachable
+  from other apps.
+- A new credential/token written to plain `SharedPreferences` — flag it;
+  the fix direction is the Android Keystore directly, not
+  `EncryptedSharedPreferences` (known reliability issues, no longer
+  recommended for new code per `rules/security.mdc`).
+
+### Step 3: Report
+
+For each finding: file:line, the pattern, why it matters (leak, crash,
+recomposition bug, data exposure), and the fix direction — but do not
+apply it.
+
+```
+feature/profile/ProfileViewModel.kt:28 — GlobalScope.launch used to save
+  the profile. Risk: outlives the ViewModel, can write state after the
+  screen is gone. Fix direction: replace with viewModelScope.launch.
+```
+
+## Rules
+
+- NEVER edit code — findings and fix direction only.
+- Flag GlobalScope usage, side effects outside LaunchedEffect/
+  DisposableEffect, unstable composable parameters, `!!` on external
+  data, leaked mutable ViewModel state, and unguarded exported manifest
+  components; do not report generic style nits already covered by
+  `ktlint`/`detekt`/`lint` (those are noise here).
+- Distinguish a finding the diff introduces from a pre-existing one in
+  code the diff merely touches.
+- When a suspected recomposition or leak issue is not certain from
+  reading alone, say so and suggest a way to confirm (a Compose layout
+  inspector trace, a `LeakCanary` run) rather than asserting it without
+  evidence.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "This GlobalScope call is for a quick analytics ping, it's harmless" | Harmless intent doesn't change that nothing cancels it; flag it regardless of what the call does |
+| "The `!!` here is fine, this field is always populated by the backend" | "Always" is an external contract, not a compiler-verified guarantee; report it as a finding, the API can still return the field as null once |
+| "I'll just fix the exported manifest attribute myself, it's a one-line change" | This skill is read-only; report the finding and its fix direction, do not edit the file |
+| "The composable parameter type is a List, that's fine for now" | A raw `List` is unstable, and strong skipping's instance-identity fallback still won't skip a NEW list instance built every call; flag it, especially in a list item or frequently-recomposing position |
+
+## Verification
+
+Do not report the review done until all of the following hold:
+
+- Every changed `*.kt`/`*.kts` file (and `AndroidManifest.xml`, if
+  touched) 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/kotlin-android/skills/kotlin-android-code-review/evals.json

@@ -0,0 +1,78 @@
+{
+  "triggers": {
+    "positive": [
+      "Take a look at this diff before I open the PR for the mobile app",
+      "Anything risky in these ViewModel changes I should fix before merge",
+      "Can you spot problems in this screen's new composable before I push",
+      "Double-check this Kotlin diff doesn't introduce any leaks",
+      "Give this Android pull request a once-over for correctness",
+      "Flag anything sketchy in this profile screen's changes",
+      "Is this manifest change safe to ship"
+    ],
+    "negative": [
+      "Review this SwiftUI diff for retain cycles before merging",
+      "Check this Flutter pull request for setState misuse",
+      "Review this ASP.NET Core controller diff for missing authorization",
+      "Check this React diff for missing hook dependencies",
+      "Review this Python diff for unhandled exceptions",
+      "Write tests covering this screen's new error state",
+      "Fix the compile error in this ViewModel after the merge"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "globalscope-in-viewmodel-diff",
+      "prompt": "Here's a diff to a ProfileViewModel: it adds a new `refresh()` function whose body is `GlobalScope.launch { val data = repository.fetch(); _state.value = ProfileUiState.Content(data) }`, called from the screen's pull-to-refresh handler. What do you flag in review?",
+      "strictness": "high",
+      "expected_behavior": [
+        { "grader": "regex", "value": "viewModelScope" },
+        {
+          "grader": "judge",
+          "rubric": "A correct review flags the GlobalScope.launch in refresh() as the primary finding: it should be viewModelScope.launch instead, because GlobalScope is not cancelled when the ViewModel is cleared, so a slow fetch can still resolve and write to _state.value after the screen (and this ViewModel) are gone, and the finding names the actual risk (a completed background call writing state, or the exposed StateFlow's writer outliving its owner) rather than only restating that GlobalScope is discouraged.",
+          "pass_criteria": [
+            "Names the exact line/construct (GlobalScope.launch in refresh()) as the finding, not a generic 'watch your coroutines' comment.",
+            "States the concrete fix direction: replace GlobalScope.launch with viewModelScope.launch.",
+            "Explains the actual risk in this diff: an in-flight fetch can complete and write to _state.value after the ViewModel/screen is gone, since nothing cancels a GlobalScope coroutine when the ViewModel is cleared."
+          ],
+          "fail_criteria": [
+            "Does not flag the GlobalScope.launch call as a finding at all.",
+            "Flags it only as a vague style nit ('avoid GlobalScope, it's not idiomatic') with no explanation of the actual lifecycle/leak risk it causes in this specific diff."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Flag `refresh()`'s use of `GlobalScope.launch` as the main issue in this diff: it should be `viewModelScope.launch` instead. As written, if the user pulls to refresh and then immediately backs out of the screen, `GlobalScope.launch` keeps running -- nothing about it is tied to this ViewModel's lifecycle -- so `repository.fetch()` can still complete and write to `_state.value` well after the ViewModel has been cleared and the screen is gone. `viewModelScope` is cancelled automatically in `onCleared()`, which is exactly the guarantee this refresh call needs. Fix direction: `viewModelScope.launch { val data = repository.fetch(); _state.value = ProfileUiState.Content(data) }`.",
+        "known_wrong": "This looks fine -- `refresh()` is a short, one-shot network call triggered by a manual pull-to-refresh gesture, so `GlobalScope.launch` here is low-risk; users don't typically leave a screen mid-refresh, and even if they do, updating a `StateFlow` no one is collecting anymore doesn't really cause a problem.",
+        "vague": "Coroutine scoping in this ViewModel could probably be tightened up a bit.",
+        "subtle_wrong": "Worth a note that `GlobalScope.launch` is used here instead of `viewModelScope.launch`, but since the closure only writes to `_state.value` and doesn't touch the UI directly, the worst case is a StateFlow update nobody collects if the screen is already gone -- not a crash, just a wasted write. I'd leave a comment but wouldn't block the PR on it."
+      },
+      "anti_patterns": ["GlobalScope"]
+    },
+    {
+      "id": "forced-unwrap-external-data",
+      "prompt": "This diff adds `val userId = intent.getStringExtra(\"user_id\")!!` at the top of an Activity's `onCreate()`, reading an extra from the incoming Intent that launched it. What's worth flagging here?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct review flags the `!!` on intent.getStringExtra(\"user_id\") as a crash risk: getStringExtra returns a nullable String, and since the Intent came from outside this code (another activity, a deep link, a notification, a test harness) there is no compile-time guarantee the extra is present, so a missing extra crashes onCreate() with an NPE; the fix direction is a safe call/Elvis default or requireNotNull with a message, not simply asserting the value is always there.",
+          "pass_criteria": [
+            "Names the specific line (`intent.getStringExtra(\"user_id\")!!`) as the finding.",
+            "States why it's risky: the extra is nullable and Intent-sourced (from outside this code's control), so a missing extra causes an NPE crash at onCreate().",
+            "Gives a concrete fix direction: a safe call with a default/early return, or requireNotNull(...) { \"...\" } with an explanatory message, instead of the bare !!."
+          ],
+          "fail_criteria": [
+            "Does not flag the forced-unwrap on intent.getStringExtra(\"user_id\") at all.",
+            "Excuses the `!!` on the grounds that this Activity is always launched from a known, controlled place in the same app, without noting that an Intent can still arrive from a deep link, a test, or the OS restoring the Activity in a way that omits the extra."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Flag `intent.getStringExtra(\"user_id\")!!` -- `getStringExtra` returns `String?`, and an `Intent` is fundamentally external input: it can come from a deep link, a notification, another app if this Activity is exported, or the system recreating the Activity, none of which are guaranteed to include the extra the way an internal call site would be. The `!!` turns a missing extra into an immediate crash in `onCreate()`. Fix direction: either bail out safely (`val userId = intent.getStringExtra(\"user_id\") ?: run { finish(); return }`) or fail loudly with context via `requireNotNull(intent.getStringExtra(\"user_id\")) { \"ProfileActivity requires a user_id extra\" }` if a missing value truly should never happen and you want a clear crash message instead of a bare NPE.",
+        "known_wrong": "This is fine -- this Activity is only ever started from one place in our own code, and that call site always sets the `user_id` extra, so the `!!` will never actually fail in practice.",
+        "vague": "Might want to handle the null case here a bit more carefully.",
+        "subtle_wrong": "The `!!` itself isn't great style, but I'd let it go for now since `onCreate()` already wraps this in a `try/catch` further down that logs and finishes the Activity on any exception -- so a crash here gets handled gracefully one level up regardless of whether the extra is missing."
+      }
+    }
+  ]
+}