@mrciphersmith/keryx 0.3.3 → 0.3.6

package/src/gdskills/bundled/stacks/flutter-dart/skills/flutter-build-fix/evals.json

@@ -0,0 +1,79 @@
+{
+  "triggers": {
+    "positive": [
+      "Getting a red squiggly on an undefined identifier when I run the analyzer",
+      "pubspec.yaml and pubspec.lock are out of sync, please fix",
+      "Resolve this pub version solving conflict between two packages",
+      "Upgraded a package and now the app will not compile",
+      "CI keeps failing on the lint step for this PR, can you sort it out",
+      "Ran pub upgrade this morning and the whole test suite stopped compiling",
+      "Dart compile error about a nullable value, fix the build"
+    ],
+    "negative": [
+      "npm install is failing with a peer dependency conflict",
+      "cargo build is failing for this Rust crate after a version bump",
+      "NuGet restore is failing for this C#/.NET project",
+      "Gradle build is failing for this Kotlin Android module",
+      "Implement a new screen in this Flutter app",
+      "Review this Flutter diff for concurrency-adjacent lifecycle bugs",
+      "Write widget tests for this Flutter form"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "pubspec-lock-mismatch",
+      "prompt": "flutter build fails saying pubspec.lock is out of date after I bumped a dependency version in pubspec.yaml. How do I fix it?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer identifies that pubspec.lock is stale relative to pubspec.yaml's requirements after the dependency bump and fixes it by running flutter pub get (or flutter pub upgrade for a newer compatible version). For a genuine version conflict it checks flutter pub deps or the version-solving error output before pinning a version by hand, rather than routing around the error some other way.",
+          "pass_criteria": [
+            "Names `flutter pub get` (or `flutter pub upgrade` when a newer compatible version is actually needed), run from the project root, as the concrete command that resolves the stale pubspec.lock -- not merely 'sync the files' or 'run the tool that fixes this'.",
+            "States the root cause: pubspec.lock no longer matches what pubspec.yaml now requires after the version bump, not just 'run this command' with no explanation.",
+            "Either names a concrete verification step afterward (`flutter analyze` and/or `flutter test`) or does not suggest skipping verification."
+          ],
+          "fail_criteria": [
+            "Recommends bumping the Dart/Flutter SDK constraint in pubspec.yaml's environment section to make the error go away, or bumping another dependency's version by hand, as a substitute for running flutter pub get.",
+            "Recommends hand-editing the version/hash entries in pubspec.lock directly instead of regenerating it with flutter pub get."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "This means pubspec.lock no longer matches what pubspec.yaml now requires after you bumped the dependency version. The fix is to run `flutter pub get` from the project root -- it recomputes pubspec.lock against pubspec.yaml's constraints, resolving the new version and any transitive dependencies it pulls in. If the version you bumped to needs a compatible-version bump beyond what `pub get` alone will resolve, use `flutter pub upgrade` instead. If `pub get`/`pub upgrade` reports a real version-solving conflict rather than a simple stale-lock error, don't just bump another package by hand -- read the conflict output (it names which packages disagree) and check `flutter pub deps` to see the actual dependency graph before deciding how to resolve it. After that, re-run `flutter analyze` and `flutter test` to confirm the project is consistent again before considering this done. Avoid hand-editing pubspec.lock directly; it's a generated file meant to be regenerated by tooling, not patched by hand.",
+        "known_wrong": "Honestly the fastest fix here is to bump the Dart SDK constraint in pubspec.yaml's `environment:` section to a newer version -- that usually makes pubspec.lock errors like this go away without needing to figure out what `flutter pub get` would even change. Just widen the `sdk:` constraint and re-run the build; if it still complains, bump the specific dependency version in pubspec.yaml up a bit further too until the error clears. You don't really need to check `flutter pub deps` or read the conflict output for a simple lock mismatch like this -- that's overkill for what's usually just a version being out of date.",
+        "vague": "This is just a dependency sync issue -- make sure your pub files are consistent with each other again and the build should pass.",
+        "subtle_wrong": "Bump the dependency's version in pubspec.yaml directly to match what your code now needs, then try `flutter build` again -- if pubspec.lock still complains, add the missing version entries to pubspec.lock by hand so the two files line up. That gets you to a green build without having to run the whole project through `flutter pub get` and re-resolve everything else it might touch."
+      }
+    },
+    {
+      "id": "no-ignore-suppression",
+      "prompt": "flutter analyze is flagging a null-safety warning on a value I'm using in my Dart code. How should I fix it, without just making the analyzer stop complaining?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer fixes the actual nullability gap the analyzer found -- adding a null check, using ?./??, making a parameter required, or otherwise confirming/guaranteeing non-null before use -- instead of suppressing the finding with an `// ignore:` comment or a blanket `// ignore_for_file:` directive. Since the prompt supplies no actual code, the answer may either ask for the missing concrete detail (the exact error and the surrounding code) while still committing to the right kind of fix and explicitly ruling out an ignore comment, or give a concrete illustrative example (e.g. a corrected null check or a `required` parameter) clearly framed as an example rather than claimed as the real fix for code it never saw.",
+          "pass_criteria": [
+            "Commits to actually resolving the underlying nullability gap (a null check, `?.`/`??`, a `required` parameter, or an equivalent concrete guarantee of non-null) rather than only describing the goal in the abstract.",
+            "Either shows this as a concrete illustrative example (since the prompt gives no real code to quote from) or explicitly asks for the missing error text/code while still committing to fixing the root cause rather than suppressing it.",
+            "Explicitly rules out `// ignore:`/`// ignore_for_file:` as the fix, not merely omitting any mention of it."
+          ],
+          "fail_criteria": [
+            "Recommends adding `// ignore:` (naming the specific lint rule) or a blanket `// ignore_for_file:` directive to silence the finding instead of fixing the underlying nullability gap.",
+            "Recommends adding `!` to the value purely to stop the analyzer from complaining, with no stated basis for why the value is actually non-null at that point."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "I don't have the actual error text or the surrounding code, so I can't point at the exact fix -- but the shape of it is: flutter analyze's null-safety check is telling you a value could be null where non-null is required, and the fix is to actually resolve that gap, not silence the warning. Concretely, that usually looks like one of: adding an explicit `if (value == null) { ... }` guard before the use, switching to `value?.someMethod()` or `value ?? fallback` if a default is acceptable, or making a constructor/function parameter `required` (or giving it a non-null default) if it should never have been nullable in the first place. As an illustrative example: if you had `String? name; return name.toUpperCase();`, the fix is `return name?.toUpperCase() ?? '';` or an early-return guard -- not `// ignore: use_of_nullable_value_without_null_check` above the line, which just tells the analyzer to stop looking rather than addressing whether the value can actually be null there. Once you've made the real fix, re-run `flutter analyze` to confirm the finding is genuinely resolved, not just hidden. Send over the exact error and the code around it if you want the precise fix rather than this general pattern.",
+        "known_wrong": "The simplest fix is to just add `// ignore: <the specific lint rule name>` on the line above the flagged code -- that value is probably fine in practice, and it stops flutter analyze from flagging it every time CI runs. You don't need to add a null check or change the function's signature; the ignore comment is exactly what it's for. If several similar warnings show up elsewhere, you can add `// ignore_for_file: <rule>` at the top of the file instead so you don't have to annotate every line individually.",
+        "vague": "You should fix the actual null-safety issue instead of suppressing the warning -- make sure the value is properly handled before you call this done.",
+        "subtle_wrong": "Since there's no code attached, here's the general pattern: add `!` after the flagged value so the analyzer treats it as non-null and stops complaining, e.g. `value!.someMethod()`. That resolves the warning without needing to restructure anything, and you can always come back and add a proper null check later if it turns out the value really can be null at runtime."
+      },
+      "anti_patterns": [
+        "ignore_for_file"
+      ]
+    }
+  ]
+}

