Builds reusable Convex components with isolated tables and app-facing APIs. Use for new components, reusable backend modules, integrations, or component boundary work.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
Builds reusable Convex components with isolated tables and app-facing APIs. Use for new components, reusable backend modules, integrations, or component boundary work.
Convex Create Component
Create reusable Convex components with clear boundaries and a small app-facing
API.
When to Use
Creating a new Convex component in an existing app
Extracting reusable backend logic into a component
Building a third-party integration that should own its own tables and
workflows
Packaging Convex functionality for reuse across multiple apps
When Not to Use
One-off business logic that belongs in the main app
Thin utilities that do not need Convex tables or functions
App-level orchestration that should stay in convex/
Cases where a normal TypeScript library is enough
Workflow
Ask the user what they are building and what the end goal is. If the repo
already makes the answer obvious, say so and confirm before proceeding.
Choose the shape using the decision tree below and read the matching
reference file.
Decide whether a component is justified. Prefer normal app code or a regular
library if the feature does not need isolated tables, backend functions, or
reusable persistent state.
Make a short plan for:
what tables the component owns
what public functions it exposes
what data must be passed in from the app (auth, env vars, parent IDs)
what stays in the app as wrappers or HTTP mounts
Create the component structure with convex.config.ts, schema.ts, and
function files.
Implement functions using the component's own ./_generated/server imports,
not the app's generated files.
Wire the component into the app with . If the app does not
already have , create it.
app.use(...)
convex/convex.config.ts
Call the component from the app through components.<name> using
ctx.runQuery, ctx.runMutation, or ctx.runAction.
If React clients, HTTP callers, or public APIs need access, create wrapper
functions in the app instead of exposing component functions directly.
Run pnpm exec convex dev and fix codegen, type, or boundary issues before
finishing.
Choose the Shape
Ask the user, then pick one path:
Goal
Shape
Reference
Component for this app only
Local
references/local-components.md
Publish or share across apps
Packaged
references/packaged-components.md
User explicitly needs local + shared library code
Hybrid
references/hybrid-components.md
Not sure
Default to local
references/local-components.md
Read exactly one reference file before proceeding.
Default Approach
Unless the user explicitly wants an npm package, default to a local component:
Put it under convex/components/<componentName>/
Define it with defineComponent(...) in its own convex.config.ts
Install it from the app's convex/convex.config.ts with app.use(...)
Let pnpm exec convex dev generate the component's own _generated/ files
Component Skeleton
A minimal local component with a table and two functions, plus the app wiring.
Note the reference path shape: a function in
convex/components/notifications/lib.ts is called as
components.notifications.lib.send from the app.
Critical Rules
Keep authentication in the app, because ctx.auth is not available inside
components.
Keep environment access in the app, because component functions cannot read
process.env.
Pass parent app IDs across the boundary as strings, because Id types become
plain strings in the app-facing ComponentApi.
Do not use v.id("parentTable") for app-owned tables inside component args or
schema, because the component has no access to the app's table namespace.
Import query, mutation, and action from the component's own
./_generated/server, not the app's generated files.
Do not expose component functions directly to clients. Create app wrappers
when client access is needed, because components are internal and need
auth/env wiring the app provides.
If the component defines HTTP handlers, mount the routes in the app's
convex/http.ts, because components cannot register their own HTTP routes.
If the component needs pagination, use paginator from convex-helpers
instead of built-in .paginate(), because .paginate() does not work across
the component boundary.
Add args and returns validators to all public component functions, because
the component boundary requires explicit type contracts.
Patterns
Authentication and environment access
// Bad: component code cannot rely on app auth or envconst identity = await ctx.auth.getUserIdentity();
const apiKey = process.env.OPENAI_API_KEY;
// Good: the app resolves auth and env, then passes explicit valuesconst userId = awaitgetAuthUserId(ctx);
if (!userId) thrownewError("Not authenticated");
await ctx.runAction(components.translator.translate, {
userId,
apiKey: process.env.OPENAI_API_KEY,
text: args.text,
});
Client-facing API
// Bad: assuming a component function is directly callable by clientsexportconst send = components.notifications.send;
// Bad: parent app table IDs are not valid component validatorsargs: {
userId: v.id("users");
}
// Good: treat parent-owned IDs as strings at the boundaryargs: {
userId: v.string();
}
Advanced Patterns
For additional patterns including function handles for callbacks, deriving
validators from schema, static configuration with a globals table, and
class-based client wrappers, see references/advanced-patterns.md.