@gallopsystems/agent-skills 1.11.0 → 1.12.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@gallopsystems/agent-skills",
-  "version": "1.11.0",
+  "version": "1.12.0",
   "description": "Gallop Systems agent skills, symlinked into .claude/skills (Claude Code) and .agents/skills (Codex) on install.",
   "license": "UNLICENSED",
   "repository": {

package/plugins/git-github/skills/git-github/SKILL.md

@@ -51,6 +51,7 @@ EOF
 - After merge: `git switch main && git pull --ff-only`, clean up `[gone]` branches, start the next branch from fresh main.
 - One concern per PR — hotfixes and review findings go in separate PRs unless told otherwise.
 - Stacked PRs: `gh pr create --base <parent-branch>`; after the parent merges, retarget with `gh pr edit <n> --base main` (and see [getting-unstuck.md](getting-unstuck.md) for rebasing onto main after the parent was squash-merged).
+- If you discover uncommitted work on the wrong branch and the PR must be "off main", do not commit to the wrong branch. With a cleanly applicable worktree, `git fetch origin main && git switch -c feat/<short-description> origin/main` carries the unstaged changes onto a new branch from `origin/main`. Verify with `git status` and tests. If checkout would overwrite/conflict, stash with `-u`. Only resort to worktree if stash gets too complicated.
 
 ## Reading PR and CI State
 

package/plugins/nitro-testing/skills/nitro-testing/frontend-testing.md

@@ -526,6 +526,19 @@ await flushPromises();
 expect(replace.mock.calls.some((c) => (c[0] as any)?.query?.q === "foo")).toBe(true);
 ```
 
+If the component's source of truth is `useRoute()`/`useRouter()`, `route:` is not
+always the most direct test seam: app middleware, route rules, and redirects still
+run. For component-level behavior, mock the Nuxt imports before mounting:
+
+```typescript
+mockNuxtImport("useRoute", () => () => ({ query: { tab: "activity" }, params: {} }));
+mockNuxtImport("useRouter", () => () => ({ replace: vi.fn(), push: vi.fn() }));
+```
+
+If the component imports router helpers directly from `vue-router`, mock that
+module too. Keep the test focused on what the component reads or writes; use an
+end-to-end/page test when the middleware behavior itself is under test.
+
 ### 9. Testing a composable that needs a component scope
 
 For a composable using lifecycle hooks or `provide`/`inject`, mount a throwaway
@@ -541,6 +554,12 @@ Control a VueUse dependency with `vi.mock("@vueuse/core", …)` to return refs y
 drive. And make sure the vitest `include` glob covers `app/composables/**` — a
 composables dir is easy to leave out of the frontend config.
 
+Do this for lifecycle composables even when the return value looks plain:
+`onMounted`, `onUnmounted`, `useEventListener`, `useScrollLock`, and similar
+helpers need a component effect scope to attach and clean up correctly. Calling
+the composable directly in a Vitest test can produce Vue warnings and, worse,
+skip the listener or cleanup path you meant to verify.
+
 ### 10. Reset the shared `useFetch` cache between mounts
 
 `useFetch`/`useAsyncData` cache by key, and the cache is **shared across
@@ -553,6 +572,27 @@ import { clearNuxtData } from "#imports"; // not exported from @nuxt/test-utils/
 beforeEach(() => clearNuxtData());
 ```
 
+### 11. Mock Nuxt fetch behavior at the right layer
+
+`mockNuxtImport("$fetch", ...)` is not a reliable target: `$fetch` is not a normal
+Nuxt auto-import in the same way `useRoute` or a composable is, so the transform
+may fail before the test even runs. Prefer `registerEndpoint` when the component
+calls `useFetch`, `useAsyncData`, or `$fetch` against an app route:
+
+```typescript
+registerEndpoint("/api/search", {
+  method: "GET",
+  handler: (event) => {
+    const q = new URL(event.node.req.url!, "http://localhost").searchParams.get("q");
+    return [{ id: 1, name: q ?? "" }];
+  },
+});
+```
+
+If the component calls a local service/composable that wraps `$fetch`, mock that
+service/composable instead. Mock the boundary you own; use `registerEndpoint` for
+Nuxt's fetch path.
+
 ## File Organization
 
 Co-locate tests with source files:

package/plugins/vue-nuxt/skills/vue-nuxt/SKILL.md

@@ -39,6 +39,11 @@ cross-links to those rather than restating them.
 - [page-structure.md](./page-structure.md) — keep pages thin: route-param parsing + layout in the page, data/logic/forms in components
 - [formatters.md](./formatters.md) — never inline a currency/date/number formatter; centralize in `useFormatters`, prefer Intl/date-fns
 
+Testing note: when a Vue/Nuxt refactor changes component behavior, route/query
+state, or a composable with lifecycle hooks, use the Nuxt frontend testing
+guidance in `nitro-testing`'s [frontend-testing.md](../../../../nitro-testing/skills/nitro-testing/frontend-testing.md)
+instead of testing those pieces as plain Vue functions.
+
 ## Core Principles
 
 1. **Lean on auto-imports.** `app/components`, `app/composables`, `app/utils`, and the Vue/Nuxt APIs all auto-import. Add an explicit `import` only for third-party symbols and TS types. A nested component's tag carries its directory as a prefix (`components/customers/ProfileCard.vue` → `<CustomersProfileCard>`).

package/plugins/vue-nuxt/skills/vue-nuxt/vueuse.md

@@ -24,6 +24,9 @@ export default defineNuxtConfig({ modules: ['@vueuse/nuxt'] })
 
 The **`@vueuse/router`** and **`@vueuse/integrations`** add-ons are separate
 installs and are **not** auto-imported by the module — import them explicitly.
+For URL query sync, install `@vueuse/router` and use its router composables before
+hand-rolling `useRoute()`/`useRouter()` glue; the package exists exactly for that
+boundary.
 
 ## The boundary cases (mapped from `watch.md`)
 
@@ -42,8 +45,9 @@ installs and are **not** auto-imported by the module — import them explicitly.
 
 URL sync (`router.replace({ query: { ...route.query, tab } })`) →
 `useRouteQuery('tab')` from `@vueuse/router` gives a ref bound two-way to the query
-param. Nuxt's own `useRoute()` is already reactive for *reads*; reach for
-`useRouteQuery` when you want a **writable** ref bound to a single param.
+param. Nuxt's own `useRoute()` is already reactive for *reads*; install and import
+`useRouteQuery` when you want a **writable** ref bound to a single param instead of
+open-coding the same replace/query merge logic.
 
 ### `useLocalStorage` reads at setup — guard SSR hydration
 
@@ -67,9 +71,13 @@ Because the bound ref reads from and writes to the query param, the URL *is* the
 state — so it **can't represent a ref with two distinct "empty" states** (e.g. a
 filter that defaults to `"Open"` on load but clears to `null`; both would be "param
 absent"). When you need that distinction, keep a plain `ref` + a projecting `watch`
-(a sanctioned `watch.md` "URL sync" case). And **don't mix `useUrlSearchParams`
-(History API) with `useRouteQuery` (vue-router) in the same component** — they write
-the URL through different mechanisms and clobber each other's params; pick one.
+(a sanctioned `watch.md` "URL sync" case). The same exception applies when one
+source object fans out to several query params and the projection itself is the
+behavior being tested. Otherwise, adding `@vueuse/router` is preferable to writing
+your own route-query synchronization. And **don't mix `useUrlSearchParams`
+(History API) with `useRouteQuery` (vue-router) in the same component** — they
+write the URL through different mechanisms and clobber each other's params; pick
+one.
 
 ## VueUse's `watch` sugar — when a `watch` IS warranted
 

package/plugins/vue-nuxt/skills/vue-nuxt/watch.md

@@ -69,12 +69,12 @@ Only when the effect crosses **out of** the reactive graph:
 - **Persist** — a `localStorage`/`useCookie` write, debounced auto-save of a
   deep-watched form.
 - **URL sync** — `router.replace({ query: { ...route.query, tab } })`. For a single
-  ref ↔ one query param, prefer `useRouteQuery` (see below). A write-back watch is
-  the right tool only when the URL can't model the state: a ref with **two distinct
-  "empty" states** (e.g. a filter that defaults to `"Open"` on load but clears to
-  `null` — an absent param can map to only one of them), or a **composite object
-  fanning out to many params** (a PrimeVue filter object) that a one-ref-per-param
-  `useRouteQuery` can't express.
+  ref ↔ one query param, install `@vueuse/router` and prefer `useRouteQuery` (see
+  below). A write-back watch is the right tool only when the URL can't model the
+  state: a ref with **two distinct "empty" states** (e.g. a filter that defaults to
+  `"Open"` on load but clears to `null` — an absent param can map to only one of
+  them), or a **composite object fanning out to many params** (a PrimeVue filter
+  object) that a one-ref-per-param `useRouteQuery` can't express.
 - **Re-seed local state on dialog open** — `watch(visible, (v) => { if (v) initForm() })`.
   The single most common legit pattern. Its one-liner is `whenever(visible, initForm)`
   (see `vueuse.md`); a compound guard keeps its inner half —