@mrciphersmith/keryx 0.3.0 → 0.3.2

package/src/gdskills/bundled/stacks/nextjs-nuxt/skills/nextjs-nuxt-code-review/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: nextjs-nuxt-code-review
+description: "Use when reviewing a diff that touches Next.js App Router files ('use client'/'use server' directives, Route Handlers, revalidatePath/revalidateTag) or Nuxt files (composables, server/api routes, nuxt.config.ts routeRules/runtimeConfig) for meta-framework-specific risk: a misplaced Server/Client boundary, a composable called outside setup context, a hydration-mismatch-prone render, a rendering-mode choice that doesn't match the data's actual freshness need, or an unauthenticated Server Action/server route. Does not edit code. Not for general React/Vue component review with no App Router/Nuxt-specific concern (use review-frontend or a react/vue pack review skill), and not for NestJS backend review (use review-backend)."
+triggers:
+  - "review this Next.js server action for auth issues"
+  - "check this diff for use client boundary mistakes"
+  - "review this Nuxt server/api route"
+  - "does this Nuxt composable get called outside setup"
+  - "review the rendering mode choice on this Next.js route"
+  - "check for hydration mismatch risk in this component"
+  - "review this nuxt.config routeRules change"
+metadata:
+  origin: authored
+  category: review
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# Next.js / Nuxt code review
+
+Review a diff touching Next.js App Router or Nuxt files for
+meta-framework-specific risk. This skill reviews and reports; it does not
+edit code. See `rules/patterns.mdc` and `rules/security.mdc` for the full
+rationale behind each check below.
+
+## Workflow
+
+### Step 1: Scope the diff by framework
+
+- Identify which files are Next.js (`app/**`, `'use client'`/`'use
+  server'` directives, `route.ts` handlers) vs. Nuxt (`pages/**`,
+  `composables/**`, `server/api/**`, `nuxt.config.ts`) — apply the
+  matching checklist below to each; a monorepo diff may need both.
+
+### Step 2: Check the Server/Client boundary (Next.js)
+
+- Every `'use client'` is on the smallest component that actually needs
+  browser state, an event handler, or a browser API — not on a shared
+  layout, a page, or an ancestor of the component that needs it.
+- No Server Component reads `cookies()`/`headers()` and then passes the
+  raw session/auth data down as a prop to a Client Component
+  unnecessarily — pass only what the client actually needs to render.
+- No server-only import (a DB client, an API key read, a `'use server'`
+  file) is reachable from a file that lacks its own server boundary and
+  could end up in a Client Component's import chain.
+
+### Step 3: Check composable/context usage (Nuxt)
+
+- Every composable (`useX`) call sits at the synchronous top level of
+  `<script setup>`, a plugin, or middleware — not inside an `async`
+  callback, after an `await`, or inside `setTimeout`/an event handler
+  where Nuxt's injection context is no longer available the same way.
+- `runtimeConfig` secrets stay out of the `public` block; a component
+  never reads a value from `public` that should have been server-only.
+
+### Step 4: Check rendering-mode and data-freshness fit
+
+- A route/page marked static or ISR (Next's `revalidate`, Nuxt's
+  `prerender`/`isr` routeRule) doesn't actually need per-request data
+  (auth-gated content, a `searchParams`-dependent result) — that
+  combination silently serves stale or wrong data to different users.
+- A mutation (Server Action, Nuxt server route) that changes displayed
+  data calls `revalidatePath()`/`revalidateTag()` (Next.js) or otherwise
+  invalidates the relevant cached data (Nuxt) — a missing revalidate
+  leaves the UI showing stale data after a successful write.
+
+### Step 5: Check hydration-mismatch risk
+
+- No component renders `Date.now()`, `Math.random()`, or
+  locale/timezone-dependent formatting directly in its render path
+  without a client-only guard or a stable server-computed value — flag it
+  even if the diff's own tests pass, since a mismatch often only shows up
+  as a console warning in a real browser, not in a unit test.
+
+### Step 6: Check Server Action / server route auth
+
+- Every `'use server'` action and `server/api/**` handler checks
+  auth/authorization and re-validates its own input inside the
+  action/handler — not only relying on a middleware check or the
+  client-side form validation that called it. See `rules/security.mdc`.
+
+### Step 7: Report
+
+List each finding with file:line, what's wrong, and the concrete fix
+(quote `rules/patterns.mdc`/`rules/security.mdc` by name where relevant).
+Do not modify the code under review.
+
+## Rules
+
+- This is a review skill: report findings, do not edit the reviewed
+  files.
+- Follow `rules/patterns.mdc` for boundary/rendering-mode/data-fetching
+  checks and `rules/security.mdc` for auth/env-var checks.
+- Flag a missing auth check on a Server Action/server route as a
+  correctness-blocking finding, not a style nit.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "'use client' is on the page, but that's fine, it's simpler to review as one unit" | A page-level 'use client' ships the whole subtree to the browser; it is exactly the finding this review exists to catch, not something to wave through for simplicity |
+| "The server action's caller already validates the form, so the handler check can be skipped in review" | The handler is a directly reachable endpoint regardless of what called it; flag the missing server-side check |
+| "The composable is called inside onMounted, that still runs after setup so it's probably fine" | onMounted callbacks run after Nuxt's synchronous setup-time context resolution window for some composable patterns; flag it for verification rather than assuming it's safe |
+| "Date.now() in the render is just a display nicety, not worth flagging" | It is a concrete hydration-mismatch source (server render time vs. client render time differ); flag it regardless of how minor the visual impact looks |
+
+## Verification
+
+Before finishing the review, confirm:
+
+- Every `'use client'`/`'use server'` directive in the diff was checked
+  against its actual placement, not assumed correct.
+- Every new/changed Nuxt composable call site was checked for
+  synchronous setup-context placement.
+- Every new/changed Server Action or `server/api/**` handler was checked
+  for its own auth/validation, independent of client-side checks.
+- The report names file:line for each finding and the concrete fix, not
+  just "check the boundary here".

