test
Skill from get-convex/convex-backend-skill
Install
npx skills add get-convex/convex-backend-skill --skill test
Runs the open skills CLI and installs the skill for your agent (Claude Code, Codex, Cursor …). Alternatively copy the skill folder into .claude/skills/ or upload it in Claude.ai under Settings → Skills.
As a Claude Code plugin
/plugin marketplace add anthropics/claude-plugins-official
/plugin install convex@convex
This skill is part of the plugin “convex”. In Claude Code the plugin installs it together with the plugin’s other skills, commands and hooks.
What does the test skill do?
Description from the SKILL.md in the source repository.
Questions about test
What does the test skill do?
Generate tests for Convex functions with convex-test (queries/mutations/auth/scheduling, in-memory). TRIGGER when the user wants tests / a test suite for their Convex backend / 'how do I test this'.
How do I install test?
In a terminal: npx skills add get-convex/convex-backend-skill --skill test. The skills CLI asks which agents to install it for. In Claude.ai you can upload the skill folder as a ZIP under Settings → Skills.
Which agents can use test?
Skills use the open SKILL.md format, which Claude Code, Claude.ai, the Claude API, OpenAI Codex, Cursor, Gemini CLI and other agents support.
Is test safe to use?
Our automatic check found no risky patterns (piped shell scripts, hidden characters, secret access, prompt overrides). It is not a full audit – read the SKILL.md and any scripts before installing.
More skills from get-convex/convex-backend-skill
Set up recurring scheduled jobs (crons) on Convex — digests, cleanups, polling, retries. TRIGGER when the user wants a recurring/scheduled task ('every day/hour', cron, periodic cleanup). Targets internal functions, idempotent handlers.
Design and build reactive, type-safe, production-grade backends on Convex. Covers schema, queries/mutations/actions, indexes, auth, file storage, scheduling, real-time multiplayer, mobile backends, and LLM/agent workflows on Convex's one-platform stack.
Wire a domain the user ALREADY OWNS (GoDaddy/Namecheap/Cloudflare/…) to their Convex app: exact DNS records, custom-domain attachment, auth-origin rebind. TRIGGER when the user owns a domain and wants it pointing at their app ('point my domain at this', 'use my own domain', 'set up example.com'). Never asks for registrar credentials.
Set + wire deployment env vars / secrets (API keys) for a Convex app — stored in Convex env, read in actions, never hardcoded. TRIGGER when the user needs an API key/secret/env var ('add my OpenAI key', 'set an env var').
LABS — scaffold a running Next.js + shadcn Convex app with passkey sign-in and a live Chef feedback panel, then build and verify it locally. TRIGGER for the full/labs quickstart, passkeys, or the feedback panel in a new app. For a plain scaffold use quickstart. Legacy convex.app publishing is retired; use a separate hosting workflow if requested. SKIP when a Convex project already exists in the cwd.
Safely migrate the schema + backfill data on a deployed Convex app with @convex-dev/migrations. TRIGGER when changing the schema on a live app, backfilling data, or after a schema-validation error from a change. SKIP a fresh local app.
Scaffold a brand-new Convex app from a one-sentence idea and build it live — a running Next.js + shadcn app with `convex dev` + `next dev` and error watchers already armed, going from idea to running app in under a minute (locally).
Seed the Convex database with starter/fixture data or import an existing dataset (CSV/JSON). TRIGGER when the user wants sample/seed data or to import a dataset into Convex. Idempotent, schema-matching.
Related skills in Testing & QA
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
Migrate test files from `as` type assertions to @total-typescript/shoehorn. Use when user mentions shoehorn, wants to replace `as` in tests, or needs partial test data.
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
Use when implementing any feature or bugfix, before writing implementation code
Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.
Use when the user mentions Developer Console, projects, workspaces, credentials, or orgs — or uses phrases like "show my projects", "list workspaces", "get credentials", "switch project", "which org", "my org", "console", "navigate", "explore", "what projects do I have", "show credentials", "what workspace". Also use as the first step of the I/O Events registration and filtering flows — phrases like "subscribe to events", "register for events", "set up webhook", "event registration", "I/O Events", "add filter", "subscriber filter", "test my registration", "sample event" — to establish the org/project/workspace/credential context those flows are scoped to. Maintains a live breadcrumb showing exactly where the user is at all times.
Use when the user wants to filter events, test event registrations with sample events, or manage subscriber defined filters — phrases like "add filter", "create filter", "subscriber filter", "filter events", "define filter", "filter registration", "validate filter", "update filter", "edit filter", "delete filter", "remove filter", "show my filters", "list filters", "show sample event", "test my registration", "send test event", "what does the event look like", "sample payload", "send a test event", "view sample payload", "custom event payload", "send custom event".