package/src/gdskills/bundled/stacks/flutter-dart/skills/flutter-code-review/SKILL.md

@@ -0,0 +1,124 @@
+---
+name: flutter-code-review
+description: "Use when reviewing a Flutter/Dart change for lifecycle and null-safety risks -- unguarded BuildContext/setState after an await, an undisposed controller/subscription, bang-operator misuse, and business logic inside build(). Read-only, no edits."
+triggers:
+  - "review this Flutter diff for missing mounted checks"
+  - "check this Flutter change for a disposed controller"
+  - "review this Dart pull request for null-safety issues"
+  - "any BuildContext misuse in this Flutter change"
+  - "review this Flutter widget for lifecycle bugs"
+  - "check this Flutter diff for logic inside build()"
+metadata:
+  origin: authored
+  category: review
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# Flutter/Dart code review
+
+Read-only review of a Flutter/Dart change for lifecycle and null-safety
+risks specific to Flutter: unguarded `BuildContext`/`setState` after an
+`await`, an undisposed controller or subscription, bang-operator misuse,
+and business logic misplaced inside `build()`. 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 `*.dart` 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 widget/class against the focus list
+
+**BuildContext and setState after an async gap**
+- Every `await` inside a `State` method that is followed by `setState()`
+  has a `mounted` check between the `await` and the `setState()` call —
+  flag a `setState()` reached after an `await` with no intervening
+  `mounted`/`context.mounted` check.
+- Every `await` inside a callback holding a `BuildContext` that is
+  followed by any use of that `context` (`Navigator.of(context)`,
+  `ScaffoldMessenger.of(context)`, `Theme.of(context)`, a dialog) has a
+  `context.mounted` check first — flag its absence.
+
+**Lifecycle and disposal**
+- Every `TextEditingController`/`AnimationController`/
+  `StreamSubscription`/`FocusNode`/`ScrollController` created in
+  `initState()` (or elsewhere in the `State`) has a matching release in
+  `dispose()` — flag one created with no corresponding disposal.
+- `dispose()` calls `super.dispose()` last, not first — flag it if the
+  super call happens before the class's own cleanup.
+
+**Null safety**
+- A bang operator (`!`) used on a value whose non-null status is not
+  locally evident (crossed an `await`, came from a widget/state field that
+  could be null, no preceding null check in the same scope) — flag it as
+  a potential `null check operator used on a null value` crash risk.
+- A `late` field whose initialization path is not obviously guaranteed
+  before first read — flag as a potential `LateInitializationError` risk.
+
+**Build method hygiene**
+- Network calls, parsing, or other side-effecting/expensive logic written
+  directly inside a `build()` method instead of a controller/view-model —
+  flag it; `build()` can run many times for reasons unrelated to data
+  changing.
+- A widget constructor that could be `const` (all fields final and
+  const-constructible) but is not — flag as a missed `const`
+  opportunity when it is on a widget likely to rebuild often (a list
+  item, a child of an animated ancestor); do not flag it as a blocker for
+  a one-off, rarely-rebuilt widget.
+
+### Step 3: Report
+
+For each finding: file:line, the pattern, why it matters (crash risk,
+resource leak, stale UI), and the fix direction — but do not apply it.
+
+```
+lib/order/order_screen.dart:58 — setState() called after `await
+_repository.submit(order)` with no mounted check first. Risk: throws
+"setState() called after dispose()" if the user navigates away while the
+submit call is in flight. Fix direction: add `if (!mounted) return;`
+immediately after the await, before the setState call.
+```
+
+## Rules
+
+- NEVER edit code — findings and fix direction only.
+- Flag unguarded `BuildContext`/`setState` after an `await`, undisposed
+  controllers/subscriptions, risky bang-operator use, and business logic
+  inside `build()`; do not report generic style nits already covered by
+  `dart format`/`flutter analyze`'s default lint set (those are noise
+  here).
+- Distinguish a finding the diff introduces from a pre-existing one in
+  code the diff merely touches.
+- When a suspected disposal gap is not certain from reading alone (a
+  controller might be disposed by a base class or a mixin not shown in
+  the diff), say "confirm the base class disposes this" rather than
+  asserting a leak exists without evidence.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "The await usually resolves before the user can navigate away" | "Usually" is not a guarantee; flag the missing mounted/context.mounted check regardless of how unlikely the race feels |
+| "This controller is only used on one screen, disposal is a minor nit" | An undisposed controller leaks its underlying platform resources for the app's lifetime, not just the screen's; it is a real finding, not a nit |
+| "I'll just add the mounted check myself since it's a one-line fix" | This skill is read-only; report the finding and its fix direction, do not edit the file |
+| "The bang operator is probably fine here, I won't flag it without proof it crashes" | The point of flagging is the risk, not proof of an actual crash; a `!` on a value whose non-null status is not locally evident is a finding worth raising even without a reproduced crash |
+
+## Verification
+
+Do not report the review done until all of the following hold:
+
+- Every changed `*.dart` 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/flutter-dart/skills/flutter-code-review/evals.json

