navori 0.2.11 → 0.2.16

package/README.md

@@ -19,6 +19,9 @@ npx navori init
 cd ~/tu-repo
 navori init --recommended
 
+# Instalación máxima: todos los plugins + pre-commit hook + scan-monorepo + project block estricto
+navori init --full
+
 # O wizard interactivo con detección de stack
 navori init
 ```
@@ -40,7 +43,7 @@ Y genera:
 
 | Comando | Qué hace |
 |---|---|
-| `init` | Bootstrap del repo con detección automática + wizard (o `--recommended` sin preguntas) |
+| `init` | Bootstrap del repo con detección automática + wizard (o `--recommended` sin preguntas, o `--full` para la instalación máxima) |
 | `add <plugin>` | Activa un plugin y opcionalmente instala la tool externa |
 | `configure <section>` | Ajusta una sección del config sin re-correr el wizard |
 | `update` | Re-detecta el repo, refresca config y corre sync en un paso |
@@ -67,10 +70,12 @@ Un preset aporta skills y reglas específicas del stack además del core. El `in
 | `vite-react-ts` | Vite + React + TS (SPA, agnóstico de UI-lib) |
 | `vite-react-ts-mantine` | Vite + React + TS + Mantine (SPA) |
 | `nextjs` | Next.js (App Router) |
+| `react-native-expo` | React Native + Expo (app móvil) |
 | `astro` | Astro (static / SSR) |
 | `nestjs` | NestJS (backend) |
 | `express` | Express (backend, agnóstico de DB) |
 | `express-mongoose` | Express + Mongoose (backend) |
+| `bun-keystone` | Keystone 6 + Prisma (backend, Bun) |
 | `background-worker` | Worker de fondo (jobs + colas: agenda / bullmq / amqplib) |
 | `medusa` | Medusa.js v2 (backend) |
 

package/dist/assets/core/core-assets/lib-skills/bullmq.md

@@ -0,0 +1,56 @@
+---
+name: bullmq
+description: Jobs y colas con BullMQ sobre Redis — Queue/Worker/QueueEvents, jobs idempotentes, retries con backoff, concurrency y graceful shutdown. Aplica al crear/tocar un job, un worker o al encolar trabajo async.
+type: reference
+---
+
+# BullMQ — jobs & queues
+
+BullMQ mueve trabajo pesado o diferido fuera del request: un **productor** encola (`Queue.add`) y un **worker** (proceso aparte) lo procesa. La conexión es Redis (`ioredis`). El productor y el worker viven en procesos distintos y comparten solo el nombre de la cola.
+
+## Cuándo usar este skill
+
+Al crear una cola o un job nuevo, tocar el worker, encolar trabajo desde un handler/hook, o depurar jobs que se cuelgan, se reintentan en loop o se pierden.
+
+## El patrón
+
+```ts
+// Productor (en un request/hook): encola y responde rápido, NO esperes el resultado.
+await queue.add("send-welcome", { userId }, {
+  attempts: 3,
+  backoff: { type: "exponential", delay: 1000 },
+  removeOnComplete: 1000,   // no dejes que Redis crezca sin límite
+  removeOnFail: 5000,
+});
+
+// Worker (proceso aparte): una responsabilidad por worker/cola.
+const worker = new Worker("emails", async (job) => {
+  // idempotente: correr dos veces el mismo job no debe duplicar efectos
+  return sendEmail(job.data);
+}, { connection, concurrency: 5 });
+```
+
+## Reglas duras
+
+1. **Jobs idempotentes.** Un job puede reintentarse o entregarse dos veces. Usa un id determinista (`jobId`) o un guard de "ya procesado" para efectos no repetibles (cobros, emails, mutaciones críticas).
+2. **`attempts` + `backoff` siempre.** Un job sin reintentos muere al primer error transitorio; uno sin backoff martillea el recurso que falla. Exponencial por default.
+3. **El productor NO espera el resultado.** Encola y responde; el valor del job se consume por eventos (`QueueEvents`) o releyendo estado, no bloqueando el request.
+4. **`removeOnComplete`/`removeOnFail`.** Sin límites, Redis se llena de jobs viejos. Acota siempre.
+5. **Graceful shutdown.** En `SIGTERM`/`SIGINT`, `await worker.close()` antes de salir para no matar un job a medias. Un worker que no cierra limpio deja jobs en `active` colgados.
+6. **Errores que deben reintentar → lanza; errores permanentes → no.** Un input inválido no se arregla reintentando: valida antes de encolar o marca el job como fallido sin reintento (`attempts: 1` o un error no-recuperable).
+7. **Una responsabilidad por worker.** No metas varios tipos de trabajo no relacionado en un solo `Worker` con `if job.name`; sepáralos por cola.
+
+## Gotchas que muerden
+
+- **La `connection` de ioredis para BullMQ necesita `maxRetriesPerRequest: null`** — si no, BullMQ lanza al reconectar.
+- **`concurrency` alto no es gratis**: cada job concurrente abre conexiones/CPU. Súbelo con medida, no por default.
+- **Un job "perdido"** casi siempre es: el worker no está corriendo, apunta a otra cola/Redis, o crasheó sin `removeOnFail` y quedó en `failed`. Revisa el estado del job antes de asumir un bug de lógica.
+- **Delayed/repeatable jobs** viven en Redis: cambiar el patrón de un repeatable no borra el viejo — límpialo explícitamente.
+
+## Antes de declarar listo
+
+- El job es idempotente (o tiene guard de duplicados) y define `attempts` + `backoff`.
+- El worker cierra en `SIGTERM`/`SIGINT` (`worker.close()`).
+- `removeOnComplete`/`removeOnFail` acotados; la `connection` usa `maxRetriesPerRequest: null`.
+- El productor no bloquea el request esperando el job.
+- `{{qualityGate.fast}}` en verde.

