kavo: Skill for Claude Code

Integrating @kavo/next

@kavo/next binds Kavo to the Next.js App Router: createKavoHandler turns one or more createCrud results into GET/POST/PUT/PATCH/DELETE route-handler exports for a catch-all route. There's no decorator, no DI container, and no dependency on @kavo/nest — App Router route handlers are plain functions over the Fetch API's Request/Response.

The three pieces every integration needs

1. Wire entities where the app's Kavo setup lives — call createCrud directly, once per entity, same as with any other framework binding:

   // kavo.ts
   import { createKavo } from "@kavo/core";
   import { createInfrastructure } from "@kavo/typeorm";
   import { dataSource } from "./data-source";
   import { User } from "./user.entity";
   
   const kavo = createKavo({ infrastructure: createInfrastructure(dataSource) });
   export const users = kavo.createCrud(User, { filter: { fields: ["id", "email"] } });
   

   Any ORM adapter works the same way here as with @kavo/nest — @kavo/typeorm, @kavo/prisma, @kavo/mongoose, @kavo/mikroorm all produce a plain createCrud result with nothing framework-specific.

2. Mount the catch-all route — one file, one call:

   // app/api/[...kavo]/route.ts
   import { createKavoHandler } from "@kavo/next";
   import { users, projects } from "../../../kavo";
   
   export const { GET, POST, PUT, PATCH, DELETE } = createKavoHandler({ users, projects });
   

   The first path segment resolves the entity by its key in this map (users → the users service); the rest resolves the operation by matching the request's method and remaining segments against that entity's own operation registry — the same registry @kavo/nest's @Kavo decorator reads. An unknown entity key, or a method/segment combination no enabled operation resolves to, answers 404 — never 500, never a bare 405 (see ADR-0054 for why resolution happens at request time).