Convex

Convex backend skill with a bias toward safety, observability, and index-backed queries.

Docs-First Rule (Blocking)

Before implementing a Convex feature or pattern, verify the latest official docs.

Primary sources:

• •https://docs.convex.dev/
• •https://stack.convex.dev/

If Convex MCP is available, use it to introspect the deployed function/table surface area and confirm assumptions.

Environments (Dev / Preview / Prod)

Convex projects typically have:

• •Dev deployments (your local npx convex dev sync target)
• •Preview deployments (branch/PR deployments, beta feature)
• •Production deployment

Use MCP status (if available) or the CLI to confirm which deployment you are connected to before making changes.

Components-First Rule

Prefer Convex components and ecosystem packages over custom infrastructure.

Start at:

• •https://docs.convex.dev/components
• •references/ecosystem.md

Core Rule (Blocking)

Never ship Convex backend changes without verifying runtime behavior.

Preferred verification order:

1. •Convex MCP logs (structured, diffable)
2. •npx convex dev terminal logs
3. •Convex Dashboard logs

Project Conventions (Preferred)

• •Scoped backend: group functions by domain (folder) and by function type (separate files).
• •Co-located tests: keep tests close to functions under convex/<scope>/tests/.
• •Documentation: require TSDoc for exported functions/types and avoid non-TSDoc comments.

See references/style.md and references/testing.md.

Router

MCP Integration (Recommended)

If Convex MCP is available, use it first.

If Convex MCP is not available, this skill still works:

• •

  Use the Convex CLI (npx convex ...) and the dashboard.

• •

  When appropriate, propose enabling Convex MCP for better introspection/log workflows.

• •

  Discover deployments: convex_status({ projectDir })

• •

  Inspect functions: convex_functionSpec({ deploymentSelector })

• •

  Inspect tables: convex_tables({ deploymentSelector })

• •

  Read data: convex_data({ deploymentSelector, tableName, ... })

• •

  Run functions: convex_run({ deploymentSelector, functionName, args })

• •

  Run safe ad-hoc reads: convex_runOneoffQuery({ deploymentSelector, query })

• •

  Verify logs: convex_logs({ deploymentSelector, ... })

Full workflow: references/mcp.md.

Critical Rules (7)

1. •Always use validators (args + returns) for functions.
2. •Always use explicit table names with ctx.db.get/patch/replace.
3. •Prefer index-backed queries (withIndex) and bounded reads (take/pagination).
4. •User identity comes from ctx.auth, never from args.
5. •Use internal* functions for sensitive operations.
6. •Schedule only internal functions.
7. •Use v.null() for void returns (return null).

References

• •Patterns:
  • •references/patterns/schemas.md
  • •references/patterns/functions.md
  • •references/patterns/auth.md
  • •references/patterns/workflows.md
  • •references/patterns/http.md
• •Other:
  • •references/mcp.md
  • •references/cli.md
  • •references/cli-help.md
  • •references/style.md
  • •references/file-storage.md
  • •references/testing.md
  • •references/ecosystem.md
  • •references/troubleshooting.md
• •Checklist:
  • •checklists/validation.md