better-chatbot-patterns

What this skill does

# better-chatbot-patterns

**Status**: Production Ready
**Last Updated**: 2025-10-29
**Dependencies**: None
**Latest Versions**: [email protected], [email protected], [email protected], [email protected]

---

## Overview

This skill extracts reusable patterns from the better-chatbot project for use in custom AI chatbot implementations. Unlike the `better-chatbot` skill (which teaches project conventions), this skill provides **portable templates** you can adapt to any project.

**Patterns included**:
1. Server action validators (auth, validation, FormData)
2. Tool abstraction system (multi-type tool handling)
3. Multi-AI provider setup
4. Workflow execution patterns
5. State management conventions

---

## Pattern 1: Server Action Validators

### The Problem
Manual server action auth and validation leads to:
- Inconsistent auth checks
- Repeated FormData parsing boilerplate
- Non-standard error handling
- Type safety issues

### The Solution: Validated Action Utilities

Create `lib/action-utils.ts`:

```typescript
import { z } from "zod"

// Type for action result
type ActionResult<T> =
  | { success: true; data: T }
  | { success: false; error: string }

// Pattern 1: Simple validation (no auth)
export function validatedAction<TSchema extends z.ZodType>(
  schema: TSchema,
  handler: (
    data: z.infer<TSchema>,
    formData: FormData
  ) => Promise<ActionResult<any>>
) {
  return async (formData: FormData): Promise<ActionResult<any>> => {
    try {
      const rawData = Object.fromEntries(formData.entries())
      const parsed = schema.safeParse(rawData)

      if (!parsed.success) {
        return { success: false, error: parsed.error.errors[0].message }
      }

      return await handler(parsed.data, formData)
    } catch (error) {
      return { success: false, error: String(error) }
    }
  }
}

// Pattern 2: With user context (adapt getUser() to your auth system)
export function validatedActionWithUser<TSchema extends z.ZodType>(
  schema: TSchema,
  handler: (
    data: z.infer<TSchema>,
    formData: FormData,
    user: { id: string; email: string } // Adapt to your User type
  ) => Promise<ActionResult<any>>
) {
  return async (formData: FormData): Promise<ActionResult<any>> => {
    try {
      // Adapt this to your auth system (Better Auth, Clerk, Auth.js, etc.)
      const user = await getUser()
      if (!user) {
        return { success: false, error: "Unauthorized" }
      }

      const rawData = Object.fromEntries(formData.entries())
      const parsed = schema.safeParse(rawData)

      if (!parsed.success) {
        return { success: false, error: parsed.error.errors[0].message }
      }

      return await handler(parsed.data, formData, user)
    } catch (error) {
      return { success: false, error: String(error) }
    }
  }
}

// Pattern 3: With permission check (adapt to your roles system)
export function validatedActionWithPermission<TSchema extends z.ZodType>(
  schema: TSchema,
  permission: "admin" | "user-manage" | string, // Your permission types
  handler: (
    data: z.infer<TSchema>,
    formData: FormData,
    user: { id: string; email: string; role: string }
  ) => Promise<ActionResult<any>>
) {
  return async (formData: FormData): Promise<ActionResult<any>> => {
    try {
      const user = await getUser()
      if (!user) {
        return { success: false, error: "Unauthorized" }
      }

      // Adapt this to your permission system
      const hasPermission = await checkPermission(user, permission)
      if (!hasPermission) {
        return { success: false, error: "Forbidden" }
      }

      const rawData = Object.fromEntries(formData.entries())
      const parsed = schema.safeParse(rawData)

      if (!parsed.success) {
        return { success: false, error: parsed.error.errors[0].message }
      }

      return await handler(parsed.data, formData, user)
    } catch (error) {
      return { success: false, error: String(error) }
    }
  }
}

// Placeholder functions - replace with your auth system
async function getUser() {
  // Better Auth: await auth()
  // Clerk: const { userId } = auth(); if (!userId) return null; return await currentUser()
  // Auth.js: const session = await getServerSession(); return session?.user
  throw new Error("Implement getUser() with your auth provider")
}

async function checkPermission(user: any, permission: string) {
  // Implement based on your role system
  throw new Error("Implement checkPermission() with your role system")
}
```