package/dist/assets/core/core-assets/presets/bun-keystone/managed/stack.md

@@ -0,0 +1,13 @@
+## Stack — Keystone 6 (Bun + Prisma)
+
+Backend GraphQL sobre **Keystone 6**, runtime **Bun**, persistencia **Prisma + PostgreSQL**. Los datos se modelan como *lists* (`list({ access, hooks, fields })`) y Keystone deriva de ahí el schema Prisma y la API GraphQL: `schema.prisma` y `schema.graphql` son **autogenerados**, nunca se editan a mano (ver `prisma-keystone`).
+
+Tres contratos gobiernan todo el código de datos:
+
+- **Access control en 3 capas** — cada list declara `operation`, `filter` y `field`; `allowAll` está prohibido. Una sesión nula recibe un filtro restrictivo, nunca abierto. Ver `keystone-access`.
+- **Hooks con contrato estricto** — `resolveInput` retorna datos, `validateInput` lanza `Error` (nunca retorna un valor), `afterOperation` chequea `operation` antes de actuar. Ver `keystone-models`.
+- **`context.sudo()` en hooks y services** — nunca `context.db` (aplicaría el access de la sesión actual) ni Prisma directo; `context.prisma` queda solo para scripts de seed/migración.
+
+Toda dependencia externa (SMS, pagos, APIs de terceros) va detrás de una interfaz en `[servicio].adapter.ts`: los services reciben la interfaz, no la implementación, para poder mockearla en tests.
+
+**Eficiencia de contexto** — los artefactos generados (`types/graphql.ts` puede rondar decenas de miles de tokens, `schema.graphql`, `migrations/`, el lockfile) **no se leen completos**: infiere los tipos desde la *list* en `models/` o desde `schema.prisma`, y busca con `grep`/`Grep` en vez de abrir el archivo entero.

package/dist/assets/core/core-assets/presets/bun-keystone/skills/keystone-access.md

