@gallopsystems/agent-skills 1.11.0 → 1.13.0

package/package.json

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

package/plugins/doctl/skills/doctl/other-services.md

@@ -10,7 +10,9 @@ doctl databases ca <db-id>                                    # cluster CA certi
 
 - **The connection URI contains live credentials** — treat command output as a secret. Don't echo it into logs; pipe it directly to where it's needed.
 - **Check `Version`** and keep CI/local database versions in sync with production — a test suite running `postgres:15` against a pg-18 production cluster hides version-specific behavior.
-- Connections use port 25060 with `sslmode=require`. **TLS trap**: some clients (e.g. newer `pg-connection-string`) silently upgrade `require` to `verify-full`, which rejects DO's CA under the default trust store. Fix: supply the CA from `doctl databases ca <db-id>` explicitly, or configure ssl options in code rather than relying on the URI.
+- Connections use port 25060 with `sslmode=require`. **TLS trap**: some clients (e.g. `pg-connection-string` as bundled with `pg` >= 8.16) silently treat `require` as `verify-full`, which rejects DO's self-signed CA under the default trust store (`SELF_SIGNED_CERT_IN_CHAIN`). Two non-obvious parts:
+  - **An ssl option set in code does NOT override an `sslmode` already in the URI.** Passing `ssl: { rejectUnauthorized: false }` while the connection string still ends in `?sslmode=require` keeps failing — the URI's `sslmode` wins. The fix has to land in the URI itself: drop/replace `sslmode`, append `uselibpqcompat=true` (restores libpq semantics: encrypt but don't verify), or supply the CA from `doctl databases ca <db-id>` explicitly.
+  - **When you can't edit the URI** — specifically, when you bind App Platform's generated `${db.DATABASE_URL}` straight into an env var in the app spec, it always carries `?sslmode=require` and you don't author the string — append the param to the bound value: `value: ${db.DATABASE_URL}&uselibpqcompat=true`. This only applies to that bound-pipethrough case; if you declare the connection-string env var yourself, just put the right params (or none) in from the start and an in-code ssl option is enough.
 
 ## Spaces
 

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/kysely-postgres/skills/kysely-postgres/SKILL.md

@@ -964,6 +964,53 @@ await db.schema.createIndex("idx_order_user_id").on("order").column("user_id").e
 .addColumn("price", sql`numeric(10, 2)`)
 ```
 
+### Migration Ordering Is Append-Only — Out-of-Order Timestamps Break Prod Deploys
+
+Kysely's migrator enforces a **strict append-only ledger**: it refuses to run any
+unexecuted migration whose timestamp sorts *before* the last-executed one
+(throwing `Corrupted migrations: previously executed migration ... is missing`).
+This bites when two branches each add a migration, and the one that merges *second*
+carries the *earlier* timestamp:
+
+```
+branch A merges first  → 1700000200000_drop_thing      (runs in prod)
+branch B merges second → 1700000100000_add_table       (timestamp is EARLIER)
+                       → 1700000100001_add_column
+```
+
+Prod has already recorded `...200000_drop_thing` as executed. On the next deploy
+the `migrate` job sees two pending migrations that sort *before* it, throws
+"Corrupted migrations", and **exits non-zero**. If migrations run as a pre-deploy
+job (common on PaaS like DigitalOcean App Platform), the failed job fails the whole
+deploy and the platform **auto-rolls-back to the previous image** — so prod silently
+stays on stale code and every subsequent deploy fails the same way. A self-reinforcing
+loop that looks like a deploy/token problem but is really a migration-ledger problem.
+
+**Prevent it:** before merging a long-lived branch, check whether `main` has merged
+any migration with a *later* timestamp than yours. If so, regenerate your migration's
+timestamp so it sorts last (`migrate:make` again, or rename the file) **before it
+merges** — only safe while the migration has not yet run in any shared DB. Never
+re-stamp a migration that prod has already executed; that forces it to re-run.
+
+**Fix it once prod is wedged:** reconcile the ledger so the executed set is a clean
+*prefix* again, then let the normal strict migrate job run. Do **not** reach for
+`allowUnorderedMigrations: true` — it works (kysely-ctl spreads the `migrations`
+config into the `Migrator`), but it permanently weakens the ordering guard to paper
+over one bad state. Instead, surgically remove the prematurely-recorded row from the
+migration ledger table (default `kysely_migration`):
+
+```sql
+-- prod ledger has the later-timestamp migration recorded, blocking the two earlier ones
+DELETE FROM kysely_migration WHERE name = '1700000200000_drop_thing';
+```
+
+Now `add_table → add_column → drop_thing` are all pending in true timestamp order, and
+the next deploy's strict migrate job applies them cleanly. This only works when the
+removed migration is **idempotent to re-run** (e.g. a `dropTable`/`dropColumn` written
+with `ifExists`, so re-applying it after the others is a safe no-op). Verify the
+ledger is a contiguous prefix after the DELETE, and prefer letting the deploy's own
+migrate job re-apply rather than running migrations from a laptop against prod.
+
 ## Type Generation
 
 Use `kysely-codegen` to generate types from your database:

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 —