@@ -0,0 +1,74 @@
+{
+  "triggers": {
+    "positive": [
+      "Does this diff use the BuildContext safely after the async call finishes?",
+      "Take a look at whether this change cleans up its controllers properly",
+      "Review this Dart pull request for bang-operator misuse",
+      "Does this Flutter diff call setState after an await with no mounted check?",
+      "Review this Flutter widget for business logic inside build()",
+      "Check this Flutter change for lifecycle bugs before merging",
+      "Review this Flutter diff and report any null-safety risks"
+    ],
+    "negative": [
+      "Review this Flutter diff and also fix the bugs you find",
+      "Review this SwiftUI diff for @State lifecycle issues",
+      "Review this Jetpack Compose diff for recomposition bugs",
+      "Review this C#/.NET diff for async/await deadlocks",
+      "Review this React diff for missing effect dependencies",
+      "Implement the fix for the missing mounted check in this Flutter screen",
+      "Write widget tests for this Flutter screen's error state"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "read-only-mounted-check",
+      "prompt": "Review this Flutter diff: inside a button's onPressed handler, after `final result = await repository.submit(order);`, the very next line calls `ScaffoldMessenger.of(context).showSnackBar(...)` with no check in between. What do you find?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer identifies the missing context.mounted check between the await and the subsequent use of context as the problem, explains the risk (the widget could be disposed or navigated away from while the submit call was pending, so using context afterward can throw or act on a stale context), 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 missing context.mounted (or mounted) check between the await and the ScaffoldMessenger.of(context) call as the specific problem in this diff.",
+            "Explains the concrete risk: the widget could be disposed/navigated away from while the await was pending, so using context afterward is unsafe.",
+            "Names the concrete fix direction (add `if (!context.mounted) return;` right after the await, before the context use) as a finding, 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: after `await repository.submit(order)`, the code calls `ScaffoldMessenger.of(context).showSnackBar(...)` immediately, with no check that the context is still valid. That's a problem -- while the submit call was pending, the user could have navigated away from this screen or the widget could have been disposed for some other reason, and using `context` at that point (via `ScaffoldMessenger.of(context)`) can throw or act on a context that no longer corresponds to anything on screen. Fix direction: add `if (!context.mounted) return;` immediately after the `await`, before the `ScaffoldMessenger.of(context)` call, so the SnackBar is only shown when the widget is still mounted. 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": "Using context right after an await like this is a known risk, so I decided to edit the code directly instead of only reporting the finding: I added `if (!context.mounted) return;` right after the await and before the ScaffoldMessenger call, and the diff now includes that fix ready to merge.",
+        "vague": "That context use after the await looks a little risky -- might be worth double-checking before this merges.",
+        "subtle_wrong": "Finding: the ScaffoldMessenger.of(context) call right after the await has no mounted check, which is worth fixing. I went ahead and made a small proof-of-concept tweak adding the mounted check so you can see the shape of the change, though it should be reviewed and cleaned up before merging."
+      }
+    },
+    {
+      "id": "undisposed-controller-finding",
+      "prompt": "Review this Flutter diff: a new AnimationController is created in initState() of this StatefulWidget's State, but dispose() is not overridden anywhere in the class. What's wrong?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer identifies that the AnimationController created in initState() is never released because dispose() is not overridden, flags this as a resource leak (the controller's underlying ticker/resources persist for the app's lifetime even after the widget is gone), and reports a fix direction (override dispose(), call the controller's .dispose(), then super.dispose() last) as a finding without applying it, and does not accept a hedge about the leak being negligible as a substitute for actually flagging it.",
+          "pass_criteria": [
+            "Explicitly identifies that the AnimationController has no matching dispose() call because dispose() isn't overridden at all, not just 'this could be cleaner'.",
+            "Explains the concrete consequence: the controller's resources (ticker) leak for the app's remaining lifetime since nothing releases them when the widget is removed.",
+            "Names the concrete fix direction (override dispose(), call the controller's own .dispose(), then super.dispose() last) as a finding, not as a code change already made."
+          ],
+          "fail_criteria": [
+            "Dismisses the missing dispose() override as negligible or not worth flagging because the AnimationController is simple or the screen is short-lived, instead of requiring an explicit disposal."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Finding: an AnimationController is created in initState(), but this State doesn't override dispose() at all, so nothing ever releases it. That's a real leak -- an AnimationController holds a ticker tied to the animation scheduler, and without a matching `.dispose()` call, that ticker and the resources behind it stay alive for the rest of the app's lifetime even after this widget has been removed from the tree, accumulating with every time this widget is created and torn down. Fix direction: override `dispose()` on this State, call `_controller.dispose()` there, then `super.dispose()` last. I'm 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 really a blocker -- AnimationControllers are pretty lightweight, and since this widget probably doesn't get created and destroyed that often, the leak from skipping dispose() here is negligible in practice. I wouldn't hold up the diff over a missing dispose() override for something like this.",
+        "vague": "That controller without a dispose() override could be an issue -- might be worth double-checking before this merges.",
+        "subtle_wrong": "Finding: the AnimationController has no matching dispose() call. That said, since this widget only appears on one screen that isn't visited often, the leaked ticker resources are probably fine in practice, so this is a nice-to-have rather than something that needs fixing before merge."
+      }
+    }
+  ]
+}