@@ -0,0 +1,52 @@
+---
+name: keystone-access
+description: Access control de Keystone 6 en 3 capas (operation / filter / field). allowAll prohibido; sesión nula → filtro restrictivo. Aplica al definir o cambiar el access de cualquier list.
+type: reference
+---
+
+# Keystone Access Control — 3 capas
+
+## Cuándo usar este skill
+
+Siempre que definas o modifiques el `access` de una list. Una línea mal puesta aquí es una fuga de datos o un bloqueo total — es el código más sensible del backend. Léelo completo antes de tocar `access`.
+
+## Las 3 capas
+
+```ts
+access: {
+  operation: { query, create, update, delete }, // ¿puede el usuario ejecutar la operación?
+  filter:    { query, update, delete },          // ¿sobre QUÉ registros? (devuelve un where)
+  field:     { fieldName: { read, create, update } }, // ¿puede leer/escribir ESTE campo?
+}
+```
+
+1. **`operation`** — gate booleano por operación. Devuelve `true`/`false` según la sesión. Es el "¿tiene permiso de intentarlo?".
+2. **`filter`** — devuelve un `where` de Prisma que acota el conjunto de registros visibles/afectables. Es el "¿sobre cuáles?". Ej.: un usuario solo ve/edita sus propios registros → `{ author: { id: { equals: session.itemId } } }`.
+3. **`field`** — control fino por campo (ocultar un campo sensible en lectura, impedir escribir un campo calculado).
+
+Las tres se combinan: `operation` decide si la request entra, `filter` acota el set, `field` recorta columnas.
+
+## Reglas duras
+
+1. **`allowAll` está prohibido.** Nunca `access: allowAll`. Todo list declara reglas explícitas por operación. Si algo "es público", exprésalo con una función que retorna `true` acotada, no con `allowAll`.
+2. **Sesión nula → restrictivo, no abierto.** Cuando no hay sesión, el default es negar (o un `filter` que no matchee nada), nunca abrir. Empieza cerrando y abre lo justo.
+3. **`filter` devuelve un where, no un booleano.** Si necesitas negar todo en una capa `filter`, devuelve un where imposible (`{ id: { equals: null } }`), no `false`.
+4. **La lógica de access va en `access/`, no inline.** Extrae funciones reutilizables (`isSignedIn`, `isOwner`, `isAdmin`) a archivos de `access/` y compón; no dupliques la misma condición inline en varias lists.
+5. **Access ≠ validación de negocio.** Access decide quién ve/toca qué; las reglas de negocio (un valor válido, un estado permitido) van en `validateInput` (ver `keystone-models`).
+
+## Tabla rápida
+
+| Quiero | Capa | Forma |
+|---|---|---|
+| Bloquear crear a no-admins | `operation.create` | `({ session }) => isAdmin(session)` |
+| Que cada quien vea lo suyo | `filter.query` | `({ session }) => ({ owner: { id: { equals: session?.itemId } } })` |
+| Ocultar un campo sensible | `field.<campo>.read` | `({ session }) => isAdmin(session)` |
+| Impedir editar un campo calculado | `field.<campo>.update` | `() => false` |
+
+## Antes de declarar el cambio "listo"
+
+- `{{qualityGate.fast}}` en verde.
+- `grep -rn "allowAll" access/ models/` → 0 resultados.
+- Toda list tocada declara las 3 capas donde apliquen; ninguna operación quedó implícitamente abierta.
+- Sesión nula probada: la list niega o filtra, nunca expone todo.
+- Las condiciones nuevas se extrajeron a `access/` si se repiten en más de una list.

package/dist/assets/core/core-assets/presets/bun-keystone/skills/keystone-models.md

@@ -0,0 +1,61 @@
+---
+name: keystone-models
+description: Convenciones para lists de Keystone 6 — estructura list({ access, hooks, fields }), contrato de hooks (resolveInput/validateInput/afterOperation) y uso de context.sudo(). Aplica al crear o modificar un modelo.
+type: reference
+---
+
+# Keystone Models — convenciones del proyecto
+
+## Cuándo usar este skill
+
+Antes de crear una list nueva, agregar/cambiar un field, o tocar un hook de un modelo. Los hooks y el access de una list son el punto donde vive la lógica de negocio y la seguridad de los datos; saltarse el contrato rompe la integridad o abre huecos de acceso.
+
+## Estructura de una list
+
+```ts
+export const Report = list({
+  access: { /* ver skill keystone-access */ },
+  hooks: { resolveInput, validateInput, afterOperation },
+  fields: {
+    title: text({ validation: { isRequired: true } }),
+    author: relationship({ ref: "User.reports", many: false }),
+    // ...
+  },
+});
+```
+
+Un modelo se compone de tres bloques: `access` (quién puede qué — skill aparte), `hooks` (lógica de dominio en el ciclo de vida) y `fields` (forma de los datos). Manténlos en ese orden.
+
+## Contrato de hooks (reglas duras)
+
+1. **`resolveInput` transforma y retorna** — devuelve el objeto de datos resuelto: `return { ...resolvedData, slug };`. Es el único hook que muta lo que se va a persistir. Nunca lanzas desde aquí para validar (eso es `validateInput`).
+2. **`validateInput` valida y lanza** — chequea invariantes de negocio y, si algo está mal, `addValidationError(msg)` o `throw new Error(msg)`. **Nunca retorna un valor**; su único efecto es dejar pasar o abortar la operación.
+3. **`afterOperation` reacciona** — corre después de persistir (side-effects: encolar un job, recalcular un agregado, emitir un evento). **Siempre** chequea `operation` antes de actuar: `if (operation === "create" || operation === "update") { ... }`. En `delete` los datos ya no existen — usa `originalItem`.
+
+## context.sudo() cheatsheet
+
+```ts
+context.sudo().db.Model;   // hooks + services: bypass del access, para lógica interna confiable
+context.db.Model;          // NUNCA en hooks/services — re-aplica el access de la sesión y puede filtrar/negar de más
+context.prisma;            // SOLO en scripts de seed/migración, nunca en runtime de la app
+```
+
+Dentro de un hook o service **siempre** usa `context.sudo()`. Usar `context.db` en un hook es un bug latente: la operación puede fallar o devolver datos parciales según quién esté logueado.
+
+## Tabla rápida
+
+| Necesito | Dónde / Cómo |
+|---|---|
+| Derivar un campo antes de guardar | `resolveInput` → `return { ...resolvedData, campo }` |
+| Rechazar una operación inválida | `validateInput` → `throw new Error(...)` / `addValidationError(...)` |
+| Efecto secundario tras guardar | `afterOperation` con guard `operation === 'create'\|'update'` |
+| Leer/escribir otro modelo desde un hook | `context.sudo().db.OtroModelo` |
+| Relación entre modelos | `relationship({ ref: "Otro.campoInverso" })` |
+
+## Antes de declarar el cambio "listo"
+
+- `{{qualityGate.fast}}` en verde.
+- Ningún hook retorna desde `validateInput` ni lanza desde `resolveInput`.
+- Ningún `afterOperation` actúa sin chequear `operation`.
+- Ningún `context.db` ni `context.prisma` dentro de hooks/services (usa `context.sudo()`).
+- Si agregaste un field a un modelo existente: corre la migración (ver `prisma-keystone`), no edites `schema.prisma` a mano.