### Usage Example

```typescript
// app/actions/profile.ts
"use server"

import { validatedActionWithUser } from "@/lib/action-utils"
import { z } from "zod"
import { db } from "@/lib/db"

const updateProfileSchema = z.object({
  name: z.string().min(1),
  email: z.string().email()
})

export const updateProfile = validatedActionWithUser(
  updateProfileSchema,
  async (data, formData, user) => {
    // user is guaranteed authenticated
    // data is validated and typed
    await db.update(users).set(data).where(eq(users.id, user.id))
    return { success: true, data: { updated: true } }
  }
)
```

**When to use**:
- Any server action requiring auth
- Form submissions needing validation
- Preventing inconsistent error handling

---

## Pattern 2: Tool Abstraction System

### The Problem
Handling multiple tool types (MCP, Workflow, Default) with different execution patterns leads to:
- Type mismatches at runtime
- Repeated type checking boilerplate
- Difficulty adding new tool types

### The Solution: Branded Type Tags

Create `lib/tool-tags.ts`:

```typescript
// Branded type system for runtime type narrowing
export class ToolTag<T extends string> {
  private readonly _tag: T
  private readonly _branded: unique symbol

  private constructor(tag: T) {
    this._tag = tag
  }

  static create<TTag extends string>(tag: TTag) {
    return new ToolTag(tag) as ToolTag<TTag>
  }

  is(tag: string): boolean {
    return this._tag === tag
  }

  get tag(): T {
    return this._tag
  }
}

// Define your tool types
export type MCPTool = { type: "mcp"; name: string; execute: (...args: any[]) => Promise<any> }
export type WorkflowTool = { type: "workflow"; id: string; nodes: any[] }
export type DefaultTool = { type: "default"; name: string }

// Branded tag system
export const VercelAIMcpToolTag = {
  create: (tool: any) => ({ ...tool, _tag: ToolTag.create("mcp") }),
  isMaybe: (tool: any): tool is MCPTool & { _tag: ToolTag<"mcp"> } =>
    tool?._tag?.is("mcp")
}

export const VercelAIWorkflowToolTag = {
  create: (tool: any) => ({ ...tool, _tag: ToolTag.create("workflow") }),
  isMaybe: (tool: any): tool is WorkflowTool & { _tag: ToolTag<"workflow"> } =>
    tool?._tag?.is("workflow")
}

export const VercelAIDefaultToolTag = {
  create: (tool: any) => ({ ...tool, _tag: ToolTag.create("default") }),
  isMaybe: (tool: any): tool is DefaultTool & { _tag: ToolTag<"default"> } =>
    tool?._tag?.is("default")
}
```

### Usage Example

```typescript
// lib/ai/tool-executor.ts
import {
  VercelAIMcpToolTag,
  VercelAIWorkflowToolTag,
  VercelAIDefaultToolTag
} from "@/lib/tool-tags"

async function executeTool(tool: unknown) {
  // Runtime type narrowing with branded tags
  if (VercelAIMcpToolTag.isMaybe(tool)) {
    console.log("Executing MCP tool:", tool.name)
    return await tool.execute()
  } else if (VercelAIWorkflowToolTag.isMaybe(tool)) {
    console.log("Executing workflow:", tool.id)
    return await executeWorkflow(tool.nodes)
  } else if (VercelAIDefaultToolTag.isMaybe(tool)) {
    console.log("Executing default tool:", tool.name)
    return await executeDefault(tool)
  }

  throw new Error("Unknown tool type")
}

// When creating tools, tag them
const mcpTool = VercelAIMcpToolTag.create({
  type: "mcp",
  name: "search",
  execute: async () => { /* ... */ }
})

const workflowTool = VercelAIWorkflowToolTag.create({
  type: "workflow",
  id: "workflow-123",
  nodes: []
})
```

**When to use**:
- Multi-type tool systems
- Runtime type checking needed
- Adding extensible too