@mrciphersmith/keryx 0.2.164 → 0.3.1

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

@@ -0,0 +1,83 @@
+{
+  "triggers": {
+    "positive": [
+      "Write a React Testing Library test for this UserCard component's loading, success, and error states",
+      "Test this custom hook with renderHook",
+      "This component test throws an act warning, help me fix it",
+      "Add an MSW request handler to mock the API call in this React component test",
+      "Add tests for the form's validation error and successful submit states",
+      "Write a user-event test that clicks the button and checks the modal opens"
+    ],
+    "negative": [
+      "Write pytest tests for this FastAPI endpoint",
+      "Build a new SearchBar React component with a debounced input",
+      "Review this component diff for accessibility issues",
+      "Set up Playwright end-to-end tests for the checkout flow",
+      "Fix the failing tsc type-check in this component after the react types upgrade",
+      "Write unit tests for this plain TypeScript date-formatting utility function"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "query-by-role",
+      "prompt": "I need a React Testing Library test that clicks the submit button on a login form and checks an error message appears when the password is empty. How should I query for the button and the error?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer queries the submit button and error message the way a user or assistive technology would — role/label/text-based queries such as getByRole for the button and findByText/getByText for the error — rather than defaulting to data-testid, and drives the click through @testing-library/user-event rather than fireEvent.",
+          "pass_criteria": [
+            "Shows or names the concrete accessible query for the submit button, such as `getByRole('button', { name: ... })`, not data-testid, as the primary approach.",
+            "Shows or names the concrete accessible query for the error message (`getByText`/`findByText`/`getByRole('alert', ...)`), not data-testid.",
+            "Shows the click driven through `@testing-library/user-event` (`userEvent.setup()` then `.click`), not `fireEvent`."
+          ],
+          "fail_criteria": [
+            "Recommends data-testid as the default/primary way to find the button or the error message when an accessible query would work.",
+            "Uses fireEvent.click (or another fireEvent call) as the interaction mechanism instead of userEvent."
+          ]
+        },
+        {
+          "grader": "regex",
+          "value": "(get|find|query)(All)?ByRole"
+        }
+      ],
+      "calibration": {
+        "known_right": "Query the submit button with `screen.getByRole('button', { name: /submit|log in/i })` — that's how a user or screen reader identifies it, by its accessible role and visible label, not by an internal test id. Drive the click with user-event rather than fireEvent: `const user = userEvent.setup(); await user.click(screen.getByRole('button', { name: /submit/i }));`. For the error message, since it appears asynchronously after the click triggers validation, use `await screen.findByText(/password is required/i)` (or `findByRole('alert', ...)` if the error is rendered with an alert role) rather than a synchronous `getByText`, since `findBy*` retries until the DOM updates. Putting it together:\n```tsx\nconst user = userEvent.setup();\nrender(<LoginForm />);\nawait user.click(screen.getByRole('button', { name: /submit/i }));\nexpect(await screen.findByText(/password is required/i)).toBeInTheDocument();\n```\nOnly fall back to `data-testid` if the button or error text genuinely has no accessible role/label/text to query by.",
+        "known_wrong": "Easiest way: give the button and the error message their own test ids in the markup — `data-testid=\"submit-btn\"` and `data-testid=\"password-error\"` — then in the test do `fireEvent.click(screen.getByTestId('submit-btn'))` and assert with `expect(screen.getByTestId('password-error')).toBeInTheDocument()`. Test ids are reliable because they don't break when you change button text or styling later, and fireEvent.click is simpler than setting up user-event since it doesn't need the extra `userEvent.setup()` call.",
+        "vague": "Query for the button and the error message the way an assistive-technology user would, using accessible role- or text-based queries instead of test ids, and drive the click through the user-event library rather than firing raw DOM events.",
+        "subtle_wrong": "Find the button by its role and label, and drive the click with user-event — that part's straightforward. For the error message, since it's simplest, just add a `data-testid=\"password-error\"` to that element and query it that way after the click — the error text itself is inside a styled component that doesn't have stable visible copy yet, so a testid is the pragmatic choice there until the copy is finalized; getting the button query right is the part that really matters for this test."
+      },
+      "anti_patterns": [
+        "fireEvent",
+        "data-testid"
+      ]
+    },
+    {
+      "id": "mock-network-boundary",
+      "prompt": "My component test needs to mock an API call that the component makes on mount. Where should I put the mock?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer mocks the network call at the request boundary (an MSW handler intercepting the actual HTTP request, or the project's existing equivalent), not by mocking the component's own data-fetching function/module directly, because a boundary mock still exercises the real fetch/parse/error-handling code path.",
+          "pass_criteria": [
+            "Names the concrete boundary mechanism (an MSW request handler for the actual HTTP endpoint, e.g. `http.get('/api/...', ...)`, or the project's existing equivalent boundary mock), not just 'mock at the boundary' in the abstract.",
+            "Explains or implies that mocking at the boundary keeps the real request/parse/error-handling path under test, rather than bypassing it."
+          ],
+          "fail_criteria": [
+            "Recommends mocking the component's own data-fetching function, fetch helper, or API client method directly (e.g. `vi.mock`/`jest.mock` on the fetch module) instead of the network boundary, even if only offered as a quicker alternative alongside the boundary approach."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Mock it at the network boundary, not inside the component. If the project already uses MSW, add a request handler for the actual endpoint the component calls on mount (e.g. `http.get('/api/user/:id', () => HttpResponse.json({ name: 'Ada' }))`) and let the component's real fetch call run against that intercepted request. That way the test still exercises the component's actual fetch call, response parsing, and error handling — you're only replacing what's on the other end of the network, not the code that talks to it. Then in the test, render the component and use `findBy*`/`waitFor` to wait for the state that appears once the mocked response resolves, since the fetch happens asynchronously after mount. If the project doesn't have MSW set up yet, use whatever boundary-level mock it already has (a fetch/axios interceptor) rather than reaching into the component's data-fetching function and swapping it out — that would skip real parsing/error-handling logic the test should also be covering.",
+        "known_wrong": "Simplest approach: just mock the component's fetch helper directly. If the component imports something like `fetchUser` from an api module, do `vi.mock('../api/fetchUser')` (or jest.mock) and have it resolve with your test data. That way you skip dealing with MSW handlers or intercepting real requests — you control exactly what the function returns, and the test runs faster since there's no simulated network layer involved at all.",
+        "vague": "Mock it at the network boundary rather than inside the component, so the real fetch and parsing logic still runs.",
+        "subtle_wrong": "Set up an MSW handler for the endpoint as the primary approach — that's the right general direction. For this particular test though, since the component's fetch call is wrapped in a small `fetchUser` helper that's already unit-tested elsewhere, you can save setup time by mocking that helper directly with `vi.mock('../api/fetchUser')` instead of standing up a full MSW handler; it resolves the same test data without needing to configure the request interception for this one case."
+      },
+      "anti_patterns": [
+        "fetch helper"
+      ]
+    }
+  ]
+}