package/dist/assets/core/core-assets/presets/bun-keystone/skills/keystone-rest.md

@@ -0,0 +1,47 @@
+---
+name: keystone-rest
+description: Endpoints REST/Express sobre Keystone 6 — el controller valida el input con Zod safeParse y delega a un service que usa context.sudo().db. Aplica al crear o tocar una ruta, un controller o un service REST.
+type: reference
+---
+
+# Keystone REST — controller fino, service con la lógica
+
+Keystone expone GraphQL, pero un backend suele montar además rutas REST/Express (vía `extendExpressApp` o un router propio) para webhooks, integraciones y endpoints a medida. La regla: el **controller** solo habla HTTP; la **lógica de datos vive en un service** que usa el `context` de Keystone.
+
+## Cuándo usar este skill
+
+Al crear o tocar una ruta REST, su controller o el service que hay detrás; o al depurar un endpoint que valida mal, filtra de más o expone internals.
+
+## El patrón
+
+```ts
+// controller — SOLO HTTP: valida el borde y delega. Nunca lógica de negocio aquí.
+export async function createReport(req: Request, res: Response) {
+  const parsed = CreateReportSchema.safeParse(req.body); // safeParse, NUNCA parse
+  if (!parsed.success) return sendError(res, "Input inválido", 422);
+  const report = await reportService.create(parsed.data, req.context);
+  return sendSuccess(res, { data: report }, 201);
+}
+
+// service — la lógica; recibe context, no (req, res). context.sudo().db, no context.db.
+export const reportService = {
+  /** Crea un Report aplicando las reglas de negocio (no el access de la sesión). */
+  async create(input: CreateReportInput, context: Context) {
+    return context.sudo().db.Report.createOne({ data: input });
+  },
+};
+```
+
+## Reglas duras
+
+1. **`safeParse`, nunca `parse`.** El input HTTP es hostil: valídalo con el schema Zod y responde 4xx ante el fallo; una excepción sin capturar se fuga como 500.
+2. **Controller fino.** El controller no accede a la DB ni implementa reglas: parsea, delega al service, formatea la respuesta. Toda la lógica testeable vive en el service.
+3. **El service recibe `context`, no `req`/`res`.** Así se testea sin HTTP y se reusa desde otro controller, un hook o un job. Dentro usa `context.sudo().db` (ver `keystone-access` para el porqué de `sudo`).
+4. **Errores sin internals.** Nunca devuelvas stacktraces, SQL ni mensajes de librería al cliente; loguea el detalle y responde un mensaje acotado con su código.
+5. **Respuestas consistentes.** Éxito y error pasan por un formateador único (un `sendSuccess`/`sendError` o equivalente), no por `res.json` suelto en cada controller.
+
+## Antes de declarar el cambio "listo"
+
+- Ningún controller llama a `.parse(` sobre el input HTTP (búscalo: debe ser `safeParse`).
+- Ningún controller usa `context.db.` directo — la lógica está en un service con `context.sudo().db`.
+- El service nuevo/tocado tiene unit tests (recibe un `context` mockeado; ver `keystone-testing`).

