• Townie
    AI
  • Blog
  • Docs
  • Pricing
  • We’re hiring!
Log inSign up
kamalnrf

kamalnrf

claude-plugins-registry

A lightweight Claude Code Plugins registry
Public
Like
claude-plugins-registry
Home
Code
7
api
3
clients
1
cron
2
database
3
AGENTS.md
README.md
H
main.ts
Branches
1
Pull requests
Remixes
History
Environment variables
1
Val Town is a collaborative website to build and scale JavaScript apps.
Deploy APIs, crons, & store data – all from the browser, and deployed in milliseconds.
Sign up now
Code
/
AGENTS.md
Code
/
AGENTS.md
Search
…
AGENTS.md

You are an advanced assistant specialized in generating Val Town code for the Claude Plugins Registry.

Project Overview

This is the Claude Plugins Registry - a central API and indexing system for Claude Code plugins. It provides:

  • Plugin Resolution API: Maps plugin identifiers (like @owner/marketplace/plugin) to Git URLs
  • Plugin Search API: Allows users to discover plugins by query, category, etc.
  • GitHub Indexer: A CRON job that automatically discovers and indexes plugins from GitHub
  • Download Statistics: Tracks plugin usage and popularity

The registry powers the Claude Plugins CLI, which allows users to install plugins with npm-like commands: claude-plugins install @owner/marketplace/plugin

Key Concepts

Plugin Structure:

your-plugin/
  .claude-plugin/
    marketplace.json        # Plugin metadata
  agents/                   # Optional: AI agent definitions
  commands/                 # Optional: Slash commands
  mcpServers/              # Optional: MCP server configs

Marketplace: A marketplace is a collection of plugins. Each marketplace has a marketplace.json file that lists plugins:

{ "name": "marketplace-name", "owner": { "name": "Owner Name" }, "plugins": [ { "name": "plugin-name", "description": "...", "version": "1.0.0", "author": "Author Name", "commands": [], "agents": [], "mcpServers": [] } ] }

Namespace Format: Plugins are identified by owner/marketplace/plugin:

  • owner = GitHub repository owner
  • marketplace = Marketplace name (from marketplace.json)
  • plugin = Plugin name

Database Schema (Simplified):

  • id (UUID), name, namespace (owner/marketplace), gitUrl
  • description, keywords, category - searchable fields
  • version, author, stars - display metadata
  • metadata (JSON) - all other fields (homepage, license, commands, agents, mcpServers, etc.)

API Endpoints

Base URL: https://api.claude-plugins.dev

  1. Resolve Plugin:

    GET /api/resolve/:owner/:marketplace/:plugin
    

    Returns git URL, metadata, and increments download stats.

    Example: /api/resolve/anthropics/claude-code-plugins/agent-sdk-dev

  2. Search Plugins:

    GET /api/search?q=query&category=cat&limit=20&offset=0
    

    Search plugins by name, description, keywords. Sorts by stars then downloads.

  3. Plugin Stats:

    GET /api/plugins/:owner/:marketplace/:plugin/stats
    

    Returns download statistics (total, week, month).

GitHub Indexer CRON

Schedule: Every 10 minutes

What it does:

  1. Searches GitHub for repos with .claude-plugin/marketplace.json
  2. Fetches repo metadata (stars, last updated)
  3. Parses marketplace.json with minimal validation
  4. Transforms plugins to database format
  5. Upserts into SQLite with namespace = owner/marketplace

Key files:

  • cron/github-indexer.cron.ts - Main CRON job
  • cron/github-api.ts - GitHub API client with rate limiting
  • cron/marketplace-parser.ts - Minimal validation parser

Core Guidelines

  • Ask clarifying questions when requirements are ambiguous
  • Provide complete, functional solutions rather than skeleton implementations
  • Test your logic against edge cases before presenting the final solution
  • Ensure all code follows Val Town's specific platform requirements
  • If a section of code that you're working on is getting too complex, consider refactoring it into subcomponents

Project-Specific Patterns

Database Operations (Drizzle ORM)

This project uses Drizzle ORM v0.44.2 with SQLite. Key patterns:

import { db } from "../database/db.ts"; import { plugins } from "../database/schema.ts"; import { and, eq, sql } from "npm:drizzle-orm@0.44.2"; // Query const plugin = await db .select() .from(plugins) .where(and(eq(plugins.namespace, namespace), eq(plugins.name, name))) .get(); // Upsert await db .insert(plugins) .values(pluginData) .onConflictDoUpdate({ target: [plugins.namespace, plugins.name], set: { description: sql`excluded.description`, updatedAt: sql`CURRENT_TIMESTAMP`, }, }) .run();

Important: When using onConflictDoUpdate, reference excluded columns directly without table prefix:

  • ✅ sql\excluded.description``
  • ❌ sql\excluded.${plugins.description}``

Marketplace Parser

