create-inox-app 0.1.0

package/dist/templates/claude-config/app/.agents/skills/vercel-react-best-practices/rules/server-after-nonblocking.md

@@ -0,0 +1,73 @@
+---
+title: Use after() for Non-Blocking Operations
+impact: MEDIUM
+impactDescription: faster response times
+tags: server, async, logging, analytics, side-effects
+---
+
+## Use after() for Non-Blocking Operations
+
+Use Next.js's `after()` to schedule work that should execute after a response is sent. This prevents logging, analytics, and other side effects from blocking the response.
+
+**Incorrect (blocks response):**
+
+```tsx
+import { logUserAction } from "@/app/utils";
+
+export async function POST(request: Request) {
+  // Perform mutation
+  await updateDatabase(request);
+
+  // Logging blocks the response
+  const userAgent = request.headers.get("user-agent") || "unknown";
+  await logUserAction({ userAgent });
+
+  return new Response(JSON.stringify({ status: "success" }), {
+    status: 200,
+    headers: { "Content-Type": "application/json" },
+  });
+}
+```
+
+**Correct (non-blocking):**
+
+```tsx
+import { after } from "next/server";
+import { headers, cookies } from "next/headers";
+import { logUserAction } from "@/app/utils";
+
+export async function POST(request: Request) {
+  // Perform mutation
+  await updateDatabase(request);
+
+  // Log after response is sent
+  after(async () => {
+    const userAgent = (await headers()).get("user-agent") || "unknown";
+    const sessionCookie = (await cookies()).get("session-id")?.value || "anonymous";
+
+    logUserAction({ sessionCookie, userAgent });
+  });
+
+  return new Response(JSON.stringify({ status: "success" }), {
+    status: 200,
+    headers: { "Content-Type": "application/json" },
+  });
+}
+```
+
+The response is sent immediately while logging happens in the background.
+
+**Common use cases:**
+
+- Analytics tracking
+- Audit logging
+- Sending notifications
+- Cache invalidation
+- Cleanup tasks
+
+**Important notes:**
+
+- `after()` runs even if the response fails or redirects
+- Works in Server Actions, Route Handlers, and Server Components
+
+Reference: [https://nextjs.org/docs/app/api-reference/functions/after](https://nextjs.org/docs/app/api-reference/functions/after)

package/dist/templates/claude-config/app/.agents/skills/vercel-react-best-practices/rules/server-auth-actions.md

@@ -0,0 +1,96 @@
+---
+title: Authenticate Server Actions Like API Routes
+impact: CRITICAL
+impactDescription: prevents unauthorized access to server mutations
+tags: server, server-actions, authentication, security, authorization
+---
+
+## Authenticate Server Actions Like API Routes
+
+**Impact: CRITICAL (prevents unauthorized access to server mutations)**
+
+Server Actions (functions with `"use server"`) are exposed as public endpoints, just like API routes. Always verify authentication and authorization **inside** each Server Action—do not rely solely on middleware, layout guards, or page-level checks, as Server Actions can be invoked directly.
+
+Next.js documentation explicitly states: "Treat Server Actions with the same security considerations as public-facing API endpoints, and verify if the user is allowed to perform a mutation."
+
+**Incorrect (no authentication check):**
+
+```typescript
+"use server";
+
+export async function deleteUser(userId: string) {
+  // Anyone can call this! No auth check
+  await db.user.delete({ where: { id: userId } });
+  return { success: true };
+}
+```
+
+**Correct (authentication inside the action):**
+
+```typescript
+"use server";
+
+import { verifySession } from "@/lib/auth";
+import { unauthorized } from "@/lib/errors";
+
+export async function deleteUser(userId: string) {
+  // Always check auth inside the action
+  const session = await verifySession();
+
+  if (!session) {
+    throw unauthorized("Must be logged in");
+  }
+
+  // Check authorization too
+  if (session.user.role !== "admin" && session.user.id !== userId) {
+    throw unauthorized("Cannot delete other users");
+  }
+
+  await db.user.delete({ where: { id: userId } });
+  return { success: true };
+}
+```
+
+**With input validation:**
+
+```typescript
+"use server";
+
+import { verifySession } from "@/lib/auth";
+import { z } from "zod";
+
+const updateProfileSchema = z.object({
+  userId: z.string().uuid(),
+  name: z.string().min(1).max(100),
+  email: z.string().email(),
+});
+
+export async function updateProfile(data: unknown) {
+  // Validate input first
+  const validated = updateProfileSchema.parse(data);
+
+  // Then authenticate
+  const session = await verifySession();
+  if (!session) {
+    throw new Error("Unauthorized");
+  }
+
+  // Then authorize
+  if (session.user.id !== validated.userId) {
+    throw new Error("Can only update own profile");
+  }
+
+  // Finally perform the mutation
+  await db.user.update({
+    where: { id: validated.userId },
+    data: {
+      name: validated.name,
+      email: validated.email,
+    },
+  });
+
+  return { success: true };
+}
+```
+
+Reference: [https://nextjs.org/docs/app/guides/authentication](https://nextjs.org/docs/app/guides/authentication)

package/dist/templates/claude-config/app/.agents/skills/vercel-react-best-practices/rules/server-cache-lru.md

@@ -0,0 +1,41 @@
+---
+title: Cross-Request LRU Caching
+impact: HIGH
+impactDescription: caches across requests
+tags: server, cache, lru, cross-request
+---
+
+## Cross-Request LRU Caching
+
+`React.cache()` only works within one request. For data shared across sequential requests (user clicks button A then button B), use an LRU cache.
+
+**Implementation:**
+
+```typescript
+import { LRUCache } from "lru-cache";
+
+const cache = new LRUCache<string, any>({
+  max: 1000,
+  ttl: 5 * 60 * 1000, // 5 minutes
+});
+
+export async function getUser(id: string) {
+  const cached = cache.get(id);
+  if (cached) return cached;
+
+  const user = await db.user.findUnique({ where: { id } });
+  cache.set(id, user);
+  return user;
+}
+
+// Request 1: DB query, result cached
+// Request 2: cache hit, no DB query
+```
+
+Use when sequential user actions hit multiple endpoints needing the same data within seconds.
+
+**With Vercel's [Fluid Compute](https://vercel.com/docs/fluid-compute):** LRU caching is especially effective because multiple concurrent requests can share the same function instance and cache. This means the cache persists across requests without needing external storage like Redis.
+
+**In traditional serverless:** Each invocation runs in isolation, so consider Redis for cross-process caching.
+
+Reference: [https://github.com/isaacs/node-lru-cache](https://github.com/isaacs/node-lru-cache)

package/dist/templates/claude-config/app/.agents/skills/vercel-react-best-practices/rules/server-cache-react.md

@@ -0,0 +1,76 @@
+---
+title: Per-Request Deduplication with React.cache()
+impact: MEDIUM
+impactDescription: deduplicates within request
+tags: server, cache, react-cache, deduplication
+---
+
+## Per-Request Deduplication with React.cache()
+
+Use `React.cache()` for server-side request deduplication. Authentication and database queries benefit most.
+
+**Usage:**
+
+```typescript
+import { cache } from "react";
+
+export const getCurrentUser = cache(async () => {
+  const session = await auth();
+  if (!session?.user?.id) return null;
+  return await db.user.findUnique({
+    where: { id: session.user.id },
+  });
+});
+```
+
+Within a single request, multiple calls to `getCurrentUser()` execute the query only once.
+
+**Avoid inline objects as arguments:**
+
+`React.cache()` uses shallow equality (`Object.is`) to determine cache hits. Inline objects create new references each call, preventing cache hits.
+
+**Incorrect (always cache miss):**
+
+```typescript
+const getUser = cache(async (params: { uid: number }) => {
+  return await db.user.findUnique({ where: { id: params.uid } });
+});
+
+// Each call creates new object, never hits cache
+getUser({ uid: 1 });
+getUser({ uid: 1 }); // Cache miss, runs query again
+```
+
+**Correct (cache hit):**
+
+```typescript
+const getUser = cache(async (uid: number) => {
+  return await db.user.findUnique({ where: { id: uid } });
+});
+
+// Primitive args use value equality
+getUser(1);
+getUser(1); // Cache hit, returns cached result
+```
+
+If you must pass objects, pass the same reference:
+
+```typescript
+const params = { uid: 1 };
+getUser(params); // Query runs
+getUser(params); // Cache hit (same reference)
+```
+
+**Next.js-Specific Note:**
+
+In Next.js, the `fetch` API is automatically extended with request memoization. Requests with the same URL and options are automatically deduplicated within a single request, so you don't need `React.cache()` for `fetch` calls. However, `React.cache()` is still essential for other async tasks:
+
+- Database queries (Prisma, Drizzle, etc.)
+- Heavy computations
+- Authentication checks
+- File system operations
+- Any non-fetch async work
+
+Use `React.cache()` to deduplicate these operations across your component tree.
+
+Reference: [React.cache documentation](https://react.dev/reference/react/cache)

package/dist/templates/claude-config/app/.agents/skills/vercel-react-best-practices/rules/server-dedup-props.md

@@ -0,0 +1,65 @@
+---
+title: Avoid Duplicate Serialization in RSC Props
+impact: LOW
+impactDescription: reduces network payload by avoiding duplicate serialization
+tags: server, rsc, serialization, props, client-components
+---
+
+## Avoid Duplicate Serialization in RSC Props
+
+**Impact: LOW (reduces network payload by avoiding duplicate serialization)**
+
+RSC→client serialization deduplicates by object reference, not value. Same reference = serialized once; new reference = serialized again. Do transformations (`.toSorted()`, `.filter()`, `.map()`) in client, not server.
+
+**Incorrect (duplicates array):**
+
+```tsx
+// RSC: sends 6 strings (2 arrays × 3 items)
+<ClientList usernames={usernames} usernamesOrdered={usernames.toSorted()} />
+```
+
+**Correct (sends 3 strings):**
+
+```tsx
+// RSC: send once
+<ClientList usernames={usernames} />;
+
+// Client: transform there
+("use client");
+const sorted = useMemo(() => [...usernames].sort(), [usernames]);
+```
+
+**Nested deduplication behavior:**
+
+Deduplication works recursively. Impact varies by data type:
+
+- `string[]`, `number[]`, `boolean[]`: **HIGH impact** - array + all primitives fully duplicated
+- `object[]`: **LOW impact** - array duplicated, but nested objects deduplicated by reference
+
+```tsx
+// string[] - duplicates everything
+usernames={['a','b']} sorted={usernames.toSorted()} // sends 4 strings
+
+// object[] - duplicates array structure only
+users={[{id:1},{id:2}]} sorted={users.toSorted()} // sends 2 arrays + 2 unique objects (not 4)
+```
+
+**Operations breaking deduplication (create new references):**
+
+- Arrays: `.toSorted()`, `.filter()`, `.map()`, `.slice()`, `[...arr]`
+- Objects: `{...obj}`, `Object.assign()`, `structuredClone()`, `JSON.parse(JSON.stringify())`
+
+**More examples:**
+
+```tsx
+// ❌ Bad
+<C users={users} active={users.filter(u => u.active)} />
+<C product={product} productName={product.name} />
+
+// ✅ Good
+<C users={users} />
+<C product={product} />
+// Do filtering/destructuring in client
+```
+
+**Exception:** Pass derived data when transformation is expensive or client doesn't need original.

package/dist/templates/claude-config/app/.agents/skills/vercel-react-best-practices/rules/server-parallel-fetching.md

@@ -0,0 +1,83 @@
+---
+title: Parallel Data Fetching with Component Composition
+impact: CRITICAL
+impactDescription: eliminates server-side waterfalls
+tags: server, rsc, parallel-fetching, composition
+---
+
+## Parallel Data Fetching with Component Composition
+
+React Server Components execute sequentially within a tree. Restructure with composition to parallelize data fetching.
+
+**Incorrect (Sidebar waits for Page's fetch to complete):**
+
+```tsx
+export default async function Page() {
+  const header = await fetchHeader();
+  return (
+    <div>
+      <div>{header}</div>
+      <Sidebar />
+    </div>
+  );
+}
+
+async function Sidebar() {
+  const items = await fetchSidebarItems();
+  return <nav>{items.map(renderItem)}</nav>;
+}
+```
+
+**Correct (both fetch simultaneously):**
+
+```tsx
+async function Header() {
+  const data = await fetchHeader();
+  return <div>{data}</div>;
+}
+
+async function Sidebar() {
+  const items = await fetchSidebarItems();
+  return <nav>{items.map(renderItem)}</nav>;
+}
+
+export default function Page() {
+  return (
+    <div>
+      <Header />
+      <Sidebar />
+    </div>
+  );
+}
+```
+
+**Alternative with children prop:**
+
+```tsx
+async function Header() {
+  const data = await fetchHeader();
+  return <div>{data}</div>;
+}
+
+async function Sidebar() {
+  const items = await fetchSidebarItems();
+  return <nav>{items.map(renderItem)}</nav>;
+}
+
+function Layout({ children }: { children: ReactNode }) {
+  return (
+    <div>
+      <Header />
+      {children}
+    </div>
+  );
+}
+
+export default function Page() {
+  return (
+    <Layout>
+      <Sidebar />
+    </Layout>
+  );
+}
+```

package/dist/templates/claude-config/app/.agents/skills/vercel-react-best-practices/rules/server-serialization.md

@@ -0,0 +1,38 @@
+---
+title: Minimize Serialization at RSC Boundaries
+impact: HIGH
+impactDescription: reduces data transfer size
+tags: server, rsc, serialization, props
+---
+
+## Minimize Serialization at RSC Boundaries
+
+The React Server/Client boundary serializes all object properties into strings and embeds them in the HTML response and subsequent RSC requests. This serialized data directly impacts page weight and load time, so **size matters a lot**. Only pass fields that the client actually uses.
+
+**Incorrect (serializes all 50 fields):**
+
+```tsx
+async function Page() {
+  const user = await fetchUser(); // 50 fields
+  return <Profile user={user} />;
+}
+
+("use client");
+function Profile({ user }: { user: User }) {
+  return <div>{user.name}</div>; // uses 1 field
+}
+```
+
+**Correct (serializes only 1 field):**
+
+```tsx
+async function Page() {
+  const user = await fetchUser();
+  return <Profile name={user.name} />;
+}
+
+("use client");
+function Profile({ name }: { name: string }) {
+  return <div>{name}</div>;
+}
+```

package/dist/templates/claude-config/app/.agents/skills/web-design-guidelines/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: web-design-guidelines
+description: Review UI code for Web Interface Guidelines compliance. Use when asked to "review my UI", "check accessibility", "audit design", "review UX", or "check my site against best practices".
+metadata:
+  author: vercel
+  version: "1.0.0"
+  argument-hint: <file-or-pattern>
+---
+
+# Web Interface Guidelines
+
+Review files for compliance with Web Interface Guidelines.
+
+## How It Works
+
+1. Fetch the latest guidelines from the source URL below
+2. Read the specified files (or prompt user for files/pattern)
+3. Check against all rules in the fetched guidelines
+4. Output findings in the terse `file:line` format
+
+## Guidelines Source
+
+Fetch fresh guidelines before each review:
+
+```
+https://raw.githubusercontent.com/vercel-labs/web-interface-guidelines/main/command.md
+```
+
+Use WebFetch to retrieve the latest rules. The fetched content contains all the rules and output format instructions.
+
+## Usage
+
+When a user provides a file or pattern argument:
+
+1. Fetch guidelines from the source URL above
+2. Read the specified files
+3. Apply all rules from the fetched guidelines
+4. Output findings using the format specified in the guidelines
+
+If no files specified, ask the user which files to review.

package/dist/templates/claude-config/app/.agents/skills/workflow/SKILL.md

@@ -0,0 +1,181 @@
+---
+name: workflow
+description: Creates durable, resumable workflows using Vercel's Workflow DevKit. Use when building workflows that need to survive restarts, pause for external events, retry on failure, or coordinate multi-step operations over time. Triggers on mentions of "workflow", "durable functions", "resumable", "workflow devkit", or step-based orchestration.
+metadata:
+  author: Vercel Inc.
+  version: '1.0'
+---
+
+## *CRITICAL*: Always Use Correct `workflow` Documentation
+
+Your knowledge of `workflow` is outdated.
+
+The `workflow` documentation outlined below matches the installed version of the Workflow DevKit.
+Follow these instructions before starting on any `workflow`-related tasks:
+
+Search the bundled documentation in `node_modules/workflow/docs/`:
+
+1. **Find docs**: `glob "node_modules/workflow/docs/**/*.mdx"`
+2. **Search content**: `grep "your query" node_modules/workflow/docs/`
+
+Documentation structure in `node_modules/workflow/docs/`:
+
+- `getting-started/` - Framework setup (next.mdx, express.mdx, hono.mdx, etc.)
+- `foundations/` - Core concepts (workflows-and-steps.mdx, hooks.mdx, streaming.mdx, etc.)
+- `api-reference/workflow/` - API docs (sleep.mdx, create-hook.mdx, fatal-error.mdx, etc.)
+- `api-reference/workflow-api/` - Client API (start.mdx, get-run.mdx, resume-hook.mdx, etc.)
+- `ai/` - AI SDK integration docs
+- `errors/` - Error code documentation
+
+Related packages also include bundled docs:
+
+- `@workflow/ai`: `node_modules/@workflow/ai/docs/` - DurableAgent and AI integration
+- `@workflow/core`: `node_modules/@workflow/core/docs/` - Core runtime (foundations, how-it-works)
+- `@workflow/next`: `node_modules/@workflow/next/docs/` - Next.js integration
+
+**When in doubt, update to the latest version of the Workflow DevKit.**
+
+### Official Resources
+
+- **Website**: https://useworkflow.dev
+- **GitHub**: https://github.com/vercel/workflow
+
+### Quick Reference
+
+**Directives:**
+
+```typescript
+"use workflow";  // First line - makes async function durable
+"use step";      // First line - makes function a cached, retryable unit
+```
+
+**Essential imports:**
+
+```typescript
+// Workflow primitives
+import { sleep, fetch, createHook, createWebhook, getWritable } from "workflow";
+import { FatalError, RetryableError } from "workflow";
+import { getWorkflowMetadata, getStepMetadata } from "workflow";
+
+// API operations
+import { start, getRun, resumeHook, resumeWebhook } from "workflow/api";
+
+// Framework integrations
+import { withWorkflow } from "workflow/next";
+import { workflow } from "workflow/vite";
+import { workflow } from "workflow/astro";
+// Or use modules: ["workflow/nitro"] for Nitro/Nuxt
+```
+
+## Prefer Step Functions to Avoid Sandbox Errors
+
+`"use workflow"` functions run in a sandboxed VM. `"use step"` functions have **full Node.js access**. Put your logic in steps and use the workflow function purely for orchestration.
+
+```typescript
+// Steps have full Node.js and npm access
+async function fetchUserData(userId: string) {
+  "use step";
+  const response = await fetch(`https://api.example.com/users/${userId}`);
+  return response.json();
+}
+
+async function processWithAI(data: any) {
+  "use step";
+  // AI SDK works in steps without workarounds
+  return await generateText({
+    model: openai("gpt-4"),
+    prompt: `Process: ${JSON.stringify(data)}`,
+  });
+}
+
+// Workflow orchestrates steps - no sandbox issues
+export async function dataProcessingWorkflow(userId: string) {
+  "use workflow";
+  const data = await fetchUserData(userId);
+  const processed = await processWithAI(data);
+  return { success: true, processed };
+}
+```
+
+**Benefits:** Steps have automatic retry, results are persisted for replay, and no sandbox restrictions.
+
+## Workflow Sandbox Limitations
+
+When you need logic directly in a workflow function (not in a step), these restrictions apply:
+
+| Limitation | Workaround |
+|------------|------------|
+| No `fetch()` | `import { fetch } from "workflow"` then `globalThis.fetch = fetch` |
+| No `setTimeout`/`setInterval` | Use `sleep("5s")` from `"workflow"` |
+| No Node.js modules (fs, crypto, etc.) | Move to a step function |
+
+**Example - Using fetch in workflow context:**
+
+```typescript
+import { fetch } from "workflow";
+
+export async function myWorkflow() {
+  "use workflow";
+  globalThis.fetch = fetch;  // Required for AI SDK and HTTP libraries
+  // Now generateText() and other libraries work
+}
+```
+
+**Note:** `DurableAgent` from `@workflow/ai` handles the fetch assignment automatically.
+
+## Error Handling
+
+Use `FatalError` for permanent failures (no retry), `RetryableError` for transient failures:
+
+```typescript
+import { FatalError, RetryableError } from "workflow";
+
+if (res.status >= 400 && res.status < 500) {
+  throw new FatalError(`Client error: ${res.status}`);
+}
+if (res.status === 429) {
+  throw new RetryableError("Rate limited", { retryAfter: "5m" });
+}
+```
+
+## Serialization
+
+All data passed to/from workflows and steps must be serializable.
+
+**Supported types:** string, number, boolean, null, undefined, bigint, plain objects, arrays, Date, RegExp, URL, URLSearchParams, Map, Set, Headers, ArrayBuffer, typed arrays, Request, Response, ReadableStream, WritableStream.
+
+**Not supported:** Functions, class instances, Symbols, WeakMap/WeakSet. Pass data, not callbacks.
+
+## Streaming
+
+Use `getWritable()` in step functions to stream data:
+
+```typescript
+async function streamData() {
+  "use step";  // Required - streaming only works in steps
+  const writer = getWritable();
+  await writer.write(data);
+  writer.releaseLock();  // Always release the lock
+}
+
+// Close when done
+await getWritable().close();
+```
+
+## Debugging
+
+```bash
+# Check workflow endpoints are reachable
+npx workflow health
+npx workflow health --port 3001  # Non-default port
+
+# Visual dashboard for runs
+npx workflow web
+npx workflow web --app-url http://localhost:3001
+
+# CLI inspection (for agents)
+npx workflow inspect runs
+npx workflow inspect run <run_id>
+```
+
+**Tip:** Only import workflow APIs you actually use. Unused imports can cause 500 errors.