package/src/gdskills/bundled/stacks/flutter-dart/skills/flutter-implementation/SKILL.md

@@ -0,0 +1,139 @@
+---
+name: flutter-implementation
+description: "Use when implementing or extending a feature in a Flutter app -- widget composition, state-management-agnostic lifecycle correctness, guarding BuildContext/setState across an async gap, and sound-null-safety idiom."
+triggers:
+  - "add this screen to the Flutter app"
+  - "implement this widget with the app's existing state management"
+  - "wire up this Flutter feature to call the repository"
+  - "add a form to this Flutter screen with validation"
+  - "extend this Flutter widget to show a loading and error state"
+  - "build this Flutter list screen backed by a Future"
+  - "add navigation from this screen to a detail screen"
+metadata:
+  origin: authored
+  category: implement
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# Flutter/Dart implementation
+
+Implement or extend a feature in a Flutter app: widget composition,
+lifecycle-correct state handling regardless of which state-management
+approach the project uses, safe `BuildContext`/`setState` use across async
+gaps, and sound-null-safety idiom. Scoped to Flutter/Dart specifically —
+`rules/coding-style.mdc`, `rules/patterns.mdc`, and `rules/security.mdc`
+carry the full stack-specific rule set this skill's checklist is drawn
+from; read them before writing code, not just this summary.
+
+## Workflow
+
+### Step 1: Discover the project's own conventions
+
+1. Read `pubspec.yaml` for the Dart/Flutter SDK constraint and which
+   state-management package (if any) is already a dependency —
+   `flutter_riverpod`/`riverpod`, `provider`, `flutter_bloc`, or none
+   (plain `StatefulWidget`). Match whichever is already there; do not
+   introduce a second state-management approach for one feature.
+2. Find the existing `lib/` layout (feature folders, a `widgets/`/
+   `screens/` split, a repository/service layer) and match it rather than
+   inventing a different structure for this change.
+3. Read 1-2 neighboring widgets/screens for: how they source data (a
+   repository interface, a provider, direct API calls), how they handle
+   loading/error/empty states, and whether `flutter_secure_storage` is
+   already used for anything sensitive this feature touches.
+
+### Step 2: Design before writing
+
+- Decide what is a `StatelessWidget` (pure function of its constructor
+  arguments) versus a `StatefulWidget` (owns mutable state, animation
+  controllers, subscriptions, or text/scroll controllers) — do not reach
+  for `StatefulWidget` when the state actually belongs in the project's
+  state-management layer instead.
+- Trace every `await` that follows with a use of `context` or a call to
+  `setState()`: plan the `context.mounted`/`mounted` check at each of
+  those points before writing the call that needs it.
+- Decide what data comes from a `Future` (fetch once, render loading →
+  data/error) versus a `Stream` (updates over time) and which widget
+  (`FutureBuilder`/`StreamBuilder`, or the project's state-management
+  async helper) will drive the corresponding UI states.
+
+### Step 3: Implement
+
+1. Compose small widgets (`rules/coding-style.mdc`); mark every
+   constructor `const` where its fields allow it, including at call
+   sites.
+2. Wire `initState`/`dispose` symmetrically for anything a `State`
+   acquires — a `TextEditingController`, `AnimationController`,
+   `StreamSubscription`, or `FocusNode` created in `initState()` gets
+   released in `dispose()`.
+3. After every `await` inside a `State` method or a callback holding a
+   `BuildContext`, check `mounted`/`context.mounted` before the next use
+   of `setState()`/`context` — do this immediately after the `await`, not
+   wrapped in a broad `try`/`catch`.
+4. Prefer `?.`/`??` over `!`; only use `!` where non-nullability is
+   locally guaranteed and unaffected by any intervening `await`.
+5. Store any credential/token this feature introduces via
+   `flutter_secure_storage`, never `shared_preferences`
+   (`rules/security.mdc`).
+6. Format with `dart format` as you go, not as an afterthought.
+
+### Step 4: Verify
+
+```bash
+flutter analyze
+dart format --set-exit-if-changed .
+flutter test
+```
+
+Run `flutter build <platform> --debug` (or the project's actual CI build
+target) when the change could plausibly affect build output, not routinely
+for every small change. Fix findings at the root cause per
+`rules/coding-style.mdc`/`rules/patterns.mdc`; an `analyze`/build failure
+here is a signal to fix the implementation, not to reach for
+`flutter-build-fix`'s scope unless the failure is purely a
+build/dependency/import problem unrelated to the feature logic.
+
+### Step 5: Report
+
+```
+Implemented: lib/order/order_screen.dart, lib/order/order_controller.dart
+  - New OrderScreen widget consuming OrderController (matches the
+    project's existing Riverpod usage)
+  - context.mounted checked after the two awaited repository calls
+  - flutter analyze / dart format / flutter test all pass
+```
+
+## Rules
+
+- Never use a `BuildContext` or call `setState()` after an `await` without
+  checking `context.mounted`/`mounted` first.
+- Never leave a `TextEditingController`/`AnimationController`/
+  `StreamSubscription`/`FocusNode` undisposed when the `State` that
+  created it is disposed.
+- Never reach for the bang operator (`!`) to silence a null-safety warning
+  without first confirming, and ideally guarding, that the value is
+  actually non-null at that point.
+- Match the project's existing state-management approach; do not
+  introduce a second one alongside it for a single feature.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "The Future usually resolves fast, I don't need a mounted check" | "Usually" is not a guarantee; a user can navigate away or the widget can be disposed for any reason while the await is pending, and the resulting `setState`/context use throws or targets a stale context |
+| "I'll add `!` here since the analyzer is complaining and this will probably not be null" | The analyzer is flagging a real gap it cannot resolve statically; guard with a null check or `?.`/`??` instead of asserting past it |
+| "This TextEditingController only lives for one screen, disposal doesn't matter much" | Every controller not disposed keeps its underlying platform resources alive for the app's lifetime, not just the screen's; dispose it in `dispose()` regardless of how short-lived the screen feels |
+| "I'll just use setState here since Riverpod/Bloc feels like overkill for this one flag" | Introducing a second state-management approach alongside the project's chosen one fragments where state lives and complicates every future feature that needs to read it |
+
+## Verification
+
+Do not report the work done until all of the following hold:
+
+- `flutter analyze` and `dart format --set-exit-if-changed .` both exit 0.
+- `flutter test` passes for any tests the change touches.
+- Every `BuildContext` use and `setState()` call that follows an `await`
+  is preceded by a `context.mounted`/`mounted` check.
+- Every controller/subscription/listener created in `initState()` (or
+  later) is released in `dispose()`.