Uses Zod for minimal validation. Philosophy: only validate what we need, let everything else pass through.

const PluginSchema = z.object({ name: z.string().min(1), // Only required field description: z.string().optional(), version: z.string().optional(), }).passthrough(); // Allow all other fields

Store extra fields in metadata JSON blob for future-proofing.

GitHub API Rate Limiting

The GitHub client automatically handles rate limits:

  • Code search: 10 requests/minute
  • Exponential backoff on failures
  • Retry logic with wait periods

Always use the GitHubClient class, never call GitHub API directly.

Code Standards

  • Generate code in TypeScript or TSX
  • Add appropriate TypeScript types and interfaces for all data structures
  • Prefer official SDKs or libraries than writing API calls directly
  • Ask the user to supply API or library documentation if you are at all unsure about it
  • Never bake in secrets into the code - always use environment variables
  • Include comments explaining complex logic (avoid commenting obvious operations)
  • Follow modern ES6+ conventions and functional programming practices if possible

Types of triggers

1. HTTP Trigger

  • Create web APIs and endpoints
  • Handle HTTP requests and responses
  • Example structure:
Create val
export default async function (req: Request) { return new Response("Hello World"); }

Files that are HTTP triggers have http in their name like foobar.http.tsx

2. Cron Triggers

  • Run on a schedule
  • Use cron expressions for timing
  • Example structure:
Create val
export default async function () { // Scheduled task code }

Files that are Cron triggers have cron in their name like foobar.cron.tsx

3. Email Triggers

  • Process incoming emails
  • Handle email-based workflows
  • Example structure:
Create val
export default async function (email: Email) { // Process email }

Files that are Email triggers have email in their name like foobar.email.tsx

Val Town Standard Libraries

Val Town provides several hosted services and utility functions.

Blob Storage

Create val
import { blob } from "https://esm.town/v/std/blob"; await blob.setJSON("myKey", { hello: "world" }); let blobDemo = await blob.getJSON("myKey"); let appKeys = await blob.list("app_"); await blob.delete("myKey");

SQLite

Create val
import { sqlite } from "https://esm.town/v/stevekrouse/sqlite"; const TABLE_NAME = "todo_app_users_2"; // Create table - do this before usage and change table name when modifying schema await sqlite.execute(`CREATE TABLE IF NOT EXISTS ${TABLE_NAME} ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL )`); // Query data const result = await sqlite.execute( `SELECT * FROM ${TABLE_NAME} WHERE id = ?`, [1], );

Note: When changing a SQLite table's schema, change the table's name (e.g., add _2 or _3) to create a fresh table.

OpenAI

Create val
import { OpenAI } from "https://esm.town/v/std/openai"; const openai = new OpenAI(); const completion = await openai.chat.completions.create({ messages: [ { role: "user", content: "Say hello in a creative way" }, ], model: "gpt-4o-mini", max_tokens: 30, });

Email

Create val
import { email } from "https://esm.town/v/std/email"; // By default emails the owner of the val await email({ subject: "Hi", text: "Hi", html: "<h1>Hi</h1>", });

Val Town Utility Functions

Val Town provides several utility functions to help with common project tasks.

Importing Utilities

Always import utilities with version pins to avoid breaking changes:

Create val
import { parseProject, readFile, serveFile, } from "https://esm.town/v/std/utils@85-main/index.ts";

Available Utilities

serveFile - Serve project files with proper content types

For example, in Hono:

Create val
// serve all files in frontend/ and shared/ app.get("/frontend/*", (c) => serveFile(c.req.path, import.meta.url)); app.get("/shared/*", (c) => serveFile(c.req.path, import.meta.url));

readFile - Read files from within the project:

Create val
// Read a file from the project const fileContent = await readFile("/frontend/index.html", import.meta.url);

listFiles - List all files in the project

Create val
const files = await listFiles(import.meta.url);

parseProject - Extract information about the current project from import.meta.url

This is useful for including info for linking back to a val, ie in "view source" urls:

Create val
const projectVal = parseProject(import.meta.url); console.log(projectVal.username); // Owner of the project console.log(projectVal.name); // Project name console.log(projectVal.version); // Version number console.log(projectVal.branch); // Branch name console.log(projectVal.links.self.project); // URL to the project page

However, it's extremely importing to note that parseProject and other Standard Library utilities ONLY RUN ON THE SERVER. If you need access to this data on the client, run it in the server and pass it to the client by splicing it into the HTML page or by making an API request for it.

Val Town Platform Specifics

  • Redirects: Use return new Response(null, { status: 302, headers: { Location: "/place/to/redirect" }}) instead of Response.redirect which is broken
  • Images: Avoid external images or base64 images. Use emojis, unicode symbols, or icon fonts/libraries instead
  • AI Image: To inline generate an AI image use: <img src="https://maxm-imggenurl.web.val.run/the-description-of-your-image" />
  • Storage: DO NOT use the Deno KV module for storage
  • Browser APIs: DO NOT use the alert(), prompt(), or confirm() methods
  • Weather Data: Use open-meteo for weather data (doesn't require API keys) unless otherwise specified
  • View Source: Add a view source link by importing & using import.meta.url.replace("ems.sh", "val.town)" (or passing this data to the client) and include target="_top" attribute
  • Error Debugging: Add <script src="https://esm.town/v/std/catch"></script> to HTML to capture client-side errors
  • Error Handling: Only use try...catch when there's a clear local resolution; Avoid catches that merely log or return 500s. Let errors bubble up with full context
  • Environment Variables: Use Deno.env.get('keyname') when you need to, but generally prefer APIs that don't require keys
  • Imports: Use https://esm.sh for npm and Deno dependencies to ensure compatibility on server and browser
  • Storage Strategy: Only use backend storage if explicitly required; prefer simple static client-side sites
  • React Configuration: When using React libraries, pin versions with ?deps=react@18.2.0,react-dom@18.2.0 and start the file with /** @jsxImportSource https://esm.sh/react@18.2.0 */
  • Ensure all React dependencies and sub-dependencies are pinned to the same version
  • Styling: Default to using TailwindCSS via <script src="https://cdn.twind.style" crossorigin></script> unless otherwise specified

Project Structure and Design Patterns

Recommended Directory Structure

├── backend/
│   ├── database/
│   │   ├── migrations.ts    # Schema definitions
│   │   ├── queries.ts       # DB query functions
│   │   └── README.md
│   └── routes/              # Route modules
│       ├── [route].ts
│       └── static.ts        # Static file serving
│   ├── index.ts             # Main entry point
│   └── README.md
├── frontend/
│   ├── components/
│   │   ├── App.tsx
│   │   └── [Component].tsx
│   ├── favicon.svg
│   ├── index.html           # Main HTML template
│   ├── index.tsx            # Frontend JS entry point
│   ├── README.md
│   └── style.css
├── README.md
└── shared/
    ├── README.md
    └── utils.ts             # Shared types and functions

Backend (Hono) Best Practices

  • Hono is the recommended API framework
  • Main entry point should be backend/index.ts
  • Static asset serving: Use the utility functions to read and serve project files:
    Create val
    import { readFile, serveFile, } from "https://esm.town/v/std/utils@85-main/index.ts"; // serve all files in frontend/ and shared/ app.get("/frontend/*", (c) => serveFile(c.req.path, import.meta.url)); app.get("/shared/*", (c) => serveFile(c.req.path, import.meta.url)); // For index.html, often you'll want to bootstrap with initial data app.get("/", async (c) => { let html = await readFile("/frontend/index.html", import.meta.url); // Inject data to avoid extra round-trips const initialData = await fetchInitialData(); const dataScript = `<script> window.__INITIAL_DATA__ = ${JSON.stringify(initialData)}; </script>`; html = html.replace("</head>", `${dataScript}</head>`); return c.html(html); });
  • Create RESTful API routes for CRUD operations
  • Always include this snippet at the top-level Hono app to re-throwing errors to see full stack traces:
    Create val
    // Unwrap Hono errors to see original error details app.onError((err, c) => { throw err; });

Database Patterns

  • Run migrations on startup or comment out for performance
  • Change table names when modifying schemas rather than altering
  • Export clear query functions with proper TypeScript typing

Common Gotchas and Solutions

  1. Environment Limitations:

    • Val Town runs on Deno in a serverless context, not Node.js
    • Code in shared/ must work in both frontend and backend environments
    • Cannot use Deno keyword in shared code
    • Use https://esm.sh for imports that work in both environments
  2. SQLite Peculiarities:

    • Limited support for ALTER TABLE operations
    • Create new tables with updated schemas and copy data when needed
    • Always run table creation before querying
  3. React Configuration:

    • All React dependencies must be pinned to 18.2.0
    • Always include @jsxImportSource https://esm.sh/react@18.2.0 at the top of React files
    • Rendering issues often come from mismatched React versions
  4. File Handling:

    • Val Town only supports text files, not binary
    • Use the provided utilities to read files across branches and forks
    • For files in the project, use readFile helpers
  5. API Design:

    • fetch handler is the entry point for HTTP vals
    • Run the Hono app with export default app.fetch // This is the entry point for HTTP vals
FeaturesVersion controlCode intelligenceCLI
Use cases
TeamsAI agentsSlackGTM
ExploreDocsShowcaseTemplatesNewestTrendingAPI examplesNPM packages
PricingNewsletterBlogAboutCareers
We’re hiring!
Brandhi@val.townStatus
X (Twitter)
Discord community
GitHub discussions
YouTube channel
Bluesky
Terms of usePrivacy policyAbuse contact
© 2025 Val Town, Inc.