package/dist/assets/core/core-assets/presets/bun-keystone/skills/keystone-testing.md

@@ -0,0 +1,72 @@
+---
+name: keystone-testing
+description: Testing de Keystone 6 con Vitest — hooks y access con context mockeado, endpoints GraphQL/REST con Supertest, factories. Aplica al escribir o revisar tests de models, access, hooks o API.
+type: reference
+---
+
+# Keystone Testing — Vitest + Supertest
+
+Dos niveles: **unit** (hooks/access/services con el `context` de Keystone mockeado, sin DB) e **integration/e2e** (API GraphQL/REST real con Supertest contra una instancia de Keystone y una DB de test). El unit es rápido y cubre la lógica; el integration cubre el contrato.
+
+## Cuándo usar este skill
+
+Al escribir tests para un hook, una función de `access/`, un service o un endpoint; al elegir el nivel (unit vs integration); o al depurar un test flaky de mocks.
+
+## Unit — hooks y access con context mockeado
+
+Los hooks y las funciones de access son funciones puras sobre `{ session, context, ... }`: se testean sin DB, mockeando el `context`.
+
+```ts
+// El mock de context expone sudo().db.<Model> y query; devuélvelo desde un helper reusable.
+const context = makeMockContext({ session: adminSession });
+
+it("validateInput rechaza truthState manual", async () => {
+  await expect(
+    Report.hooks.validateInput({ resolvedData: { truthState: "TRUE" }, operation: "create", context }),
+  ).rejects.toThrow();
+});
+
+it("access.filter.query acota a los registros del dueño", () => {
+  expect(reportAccess.filter.query({ session: userSession })).toEqual({
+    author: { id: { equals: userSession.itemId } },
+  });
+});
+```
+
+Testea **cada capa de access por separado** (`operation`/`filter`/`field`) y **la sesión nula** (debe negar/filtrar, nunca abrir).
+
+## Integration — API con Supertest
+
+Levanta Keystone contra una DB de test y golpea el endpoint real (valida el contrato completo: access + hooks + resolvers).
+
+```ts
+const res = await request(app)
+  .post("/api/graphql")
+  .set("Cookie", authCookie)
+  .send({ query: `mutation { createReport(data: {...}) { id } }` });
+expect(res.status).toBe(200);
+expect(res.body.errors).toBeUndefined();
+```
+
+La DB de test se levanta/migra/siembra antes y se derriba después (scripts `test:db:*` / `test:e2e`). Requiere Docker.
+
+## Reglas duras
+
+1. **Factories, no fixtures inline.** Centraliza la construcción de datos de test en factories (`test-factories`) y la sesión en helpers (`test-auth`); no repitas objetos `session`/`data` en cada archivo.
+2. **Un mock de context reusable.** El mock de `context` (con `sudo().db`) vive en un helper compartido, no re-inventado por test.
+3. **Access probado en las 3 capas + sesión nula.** Es el código más sensible; cada capa y el caso sin sesión tienen su test.
+4. **Trazabilidad SDD.** En features SDD-scope, cada `R<n>` se cubre con ≥1 test que lo referencia en nombre o comentario `// Covers: R<n>`.
+5. **No generar tests salvo que se pidan** (si el proyecto así lo define); cuando se piden, van al nivel correcto (unit para lógica, integration para contrato).
+
+## Gotchas de Vitest (v4.x)
+
+- **`vi.hoisted()`** para factories que usan variables externas dentro de `vi.mock` (el mock se hoistea sobre las declaraciones).
+- **Mock-constructor con función regular, no arrow** (una arrow no es `new`-able).
+- **`vi.clearAllMocks()` NO limpia implementaciones** (solo `mock.calls`); usa `vi.resetAllMocks()`/`restoreAllMocks()` cuando necesites resetear la implementación.
+
+## Antes de declarar listo
+
+- Los hooks/access nuevos o tocados tienen unit tests (incluida la sesión nula).
+- Los datos de test salen de factories; el context sale del mock compartido.
+- Si es SDD-scope, cada `R<n>` es trazable a un test.
+- `{{qualityGate.fast}}` en verde (los tests con Docker corren con el gate completo).