package/src/gdskills/bundled/stacks/flutter-dart/skills/flutter-implementation/evals.json

@@ -0,0 +1,77 @@
+{
+  "triggers": {
+    "positive": [
+      "Build a screen in this Flutter app that loads orders from a repository and shows a SnackBar when the load finishes",
+      "Add a submit button to this Flutter form that calls an async repository method and updates the UI afterward",
+      "Wire this new Flutter screen up to the app's existing Riverpod providers",
+      "Extend this Flutter widget to show a loading spinner while a Future resolves",
+      "Add a text field with a controller to this Flutter form",
+      "Implement pull-to-refresh on this Flutter list screen backed by an async call",
+      "Add navigation to a detail screen after this Flutter list item is tapped"
+    ],
+    "negative": [
+      "Add a SwiftUI view with @State that loads orders and shows an alert when done",
+      "Add a Jetpack Compose composable that loads orders from a repository and shows a Snackbar",
+      "Implement this feature in a C#/.NET minimal API service that calls a downstream client",
+      "Implement this React component with a form field and a submit handler",
+      "Review this Flutter diff for missing mounted checks",
+      "Fix this failing flutter test in the order package",
+      "Write widget tests for this Flutter screen's loading state"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "buildcontext-mounted-guard",
+      "prompt": "I'm showing a SnackBar with the result after an awaited repository call finishes inside this Flutter button's onPressed handler. What do I need to watch out for?",
+      "strictness": "high",
+      "expected_behavior": [
+        { "grader": "regex", "value": "mounted" },
+        {
+          "grader": "judge",
+          "rubric": "A correct answer explains that after the await, the widget could have been disposed (the user navigated away, the screen was popped) before the callback resumes, so the code must check context.mounted immediately after the await and before using context again (e.g. to show the SnackBar via ScaffoldMessenger.of(context)) -- returning early when it is false, rather than using the context unconditionally or wrapping the use in a try/catch instead of checking mounted.",
+          "pass_criteria": [
+            "States that the widget/BuildContext could be gone (disposed, navigated away from) by the time the awaited call completes, not just that 'something could go wrong'.",
+            "Shows the concrete fix: checking context.mounted right after the await and before the next use of context (e.g. `if (!context.mounted) return;`), not merely naming 'mounted' as a concept.",
+            "Applies the check to the actual use in this prompt -- showing the SnackBar/using ScaffoldMessenger.of(context) after the check, not a generic unrelated example."
+          ],
+          "fail_criteria": [
+            "Recommends using context to show the SnackBar right after the await with no context.mounted (or mounted) check at all.",
+            "Wraps the context use in a try/catch to swallow the error an unmounted context would throw -- whether instead of a context.mounted check or bolted on alongside one as extra insurance -- or claims the check is unnecessary because the await 'usually' resolves quickly. A correct context.mounted check needs no try/catch backstop."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "After that await, the widget this callback belongs to might not be in the tree anymore -- the user could have popped the screen, navigated away, or the whole widget could have been disposed while the repository call was in flight. Using `context` at that point (via `ScaffoldMessenger.of(context)` to show the SnackBar, or any other context-dependent lookup) without checking first can throw or target a context that no longer makes sense. Add `if (!context.mounted) return;` immediately after the `await`, before you touch `context` again -- then the ScaffoldMessenger lookup and `showSnackBar` call that follow are safe. Don't wrap this in a try/catch instead; the point is to avoid using a stale context in the first place, not to recover from the exception it can throw.",
+        "known_wrong": "As long as the repository call succeeds, you can just call `ScaffoldMessenger.of(context).showSnackBar(...)` right after the `await` with the result -- no extra check needed for something like this. If it does occasionally throw because the screen moved on, that's rare enough that you can just wrap the whole thing in a try/catch and swallow the error rather than adding a mounted check before every context use after an await.",
+        "vague": "Just be careful about how you use context after the await finishes and make sure the widget is still around before doing anything with it.",
+        "subtle_wrong": "After the await, check `if (context.mounted)` -- but put the SnackBar call inside a try/catch as well just in case, so even if the mounted check somehow misses a case, the error from an unmounted context gets caught silently instead of crashing the app."
+      }
+    },
+    {
+      "id": "controller-disposal",
+      "prompt": "I'm adding a TextEditingController and an AnimationController to this Flutter form's State, both created in initState. What do I need to do to keep this correct?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer explains that every controller created in initState (the TextEditingController and the AnimationController) must be released in dispose(), calling super.dispose() last rather than first, so the underlying platform resources each controller holds are not leaked for the app's remaining lifetime.",
+          "pass_criteria": [
+            "States that both the TextEditingController and the AnimationController need to be disposed, not just one of them.",
+            "Shows the concrete mechanism: calling `.dispose()` on each controller inside the State's `dispose()` method.",
+            "States that `super.dispose()` should be called last in `dispose()`, after the controllers' own dispose calls, not first."
+          ],
+          "fail_criteria": [
+            "Omits disposing one or both of the controllers, or says disposal is optional/only needed for one of them because the screen is short-lived.",
+            "Recommends calling `super.dispose()` before disposing the controllers, or doesn't address ordering at all despite being asked what to do to keep this correct."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Override `dispose()` on this State and dispose both controllers there: call `_textController.dispose()` and `_animationController.dispose()`, then `super.dispose()` last, after your own cleanup -- not before it. Both controllers hold onto underlying platform/animation-ticker resources for as long as they're alive, so if either one isn't disposed when the State is torn down, that resource keeps existing for the rest of the app's lifetime even though nothing can reach it anymore. This applies to both controllers equally; it's not just the AnimationController (which people remember because of the ticker) or just the TextEditingController (which people forget because it looks like plain data) -- whichever ones this State created in initState, this State's dispose() has to release.",
+        "known_wrong": "For a form like this you really only need to worry about disposing the AnimationController -- that one drives a ticker that keeps running otherwise. The TextEditingController is pretty lightweight so it's fine to just leave it; not disposing it doesn't cause any real problem in practice, and skipping it keeps dispose() simpler.",
+        "vague": "Make sure to clean up the controllers you created so nothing sticks around after the widget goes away.",
+        "subtle_wrong": "Add a dispose() override and call super.dispose() first thing, then dispose both the TextEditingController and the AnimationController right after -- that way the base class cleanup happens before your own, which feels like the safer order to avoid any interference between the two."
+      }
+    }
+  ]
+}

package/src/gdskills/bundled/stacks/flutter-dart/skills/flutter-testing/SKILL.md

@@ -0,0 +1,134 @@
+---
+name: flutter-testing
+description: "Use when a Flutter app's test suite needs writing, extending, or fixing -- widget tests with testWidgets/WidgetTester, mocking the network/repository boundary with mocktail/mockito, and pump vs pumpAndSettle for animation- and async-aware assertions."
+triggers:
+  - "write widget tests for this Flutter screen"
+  - "test this Flutter form's validation logic"
+  - "add tests for this Flutter repository with a mocked HTTP client"
+  - "fix this flaky Flutter widget test"
+  - "test the loading and error states of this Flutter screen"
+  - "add a test that taps this button and checks the result"
+metadata:
+  origin: authored
+  category: test
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# Flutter/Dart testing
+
+Write, extend, or fix a Flutter app's `flutter_test`-based test suite:
+widget tests, boundary mocking, and pump/settle discipline for
+animation- and async-aware assertions. `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. Read `pubspec.yaml`'s `dev_dependencies` for the mocking library in use
+   (`mocktail` or `mockito`) and the Dart/Flutter SDK constraint.
+2. Find the layout: tests under `test/`, mirroring `lib/`. Read 1-2
+   neighboring test files for fixture conventions, how ancestor widgets
+   (`MaterialApp`, providers) are wrapped around the widget under test,
+   and whether golden tests are already in use.
+3. Identify the external boundary the widget/class under test actually
+   depends on (a repository interface, an HTTP client wrapper, a
+   platform-channel wrapper) — this is what gets mocked, not the widget's
+   own internal collaborators.
+
+### Step 2: Plan test cases
+
+**Widgets:** initial render, each distinct visual state (loading / data /
+empty / error), user interaction (`tap`/`enterText`/`drag`) and its
+resulting state change, and any conditional rendering branch.
+
+**Business logic (non-widget classes):** happy path, edge cases (empty/
+null/boundary inputs), error cases from the mocked boundary.
+
+**Async-state widgets:** the loading state immediately after
+`pumpWidget()`, then the resolved state after the mocked `Future`/
+`Stream` completes and a further `pump()`/`pumpAndSettle()`.
+
+### Step 3: Write
+
+1. Define an abstract interface for the external boundary if the codebase
+   does not already have one (a `OrderRepository` abstract class an
+   `HttpOrderRepository` implements) — this is what makes the boundary
+   mockable without touching the widget's own internals.
+2. Build the mock with `mocktail`'s `class MockOrderRepository extends
+   Mock implements OrderRepository {}` (no codegen) or `mockito`'s
+   `@GenerateMocks`/`@GenerateNiceMocks` (codegen), matching whichever the
+   project already uses; stub calls with `when(...).thenAnswer(...)`
+   (mocktail) or `when(...).thenReturn/thenAnswer` (mockito).
+3. Wrap the widget under test in whatever ancestors it actually needs
+   (`MaterialApp`, a provider scope) via `tester.pumpWidget(...)`, with the
+   mocked boundary injected the same way the real app injects the real
+   implementation (constructor parameter, provider override).
+4. Locate elements with `find.text`/`find.byType`/`find.byKey`; drive
+   interactions with `tester.tap`/`tester.enterText`/`tester.drag`.
+5. Use `tester.pump()` for a single frame/animation step and
+   `tester.pumpAndSettle()` once an animation, transition, or async
+   operation should be fully finished before asserting — never a real-time
+   `Future.delayed` wait; control the mocked `Future`/`Stream` directly.
+6. Assert with `expect(find.text('...'), findsOneWidget)` /
+   `findsNothing` / `findsNWidgets(n)`, and verify only the boundary
+   interactions that matter to the behavior under test
+   (`verify(() => mockRepository.fetchOrders()).called(1)`).
+
+### Step 4: Run and fix
+
+```bash
+flutter test
+```
+
+Fix a failing test (max 3 iterations) by correcting the test or its
+fixtures — not the widget/class under test — unless the test has
+correctly caught a real bug, in which case say so in the report rather
+than silently changing the implementation.
+
+### Step 5: Report
+
+```
+Generated: test/order/order_screen_test.dart
+  - 5 widget tests (loading/data/error/tap/empty), mocking
+    OrderRepository with mocktail
+  - flutter test passes
+```
+
+## Rules
+
+- Mock the external boundary (repository/HTTP client/platform channel)
+  behind an interface — never a widget's or class's own internal
+  collaborators.
+- Never use `Future.delayed`/a real time wait to give a mocked async call
+  time to resolve; drive it with a controlled mock and `pump()`/
+  `pumpAndSettle()`.
+- Reach for `pumpAndSettle()` only when the pending animation/async work
+  actually settles; use a bounded `pump(duration)` for anything driven by
+  a repeating timer or an animation that never stops on its own.
+- NEVER modify the widget/class under test to make a test pass — only test
+  files and test fixtures, unless the test caught a real bug (say so).
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "I'll mock the private `_formatOrder` helper this widget calls internally" | That is an internal collaborator, not the external boundary; mocking it tests that the widget calls its own helper a particular way, not that it produces correct behavior, and breaks on every internal refactor |
+| "pumpAndSettle() times out, I'll just add a fixed pump(Duration(seconds: 2)) and move on" | A `pumpAndSettle()` timeout usually means something under test never stops animating (a repeating timer); reach for a bounded `pump(duration)` sized to the actual transition instead of guessing a delay that papers over the real cause |
+| "I'll await Future.delayed(Duration(milliseconds: 500)) so the mocked repository call has time to resolve" | A mocked `Future` resolves whenever the test tells it to, not on a wall-clock delay; control the mock directly (or use `pump()`) so the test doesn't depend on timing |
+| "A boolean 'did it show an error' check is enough for the error state test" | Assert the actual rendered error content (`find.text('Failed to load orders')`), not just that some error branch was hit, so a wrong error message still fails the test |
+
+## Verification
+
+Do not report the work done until all of the following hold:
+
+- The test file sits at the project's own convention path, mirroring
+  `lib/`.
+- `flutter test` exits 0 with every generated/modified test passing.
+- Every mock targets an external boundary interface, not an internal
+  collaborator of the widget/class under test.
+- No widget/class file under test was modified, unless the report
+  explicitly states the test caught a real bug and names the fix.