package/src/gdskills/bundled/stacks/nextjs-nuxt/skills/nextjs-nuxt-code-review/evals.json

@@ -0,0 +1,76 @@
+{
+  "triggers": {
+    "positive": [
+      "Review this Next.js server action diff for missing auth checks before it merges",
+      "In the app router pages touched by this diff, can you check for any 'use client' boundary mistakes?",
+      "There's a new server/api/orders.ts route in this Nuxt app that needs review, can you check it for security issues?",
+      "One of the reviewers on my team flagged that a composable in this PR might be running too late in the component lifecycle -- can you take a look and confirm whether that's a real problem?",
+      "This product page is marked for static generation, but the data behind it changes every few minutes -- before I approve this PR, can you sanity-check that the caching story here actually makes sense?",
+      "Before this ships, can you check whether this component carries any hydration mismatch risk given how it renders?",
+      "Someone on the team tweaked the SPA-only flag for one of our nuxt.config.ts routes and opened a PR -- can you sanity-check the change before I approve it?"
+    ],
+    "negative": [
+      "Implement a new Next.js server action for creating an order",
+      "Write a test for this Nuxt composable that calls useAsyncData",
+      "Fix this nuxi typecheck failure on an auto-imported composable",
+      "Migrate this Next.js pages router app to the app router",
+      "Review this plain React component for accessibility issues, no App Router concern",
+      "Review this Python data pipeline function for missing exception handling"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "flag-missing-server-action-auth",
+      "prompt": "Here's a Next.js server action: it's marked 'use server', takes an orderId and a new status, and calls db.order.update({ where: { id: orderId }, data: { status } }) with no other logic. What should this review flag?",
+      "strictness": "high",
+      "expected_behavior": [
+        { "grader": "regex", "value": "auth" },
+        {
+          "grader": "judge",
+          "rubric": "A correct review flags that the server action has no authentication/authorization check before performing the database write, explaining that a Server Action is a directly reachable endpoint and must check the caller's identity and permission on that specific order, not rely on the calling UI having already checked.",
+          "pass_criteria": [
+            "Explicitly flags the missing auth/authorization check as the finding, not a minor style note",
+            "States that a Server Action is directly callable/reachable regardless of which UI called it, so it must check auth itself",
+            "Names what the fix should verify: the caller is authenticated and is authorized to modify this specific order (not just any orderId)"
+          ],
+          "fail_criteria": [
+            "Concludes the code is fine as-is because the form/UI that calls it already checks permissions -- mentioning that this is not sufficient is not itself a failure"
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "This is missing an auth check and should not merge as-is. A 'use server' action is a directly reachable server endpoint -- anyone who can trigger a POST to it (not just users going through your UI) can call updateOrderStatus(orderId, status) with an arbitrary orderId. Before the db.order.update call, it needs to: get the current session/user, reject if there's no authenticated session, and confirm that user is actually authorized to modify the specific order identified by orderId (e.g. owns it, or has an admin role) -- not just that they're logged in. Right now nothing stops any authenticated (or even unauthenticated, depending on how it's wired) caller from updating any order's status.",
+        "known_wrong": "This looks fine -- the button that calls this action only shows up on the order owner's own order page, so by the time this action runs we already know it's the right user.",
+        "vague": "This action should probably have some kind of permission check before it modifies data.",
+        "subtle_wrong": "This needs an auth check, good catch -- I'd add a check that `session` exists and reject if not. That covers making sure the caller is logged in before the update runs, which is the main gap here."
+      },
+      "anti_patterns": []
+    },
+    {
+      "id": "flag-page-level-use-client",
+      "prompt": "This Next.js diff adds 'use client' at the top of app/dashboard/page.tsx because one small stat card in the middle of the page needs a hover tooltip with local state. Everything else on the page is static server-rendered content. What should the review say?",
+      "strictness": "high",
+      "expected_behavior": [
+        { "grader": "regex", "value": "'use client'" },
+        {
+          "grader": "judge",
+          "rubric": "A correct review flags that 'use client' on the whole page is too broad, and recommends extracting the stat card (or just its tooltip) into its own small client component, keeping the rest of the page as a Server Component.",
+          "pass_criteria": [
+            "States that putting 'use client' on the whole page.tsx is too broad given only one small element needs it",
+            "Recommends extracting the stat card/tooltip into its own separate component file marked 'use client', while the page itself stays a Server Component"
+          ],
+          "fail_criteria": [
+            "Approves the page-level 'use client' as fine because it's simpler than splitting into two files -- mentioning that tradeoff only to reject it is not a failure"
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "This is too broad -- putting 'use client' on the whole page.tsx ships the entire dashboard's JS to the browser and turns every other static element on the page into client-rendered content, purely for one stat card's hover tooltip. Instead, extract that stat card (or just the tooltip part of it) into its own component file, e.g. StatCardWithTooltip.tsx, and put 'use client' at the top of that file only. Keep app/dashboard/page.tsx itself with no directive so it stays a Server Component and the rest of the dashboard keeps being server-rendered. Pass whatever data the card needs down to it as props from the page.",
+        "known_wrong": "It's fine -- 'use client' on the whole page is simpler than splitting components apart, and the performance difference for one dashboard page probably doesn't matter much.",
+        "vague": "It might be better to scope the client directive more narrowly instead of putting it on the whole page.",
+        "subtle_wrong": "Agreed this should be narrowed -- I'd move 'use client' from page.tsx down to just wrapping the dashboard's main content section as its own client component, so it's not the very top-level page file anymore. That's still a lot of the page's content inside one client component, but it's an improvement over the top-level directive."
+      },
+      "anti_patterns": []
+    }
+  ]
+}

package/src/gdskills/bundled/stacks/nextjs-nuxt/skills/nextjs-nuxt-implementation/SKILL.md

@@ -0,0 +1,135 @@
+---
+name: nextjs-nuxt-implementation
+description: "Use when implementing a new page, route, or data-fetching feature in a Next.js App Router or Nuxt 3+ project: choosing Server vs. Client Components ('use client' placement), a Nuxt composable/page fetching data with useFetch/useAsyncData, a Server Action ('use server') or Nuxt server/api route, or a route's rendering mode (static/ISR/revalidate vs. Nuxt's ssr/routeRules). Not for plain React component logic with no meta-framework routing/data concern (use react-implementation), plain Vue SFC logic outside Nuxt's routing/server layer (use vue-implementation), or fixing an existing build/type error (use nextjs-nuxt-build-fix)."
+triggers:
+  - "add a new page to this Next.js app router project"
+  - "should this be a server component or a client component"
+  - "fetch this data with useFetch in my Nuxt page"
+  - "write a Next.js server action for this form"
+  - "add a Nuxt server API route under server/api"
+  - "set up ISR revalidation for this Next.js route"
+  - "this Nuxt composable needs to hit the API on page load"
+  - "configure routeRules for this Nuxt route to prerender it"
+metadata:
+  origin: authored
+  category: implement
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# Next.js / Nuxt implementation
+
+Implement a new page, route, or data-fetching feature in a Next.js App
+Router or Nuxt 3+ project. Covers both frameworks: use the Next.js
+sections for `app/`-directory work, the Nuxt sections for `pages/`/
+`server/` work, and the shared sections for the routing/rendering/
+data-fetching decisions that apply to either. See `rules/patterns.mdc` for
+the underlying idiom and `rules/coding-style.mdc` for naming/typing.
+
+## Workflow
+
+### Step 1: Identify the framework and the project's own conventions
+
+- Detect which meta-framework the project uses (`next.config.*` +
+  `app/` directory, vs. `nuxt.config.ts` + `pages/`/`server/`) — a
+  monorepo may have both in different packages, so confirm which package
+  you are actually working in before writing anything.
+- Read the nearest existing page/route/composable of the same kind
+  (another `page.tsx`, another `server/api/*.ts`, another composable) for
+  the project's own patterns: how it fetches data, where it puts types,
+  what error-handling shape it uses. Match that shape rather than
+  inventing a new one.
+
+### Step 2: Choose the Server/Client boundary (Next.js) or composable context (Nuxt)
+
+- Next.js: default to a Server Component (no directive). Add
+  `'use client'` only on the smallest leaf that needs `useState`,
+  `useEffect`, a browser API, or an event handler — never on a shared
+  layout or an ancestor of that leaf.
+- Nuxt: call composables (`useFetch`, `useRoute`, a custom `useX`)
+  synchronously at the top level of `<script setup>`, a plugin, or
+  middleware — not inside an async callback or after an `await`, since
+  Nuxt resolves their injection context synchronously at call time.
+
+### Step 3: Fetch data where the framework already renders
+
+- Next.js: fetch inside the Server Component with `fetch()` (deduplicated
+  and cached per render pass) or the project's server-side data layer;
+  pass the result down as serializable props to any Client Component that
+  needs it. Do not re-fetch the same data client-side after mount unless
+  the requirement is genuinely post-interaction (a search box, a
+  paginated "load more").
+- Nuxt: use `useFetch`/`useAsyncData` with an explicit, stable key for any
+  data the page needs during SSR — they dedupe across server and client
+  and hydrate without a second request. Reserve a plain `$fetch` call
+  inside `onMounted`/an event handler for genuinely client-only,
+  post-interaction calls.
+
+### Step 4: Choose the rendering mode deliberately
+
+- Next.js: leave the route static (default) unless it reads
+  `cookies()`/`headers()`/`searchParams` or needs fresh data every
+  request. When data can tolerate staleness, set
+  `export const revalidate = <seconds>` for ISR instead of forcing full
+  dynamic rendering.
+- Nuxt: set per-route behavior in `nuxt.config.ts`'s `routeRules` (`isr`,
+  `prerender`, or `ssr: false` for one route) rather than flipping the
+  app-wide `ssr` flag for a need that is local to one route.
+
+### Step 5: Write the mutation path (Server Action / server route)
+
+- Next.js: a Server Action (`'use server'`, file-level or inline) is
+  called from a form's `action` prop or a Client Component's handler.
+  After the mutation, call `revalidatePath()`/`revalidateTag()` for the
+  routes that show the changed data, so the same request cycle serves
+  fresh data — don't hand-roll a client refetch when revalidate already
+  covers it.
+- Nuxt: a `server/api/*.ts` handler reads the request via `defineEventHandler`,
+  validates/authorizes inside the handler itself (it is a public HTTP
+  endpoint), and returns the result; call it from the page via
+  `useFetch`/`$fetch`, not by importing server-only code into a component.
+- Both: re-validate every input inside the action/handler server-side —
+  client-side form validation is UX, not a trust boundary. See
+  `rules/security.mdc`.
+
+### Step 6: Verify
+
+Run the commands in Verification below before reporting the feature done.
+
+## Rules
+
+- Follow `rules/patterns.mdc` for the Server/Client boundary, rendering
+  mode, and data-fetching idiom.
+- Follow `rules/security.mdc` for env-var scoping and Server
+  Action/server-route auth.
+- Follow `rules/coding-style.mdc` for naming, typing, and Nuxt
+  auto-import conventions.
+- ALWAYS keep server-only code (secrets, DB clients, `'use server'`
+  files, `server/api/**`) out of any import chain a Client Component or
+  browser bundle can reach.
+- NEVER widen a `'use client'` boundary or flip a route/page to `ssr:
+  false` just to make an implementation easier — fix the actual
+  server/client data flow instead.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "I'll just mark the whole page 'use client', then I don't have to think about the boundary" | Ships the entire subtree's JS to the browser and loses server rendering for content that never needed it; isolate the directive to the interactive leaf |
+| "I'll call useFetch inside this onMounted callback so it definitely has the DOM ready" | Nuxt composables need synchronous setup-time invocation to resolve their context; moving it into an async callback breaks that, not fixes it |
+| "I'll just refetch client-side after the Server Action instead of figuring out revalidatePath" | Server Actions + revalidate already deliver fresh data in one round trip; a manual refetch is an unnecessary second request and a source of stale-UI bugs |
+| "The client already validates the form, so the server action doesn't need to check again" | A Server Action/server route is a directly reachable HTTP endpoint; client validation is UX only |
+
+## Verification
+
+Do not report the feature done until:
+
+- The project's type-check passes (`tsc --noEmit`, or `nuxi typecheck`).
+- `next build` or `nuxi build` completes without new warnings about a
+  missing `'use client'` boundary, an invalid composable call, or an
+  unresolved auto-import.
+- Every new Server Action/server route validates and authorizes its own
+  input, independent of client-side checks.
+- No secret was exposed by an incorrect `NEXT_PUBLIC_`/`runtimeConfig`
+  placement (`rules/security.mdc`).

package/src/gdskills/bundled/stacks/nextjs-nuxt/skills/nextjs-nuxt-implementation/evals.json

@@ -0,0 +1,78 @@
+{
+  "triggers": {
+    "positive": [
+      "I need to add a new order-history page to my Next.js app router project, should the data fetching happen in a server component?",
+      "Write a Next.js server action that creates a post and revalidates the posts list",
+      "This Nuxt page needs to fetch orders on load, should I use useFetch or a plain fetch call?",
+      "I need an endpoint under server/api in my Nuxt app that hands back the logged-in user's profile data, can you build that?",
+      "Set up ISR on this Next.js product page so it revalidates every hour",
+      "Configure routeRules in nuxt.config.ts so this one Nuxt route renders as SPA-only",
+      "My Nuxt composable needs to call the API as soon as the page loads, how should I wire that up",
+      "I'm adding a new component to my Next.js app and I'm not sure which rendering boundary it belongs in, how do I decide?"
+    ],
+    "negative": [
+      "Write a test for this Next.js page's server component",
+      "Review this Next.js server action diff for missing auth checks",
+      "Fix this Next.js build error about a Server Component importing useState",
+      "Migrate this Next.js app from the pages router to the app router",
+      "Add a plain React hook that debounces an input value, no routing involved",
+      "Fix this Go compile error about an unused import"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "server-client-boundary-placement",
+      "prompt": "I have a Next.js app router page that shows an order summary with a 'mark as paid' button. Where should the client-side interactivity live, and how should the data get there?",
+      "strictness": "high",
+      "expected_behavior": [
+        { "grader": "regex", "value": "'use client'" },
+        {
+          "grader": "judge",
+          "rubric": "A correct answer keeps the page/order-summary rendering as a Server Component that fetches the order data, and isolates 'use client' to only the small interactive button/form component that needs the click handler, passing the needed data down as a prop rather than marking the whole page a Client Component.",
+          "pass_criteria": [
+            "States that the page itself (or the bulk of the order summary) stays a Server Component with no 'use client' directive",
+            "Names 'use client' as belonging only on the small button/action component, not the page or a shared layout",
+            "Describes passing the necessary order data down as a prop from the server-rendered parent to that client leaf, rather than having the leaf re-fetch it itself"
+          ],
+          "fail_criteria": [
+            "Recommends adding 'use client' to the whole page or a layout component to make the button work -- naming 'use client' only to warn against placing it there is not a failure",
+            "Has the client button component independently re-fetch the order data client-side instead of receiving it as a prop from the server-rendered parent"
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Keep the order-summary page itself a Server Component -- fetch the order data there with no 'use client' directive. Extract just the 'mark as paid' button into its own small component, e.g. MarkAsPaidButton.tsx, and put 'use client' at the top of that file only, since it's the piece that actually needs an onClick handler and client state (a pending/loading flag while the mutation runs). Pass the orderId (and any other data the button needs) down to it as a prop from the server-rendered page -- don't have the button component fetch the order itself. The button's onClick calls a Server Action ('use server') that performs the mutation and calls revalidatePath so the page reflects the new status afterward.",
+        "known_wrong": "Easiest way: put 'use client' at the top of the page.tsx file itself, then you can use useState for the button's pending state and onClick directly in the same component without worrying about the server/client split. It's one extra client-side render but it's much simpler than splitting into two files.",
+        "vague": "Keep most of it server-rendered and only make the interactive part a client component, that keeps things fast.",
+        "subtle_wrong": "I'd extract the button into its own component and mark it 'use client', which is the right idea -- but to keep things simple I'd have that client component call a route handler with fetch() on mount to pull the order data itself, rather than threading it down as a prop from the server page, since that way the button component is fully self-contained and doesn't need any props from its parent."
+      },
+      "anti_patterns": []
+    },
+    {
+      "id": "nuxt-composable-setup-context",
+      "prompt": "In my Nuxt page, I want to fetch the current user's orders as soon as the page mounts, using a composable I wrote. Where should I call it?",
+      "strictness": "high",
+      "expected_behavior": [
+        { "grader": "regex", "value": "setup" },
+        {
+          "grader": "judge",
+          "rubric": "A correct answer calls the composable synchronously at the top level of <script setup> (not inside an async callback, onMounted-with-await, or after an await), explaining that Nuxt resolves a composable's injection context synchronously at call time.",
+          "pass_criteria": [
+            "States the composable must be called at the top level of <script setup>, synchronously, not inside an async callback or after an await",
+            "Explains why: Nuxt resolves the composable's context (route/app/plugin injection) synchronously at call time, so a deferred call loses access to it"
+          ],
+          "fail_criteria": [
+            "Recommends calling the composable inside an onMounted callback with an await before it, or inside a setTimeout, as the primary recommended placement -- mentioning that placement only to warn against it is not a failure"
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Call the composable directly at the top level of your <script setup> block, synchronously -- for example `const { data: orders } = await useOrdersComposable()` right in setup, not wrapped in onMounted or any async callback. Nuxt resolves a composable's access to its injection context (the current route, the app instance, plugin-provided services) synchronously when the composable function is first invoked; if you defer the call into an async callback or fire it after an earlier await inside setup, that context is no longer reliably available and the composable can throw or silently lose access to what it needs. If the composable itself does async work internally (like useFetch does), that's fine -- the call site just needs to be the synchronous top level of setup.",
+        "known_wrong": "Just call it inside onMounted(async () => { await useOrdersComposable() }) so you're sure the DOM is ready before fetching -- that's the safest place to put any data-fetching logic in a Vue/Nuxt component.",
+        "vague": "Nuxt composables need to be called at the right point in the component lifecycle for the context to work properly.",
+        "subtle_wrong": "Call it at the top of setup like usual, but if you need to fetch on mount specifically (not immediately on component creation), wrap just that call in onMounted so it only runs client-side after mount: onMounted(() => { useOrdersComposable() }) -- this still feels like it's 'in setup' since onMounted is registered during setup, so the composable should still have access to its context."
+      },
+      "anti_patterns": []
+    }
+  ]
+}

package/src/gdskills/bundled/stacks/nextjs-nuxt/skills/nextjs-nuxt-testing/SKILL.md

@@ -0,0 +1,116 @@
+---
+name: nextjs-nuxt-testing
+description: "Use when writing or fixing tests for a Next.js App Router page/Server Action or a Nuxt page/composable/server route: testing a Server Component's rendered output, a Client Component's interactivity with React Testing Library, a Nuxt composable that calls useFetch/useAsyncData with @nuxt/test-utils' mountSuspended, or a server/api handler's auth and validation paths. Not for plain React/Vue component unit tests with no meta-framework routing, SSR, or server-route concern (use react-testing/vue-testing), and not for implementing the feature under test (use nextjs-nuxt-implementation)."
+triggers:
+  - "write a test for this Next.js server action"
+  - "test this Nuxt composable that uses useAsyncData"
+  - "mountSuspended test for this Nuxt component with auto-imports"
+  - "how do I test a Next.js server component's output"
+  - "write a test for this server/api route in Nuxt"
+  - "test this route handler's auth check in Next.js"
+  - "flaky test around Date.now in this Next.js page"
+metadata:
+  origin: authored
+  category: test
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# Next.js / Nuxt testing
+
+Write or fix a test for a Next.js App Router page/Server Action or a Nuxt
+page/composable/server route. Covers both frameworks' own test-runner
+setup and mocking conventions. See `rules/testing.mdc` for the layout and
+mocking rules this skill applies.
+
+## Workflow
+
+### Step 1: Identify what is actually under test
+
+- A Server Component's rendered output (no interactivity) vs. a Client
+  Component's behavior (event handlers, state) vs. a Server
+  Action/route handler's logic (validation, auth, the mutation itself) —
+  each needs a different test shape; do not force all three through one
+  `render()` call.
+- A Nuxt page/composable that calls `useFetch`/`useAsyncData`/another
+  Nuxt-context composable, vs. a plain presentational `.vue` component
+  with no Nuxt runtime dependency — the first needs Nuxt's test context,
+  the second does not.
+
+### Step 2: Pick the right harness
+
+- Next.js: React Testing Library (with Jest or Vitest, whichever the
+  project already runs) for a Client Component's interactivity. For a
+  Server Component, render its resolved output or exercise it through an
+  integration/e2e test — `render()` alone does not run the App Router's
+  server data-fetching lifecycle.
+- Nuxt: `@nuxt/test-utils`'s `mountSuspended` (or `renderSuspended`) for
+  any component that calls a Nuxt composable needing runtime context;
+  plain Vue Test Utils `mount()` only for a component with zero Nuxt
+  context dependency.
+- A Server Action or `server/api/**` handler: call the exported function
+  directly with a constructed request/args, not through a rendered
+  component — the goal is testing the handler's own logic in isolation.
+
+### Step 3: Mock at the network boundary, not the data-fetching hook
+
+- Mock HTTP with MSW (or the project's existing network mock layer) for
+  any test that exercises `fetch`/`useFetch`/`$fetch` — this exercises the
+  real request/response handling code instead of a hand-stubbed hook
+  return value.
+- For a Server Action/server route test, mock the downstream dependency
+  (DB client, external API client) one layer down, and call the real
+  handler on top of it, so the test actually proves the handler's
+  auth/validation logic runs.
+
+### Step 4: Make it deterministic
+
+- Freeze/inject time (`vi.setSystemTime`, a clock parameter) for anything
+  rendering `Date.now()` or locale-dependent output.
+- Build route params/`searchParams`/`useRoute()` mocks with a realistic
+  shape (a fixture/factory), not a hand-built partial object that
+  happens to satisfy today's assertions.
+
+### Step 5: Verify
+
+Run the project's test command and confirm the new test fails without the
+implementation and passes with it (or, for a bug-fix test, fails on the
+buggy code first).
+
+## Rules
+
+- Follow `rules/testing.mdc` for layout, runner choice, and network
+  mocking.
+- Test the Server Action/server route's own auth and validation failure
+  paths, not just its success path.
+- NEVER mock the framework's data-fetching hook itself
+  (`useFetch`/`useAsyncData`) to return canned data when the point of the
+  test is the component's request/response handling — mock the network
+  layer beneath it instead.
+- NEVER skip or delete a flaky SSR/hydration-dependent test instead of
+  fixing its nondeterminism (freeze time, mock the varying input).
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "I'll just mock useAsyncData to return the data directly, simpler than mocking the network" | Tests the mock, not the component's real fetch/error/loading handling; mock at the network boundary instead |
+| "This composable test keeps breaking on Nuxt context, I'll just plain-mount it with Vue Test Utils" | A composable that needs Nuxt's injection context needs `mountSuspended`/Nuxt's test context, not a mount that has none |
+| "This test is flaky because of the date, I'll just skip it" | Skipping hides the same nondeterminism that causes a real hydration mismatch in production; freeze the clock instead |
+| "The server action already has client-side validation tested, no need to test the handler separately" | The handler is a directly reachable endpoint; its own validation/auth path needs its own test regardless of client-side coverage |
+
+## Verification
+
+Do not report the test done until:
+
+- The project's test command passes, and the new test fails against the
+  pre-fix/pre-implementation code (proving it actually exercises the
+  behavior).
+- No data-fetching hook (`useFetch`/`useAsyncData`/`fetch`) was mocked
+  directly when a network-boundary mock (MSW or equivalent) would have
+  exercised the real code path.
+- A tested Server Action/server route has at least one assertion covering
+  an auth or validation failure, not only the happy path.
+- No `Date.now()`/`Math.random()`/locale-dependent value reaches an
+  assertion unfrozen or unmocked.

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

@@ -0,0 +1,75 @@
+{
+  "triggers": {
+    "positive": [
+      "This server action creates a new order when called, what's the right way to get test coverage around it?",
+      "I've got a composable in my Nuxt app that internally kicks off useAsyncData, what's the best approach for testing it?",
+      "This Nuxt component pulls values from useRoute, and I need to render it in a test using @nuxt/test-utils, what's the setup for that?",
+      "How do I write a test for what this Next.js App Router server component actually renders?",
+      "Write a test for this server/api/orders.ts handler in Nuxt covering the unauthenticated case",
+      "There's an authorization check inside this route handler that has zero coverage right now, can you help me write a test for it?",
+      "One of my page tests only fails intermittently, and I traced it back to the component calling Date.now() during render, how do I make this deterministic?"
+    ],
+    "negative": [
+      "Add a new page to this Next.js app router project",
+      "Review this Nuxt server/api/orders.ts route for security issues",
+      "Fix this Nuxt build error about a composable being called outside setup",
+      "Migrate this Nuxt 2 asyncData call to useAsyncData",
+      "Write a Jest test for a plain React hook with no routing or SSR concern",
+      "Fix this generic ESLint no-floating-promises failure in a plain Node.js script"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "mock-network-not-hook",
+      "prompt": "I'm writing a test for a Nuxt page that calls useFetch to load a list of orders. Should I mock useFetch directly to return canned data, or something else?",
+      "strictness": "high",
+      "expected_behavior": [
+        { "grader": "regex", "value": "MSW|network" },
+        {
+          "grader": "judge",
+          "rubric": "A correct answer recommends mocking at the network/HTTP boundary (e.g. with MSW) rather than mocking useFetch itself, because mocking the hook only tests the mock and skips the component's real request/response handling.",
+          "pass_criteria": [
+            "Recommends mocking the HTTP/network layer (e.g. MSW, or the project's equivalent network mock) rather than mocking useFetch's return value directly",
+            "Explains that mocking useFetch itself tests the mock rather than the component's real request/response/loading/error handling"
+          ],
+          "fail_criteria": [
+            "Recommends mocking useFetch's return value (e.g. vi.mock of the composable) as the primary approach -- mentioning that approach only to warn against it is not a failure"
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Mock at the network boundary, not the composable. Use MSW (or whatever network-mocking layer the project already has set up) to intercept the actual HTTP request useFetch makes under the hood, and return the canned orders response from there. That way the test still exercises the real useFetch call, including how the component handles the loading state, the data once it resolves, and an error response if you want to test that path too. If you instead mock useFetch itself to just return { data: ordersFixture } directly, you're only proving your mock works -- the test would still pass even if the component's actual request logic, URL, or error handling were broken.",
+        "known_wrong": "Just mock useFetch directly with vi.mock so it returns { data: ref(ordersFixture), pending: ref(false) } -- that's the simplest way to control exactly what the component sees without dealing with setting up a network mocking library.",
+        "vague": "Try to test the real data flow rather than just stubbing things out, that gives you more confidence.",
+        "subtle_wrong": "Set up MSW to intercept the request, that's the right instinct -- but register the MSW handler to intercept the internal Nuxt $fetch wrapper's resolved promise rather than the actual HTTP endpoint URL the orders API is served from, so you don't have to figure out the real URL pattern; it still counts as 'network-level' since it's below the composable itself."
+      },
+      "anti_patterns": []
+    },
+    {
+      "id": "server-action-handler-test-coverage",
+      "prompt": "I wrote a Next.js server action that creates an order and only has a happy-path test so far. What else should the test cover?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer states that the server action's own auth/authorization check and input validation failure paths need their own test coverage, calling the handler directly (or through its real invocation path) rather than only asserting the successful-creation case, since the client's own form validation does not substitute for server-side test coverage.",
+          "pass_criteria": [
+            "Names testing the auth/authorization failure path (e.g. an unauthenticated or unauthorized caller) as missing coverage that should be added",
+            "Names testing at least one input-validation failure path (bad/missing input) as missing coverage that should be added",
+            "States or implies these should call the real server action handler (with a mocked downstream dependency like the database) rather than only testing the UI form that calls it"
+          ],
+          "fail_criteria": [
+            "States that the happy-path test alone is sufficient because the form already validates input client-side, or that server-side auth/validation testing can be skipped since the client already checks it"
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "The happy path alone isn't enough -- add tests that call the server action directly (with the database client mocked) covering: an unauthenticated caller (no session) should be rejected before any write happens; an authenticated caller without permission on this resource should also be rejected; and at least one bad-input case (missing or malformed order fields) should fail validation rather than reaching the database call. Each of these exercises the action's own auth and validation logic in isolation, since the server action is a directly reachable endpoint regardless of whether the calling form already validates -- client-side validation doesn't give you any server-side test coverage.",
+        "known_wrong": "The happy-path test is probably enough since the form itself already validates required fields before submitting and the user has to be logged in to see the form at all, so those cases shouldn't really be reachable in practice.",
+        "vague": "You should probably add a few more test cases for edge cases and errors, not just the success case.",
+        "subtle_wrong": "Good idea to add more coverage -- I'd add a test where the form is submitted with an empty title field and assert the submit button stays disabled, plus a test that the login redirect happens if you're not authenticated. That covers the important failure modes on the client side that lead into this action."
+      },
+      "anti_patterns": []
+    }
+  ]
+}