package/dist/assets/core/core-assets/presets/bun-keystone/skills/prisma-keystone.md

@@ -0,0 +1,45 @@
+---
+name: prisma-keystone
+description: Prisma bajo Keystone 6 — schema.prisma autogenerado (no editar a mano), migraciones vía keystone prisma migrate, y context.prisma solo en scripts. Aplica al cambiar la forma de datos o correr migraciones.
+type: reference
+---
+
+# Prisma bajo Keystone
+
+## Cuándo usar este skill
+
+Al agregar/cambiar un field o una list (cambia la forma de la BD), al correr o revisar migraciones, o al escribir un script de seed/backfill. El error clásico es editar `schema.prisma` o `schema.graphql` a mano — ambos son artefactos generados y tu cambio se pierde en la siguiente generación.
+
+## Regla base: el schema es derivado, no fuente
+
+- **`schema.prisma` y `schema.graphql` son autogenerados por Keystone** a partir de las lists. La fuente de verdad son los archivos de `models/`. **Nunca los edites a mano.**
+- Para cambiar la BD: edita la list (field nuevo, cambio de tipo, relación), regenera y migra. Keystone reescribe el schema.
+- No leas `schema.prisma` completo para "entender los tipos" — infiérelos desde la list o busca con `grep`. Es largo y derivado.
+
+## Migraciones (vía Keystone, no Prisma directo)
+
+```bash
+# Desarrollo: genera + aplica una migración a partir del cambio en las lists
+keystone prisma migrate dev --name <descripcion-corta>
+
+# Producción / deploy: aplica migraciones ya generadas
+keystone prisma migrate deploy
+```
+
+Usa siempre `keystone prisma ...` (respeta la config de Keystone), no `prisma migrate` suelto. Revisa el SQL generado antes de commitear la migración: una migración destructiva (drop de columna con datos) necesita un plan de datos, no solo el cambio de schema.
+
+## context.prisma — solo en scripts
+
+```ts
+context.sudo().db.Model;  // runtime de la app (hooks/services) — ver keystone-models
+context.prisma;           // SOLO scripts de seed/migración/backfill — nunca en runtime
+```
+
+`context.prisma` te da el cliente Prisma crudo (sin access ni hooks de Keystone). Es la herramienta correcta para un seed o un backfill masivo, y la herramienta incorrecta dentro de un hook o un resolver — ahí siempre `context.sudo().db`.
+
+## Antes de declarar el cambio "listo"
+
+- `{{qualityGate.fast}}` en verde.
+- Ni `schema.prisma` ni `schema.graphql` fueron editados a mano (aparecen solo como salida de la regeneración).
+- Toda migración nueva está commiteada junto al cambio de la list que la origina.
+- Ningún `context.prisma` fuera de `scripts/`.

package/dist/assets/core/core-assets/presets/bun-keystone.json

@@ -0,0 +1,44 @@
+{
+  "$schema": "https://navori.dev/schema/navori.preset.v1.json",
+  "id": "bun-keystone",
+  "displayName": "Keystone 6 backend (Bun + Prisma)",
+  "extends": "core",
+  "extras": {
+    "managed": [
+      {
+        "id": "stack-bun-keystone",
+        "relPath": "presets/bun-keystone/managed/stack.md"
+      }
+    ],
+    "agents": [],
+    "skills": [
+      {
+        "id": "keystone-models",
+        "relPath": "presets/bun-keystone/skills/keystone-models.md",
+        "destRelPath": ".claude/skills/keystone-models.md"
+      },
+      {
+        "id": "keystone-access",
+        "relPath": "presets/bun-keystone/skills/keystone-access.md",
+        "destRelPath": ".claude/skills/keystone-access.md"
+      },
+      {
+        "id": "prisma-keystone",
+        "relPath": "presets/bun-keystone/skills/prisma-keystone.md",
+        "destRelPath": ".claude/skills/prisma-keystone.md"
+      },
+      {
+        "id": "keystone-testing",
+        "relPath": "presets/bun-keystone/skills/keystone-testing.md",
+        "destRelPath": ".claude/skills/keystone-testing.md"
+      },
+      {
+        "id": "keystone-rest",
+        "relPath": "presets/bun-keystone/skills/keystone-rest.md",
+        "destRelPath": ".claude/skills/keystone-rest.md"
+      }
+    ],
+    "hooks": []
+  },
+  "invariants": ["allowAll", "context.sudo()", "validateInput"]
+}