package/src/gdskills/bundled/stacks/react/skills/react-upgrade-migration/SKILL.md

@@ -0,0 +1,155 @@
+---
+name: react-upgrade-migration
+description: "Use when upgrading a codebase across React major versions (e.g. 18 to 19) -- removing legacy APIs (string refs, legacy context, propTypes/defaultProps on function components, ReactDOM.render/hydrate), applying official codemods, updating the @types/react package, fixing the act import, and staging the rollout."
+triggers:
+  - "upgrade this project to react 19"
+  - "migrate off ReactDOM.render"
+  - "remove string refs"
+  - "fix propTypes deprecation warning"
+  - "run the react codemod"
+  - "update @types/react for the new major"
+metadata:
+  origin: authored
+  category: migrate
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# React upgrade / migration
+
+Move a codebase from one React major to a newer one (most commonly 18 to
+19), removing APIs the new major dropped and adopting its replacements.
+Scoped to the React library/types/runtime upgrade itself — a related
+bundler or framework major upgrade (Next.js, Vite) that happens alongside
+it is out of scope unless the failure is caused by a React API removal.
+
+## Workflow
+
+### Step 1: Establish the starting point and target
+
+1. Read the current `react`/`react-dom`/`@types/react`/`@types/react-dom`
+   versions from `package.json` and the target major from the user's
+   request.
+2. Read the official React upgrade guide for that version range (the
+   project's own `CHANGELOG`/release notes if vendored, otherwise the
+   canonical upgrade guide) before touching code — do not rely on memory
+   of a prior major's migration for a different jump.
+3. Inventory usage of the APIs the target major removes or changes (grep
+   the codebase; see Step 2 per-API list) so the scope of the change is
+   known before starting, not discovered file-by-file.
+
+### Step 2: Remove/replace legacy APIs (18 -> 19 checklist)
+
+- **String refs** (`ref="myRef"`): replace with `useRef`/`createRef` (or
+  the React 19 ref-as-prop pattern for a component receiving a ref from
+  its parent). String refs are removed, not deprecated-but-working.
+- **Legacy context** (`contextTypes`/`getChildContext`): replace with
+  `createContext`/`useContext`. Legacy context is removed.
+- **`propTypes`/`defaultProps` on function components**: `propTypes` no
+  longer has any effect at runtime in React 19+; if the project relies on
+  it for runtime validation, replace the validation with TypeScript types
+  (preferred, if the project is TS) or an explicit runtime check. Replace
+  `defaultProps` with a default parameter value in the function signature
+  (`function C({ x = 1 }: Props)`), since function-component
+  `defaultProps` is removed.
+- **`ReactDOM.render`/`ReactDOM.hydrate`**: replace with
+  `createRoot(container).render(...)` and `hydrateRoot(container,
+  ...)` respectively from `react-dom/client`. Update the app's entry
+  point; this is usually a single-file change but touches every test
+  helper that also bootstraps a root.
+- **`react-dom/test-utils`' `act`**: import `act` from `react` (or
+  `react-dom/test-utils`'s deprecated re-export, if the project pins an
+  older React Testing Library that still expects it) — check the
+  project's RTL version compatibility before changing the import broadly.
+- **Any other removed API the upgrade guide lists for this specific
+  version jump** (e.g. `ReactDOM.unmountComponentAtNode` and
+  `ReactDOM.findDOMNode`, both fully removed in React 19, not merely
+  deprecated) — do not assume the 18->19 list above is exhaustive for a
+  different version range.
+
+### Step 3: Apply codemods, then hand-fix the rest
+
+1. Run the official `react-codemod`/`types-react-codemod` transforms
+   applicable to the identified APIs (e.g. the ref-as-prop and
+   `StrictMode`-related codemods) rather than hand-editing every call
+   site — codemods cover the mechanical rewrite; review their diff before
+   committing.
+2. Hand-fix what the codemod cannot express (usually the `propTypes` ->
+   TypeScript-type conversion and any app-specific wrapper around
+   `ReactDOM.render`).
+3. Update `@types/react`/`@types/react-dom` to the versions matching the
+   new React major; a mismatched types package produces type errors
+   unrelated to the actual runtime migration — resolve that first before
+   chasing other type errors.
+
+### Step 4: Stage the rollout
+
+- The React/react-dom version bump itself is one atomic dependency change
+  — `package.json` cannot pin two React majors for different directories
+  at once, so there is no per-directory rollout of the runtime version.
+  What can be sliced by directory/feature is the code-preparation work
+  that precedes the bump: removing legacy APIs, running codemods, and
+  fixing type errors slice-by-slice with each slice green (type-check,
+  lint, test, build) — so that when the dependency bump itself lands, the
+  whole tree is already compatible and the bump is a single, low-risk
+  commit rather than a large flip that leaves the tree red.
+- Keep the previous major's peer dependencies (libraries pinned to the old
+  React major) identified before starting — a library incompatible with
+  the new major blocks the upgrade at that dependency, not in app code;
+  surface this as a blocker rather than working around it with a version
+  override that silences a real incompatibility.
+
+### Step 5: Verify and report
+
+```bash
+keryx test run --changed --strict
+```
+
+Then the full chain: type-check, lint (with `react-hooks` plugin), test,
+build — per `agentProfile.buildCommands`.
+
+```
+Migrated: react 18.3 -> 19.0
+  - ReactDOM.render -> createRoot in src/main.tsx
+  - removed propTypes from 4 components, added TS prop types
+  - ran react19-ref-as-prop codemod across src/components (12 files)
+  - @types/react bumped to ^19.0.0
+  - full build chain green
+```
+
+## Rules
+
+- ALWAYS read the target version's own upgrade guide before starting —
+  do not assume a prior migration's checklist applies unchanged to a
+  different version jump.
+- ALWAYS run an official codemod for a mechanical rewrite it covers before
+  hand-editing the same pattern across many files.
+- NEVER leave a mix of the old and new API for the same concern in the
+  same file (e.g. `ReactDOM.render` in one entry point,
+  `createRoot` in another) without flagging it as an inconsistency.
+- NEVER silence a genuine peer-dependency incompatibility with a version
+  override/resolution — report it as a blocker.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "I remember how the last major migration went, I'll skip re-reading the guide" | Removed/changed APIs differ per version jump; acting on a stale mental model misses this version's actual list |
+| "I'll hand-edit all 40 call sites instead of running the codemod" | Slower and more error-prone than the maintained codemod for a mechanical rewrite; run the codemod, then hand-fix only what it cannot express |
+| "This library isn't compatible with the new major yet, I'll force the version with a resolution override" | Hides a real incompatibility that will surface as a runtime bug instead of a clear install-time blocker; report it and let the author decide (wait, replace the library, or patch) |
+| "I'll migrate everything in one big commit, staging slices takes too long" | A single large flip leaves no bisectable, independently-verifiable checkpoint if something breaks partway through a large codebase |
+
+## Verification
+
+Do not report the work done until all of the following hold:
+
+- Every API on this skill's removed-API checklist that the inventory
+  (Step 1) found is either migrated or explicitly listed as out of scope
+  with a reason.
+- No file mixes the old and new form of the same migrated API.
+- `@types/react`/`@types/react-dom` versions match the target React major.
+- The full build chain (type-check, lint, test, build) is green after the
+  migration.
+- `git status`/the diff reflects only the migration's intended scope —
+  no unrelated refactor bundled in.

package/src/gdskills/bundled/stacks/react/skills/react-upgrade-migration/evals.json

@@ -0,0 +1,74 @@
+{
+  "triggers": {
+    "positive": [
+      "Upgrade this codebase from React 18 to React 19",
+      "Remove all string refs from this project before the React upgrade",
+      "Migrate ReactDOM.render to createRoot across the app",
+      "Fix the propTypes deprecation warnings after upgrading React",
+      "Run the official React codemods for the ref-as-prop change",
+      "Update @types/react to match the new React major we just installed"
+    ],
+    "negative": [
+      "Add a settings page that lets a user update their email address",
+      "Write unit tests for this date-formatting utility function",
+      "Review this component diff for accessibility",
+      "The build is failing with a plain TSX syntax error, unrelated to any version upgrade",
+      "Bump the pinned Node.js version in package.json engines and the CI workflow",
+      "Fix a re-render performance issue in this list component"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "read-guide-first",
+      "prompt": "We're upgrading from React 18 to React 19. Where should I start?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer starts by reading the official React upgrade guide/release notes for this specific 18-to-19 jump before touching code, rather than relying on memory of a prior migration, and mentions inventorying the removed/changed APIs and running the official codemods as part of the process rather than hand-editing everything from scratch.",
+          "pass_criteria": [
+            "Names reading the official React 19 upgrade guide/release notes as the concrete first step for this specific version jump, before any code change — not just 'research first' in the abstract.",
+            "Names a concrete mechanism for the mechanical part of the migration: inventorying removed/changed APIs and/or running the official codemods, not just 'update the code carefully'."
+          ],
+          "fail_criteria": [
+            "Recommends starting by just bumping the react/react-dom version and fixing whatever breaks, without first reading the upgrade guide for this specific version jump.",
+            "Relies on memory of a previous major-version migration instead of checking the current guide/release notes."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Start by reading the official React 19 upgrade guide and release notes — don't rely on how the 17-to-18 jump went, since the set of removed/changed APIs is specific to this version range. From the guide, build an inventory of what this codebase actually uses that's affected: string refs, legacy context (contextTypes/getChildContext), propTypes/defaultProps on function components, ReactDOM.render/hydrate, and the react-dom/test-utils act import, plus anything else the guide calls out as removed rather than merely deprecated (ReactDOM.findDOMNode and unmountComponentAtNode, for instance). Once you know the scope, run the official react-codemod/types-react-codemod transforms for the mechanical parts (the ref-as-prop change in particular has good codemod coverage) and review their diffs before committing, then hand-fix what the codemods can't express — mainly propTypes-to-TypeScript conversions and any custom ReactDOM.render wrapper. Update @types/react/@types/react-dom to match the target major early, since a types/runtime mismatch produces confusing unrelated errors. Only bump the actual react/react-dom dependency once the codebase is already compatible, so the version bump itself is a small, low-risk commit.",
+        "known_wrong": "Easiest way to start: just bump react and react-dom to 19 in package.json, run `npm install`, and then run the type-check/build/test suite to see what breaks. Fix the errors as they come up one by one — that's basically what we did for the 17-to-18 upgrade and it worked fine, so the process should be similar this time. No need to read through the whole upgrade guide up front; the compiler and test failures will tell you everything you actually need to fix.",
+        "vague": "Start by reading up on what's changed in React 19 before making any changes, then work through the codebase fixing what needs fixing.",
+        "subtle_wrong": "Skim the React 19 release notes for the headline breaking changes so you have a general sense of scope, then just bump react/react-dom in package.json and run the build/type-check/test suite to see what actually breaks in this codebase — that's usually faster than working through the full guide line by line, since most projects only hit two or three of the listed changes in practice, and the compiler will point you at the rest."
+      }
+    },
+    {
+      "id": "no-forced-resolution",
+      "prompt": "One of our dependencies isn't compatible with React 19 yet. Should I just force the version with a package.json resolution override so the install succeeds?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer says no — forcing the incompatible dependency's peer-dependency requirement with a version override/resolution hides a genuine incompatibility instead of fixing it. It recommends treating the incompatibility as a blocker to report, with real options such as waiting for the library to add support, replacing it, or patching it, rather than silently forcing the install.",
+          "pass_criteria": [
+            "States plainly that forcing/overriding the peer-dependency version (a package.json resolution override) is not the right fix here.",
+            "Names at least one concrete alternative action (wait for the library to add React 19 support, replace the dependency, or patch it via patch-package) instead of only saying 'report it as a blocker'."
+          ],
+          "fail_criteria": [
+            "Recommends forcing the dependency's version via a resolution override in package.json as the fix to make the install succeed, including as a stopgap suggested alongside the real fix."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "No, don't force it with a resolution override. That would silence a genuine peer-dependency incompatibility — the library may not actually work correctly against React 19's runtime behavior even if npm/yarn stops complaining about the version mismatch, and the failure would surface later as a confusing runtime bug instead of a clear install-time blocker you can act on now. Instead, treat this as a real blocker: check the library's repo/changelog for an open issue or in-progress React 19 support, and if there's a beta/RC release that adds it, that's the real fix. If there's no timeline, your options are to wait and keep the upgrade staged behind this one dependency, replace it with an alternative that already supports React 19, or (if it's small enough and you're willing to maintain it) patch the library yourself via patch-package rather than lying to the package manager about compatibility. Report which of these you're choosing and why, rather than quietly forcing the version.",
+        "known_wrong": "Yeah, just force the version with a resolution override in the `resolutions`/`overrides` field of package.json — most of these compatibility warnings are overly conservative peer-dependency ranges that the library maintainers just haven't bumped yet, and the actual code usually still works fine. That gets the install passing again without blocking the rest of the upgrade, and you can always revisit it later if something actually breaks at runtime.",
+        "vague": "I wouldn't force it with an override — better to treat the incompatibility as a real blocker and look into your options before working around it.",
+        "subtle_wrong": "Don't leave a blanket override in place long-term, but it's reasonable to add a scoped resolution override just for this one package as a temporary unblock so the rest of the team isn't stuck on the upgrade while you sort out a real fix — track it with a follow-up ticket to remove the override once the library ships proper React 19 support, and in the meantime keep an eye on whether anything actually breaks at runtime."
+      },
+      "anti_patterns": [
+        "resolution override"
+      ]
+    }
+  ]
+}

package/src/gdskills/bundled/stacks/ts-js-node/agent-refs.json

@@ -0,0 +1,4 @@
+{
+  "agents": [],
+  "note": "pair removed — flow 317, trials=10 honest gate run: ts-js-node/nodejs-build-fix no-ts-ignore-suppression passRate 0.6 < 0.8 (was 4/5=0.8 at trials=5, the fragility flow 316 review round 1 (R1-14) predicted). Recorded trials named the right direction but never showed the corrected declaration/access code in 4 of 10 answers. deepseek-chat runner+judge gate run, flow 317."
+}