[
  {
    "id": "acquire-domain",
    "namespace": "labs",
    "title": "Acquire a domain (labs) — find and buy through Convex",
    "summary": "Find a memorable domain for the app, check live availability + price, and (only on explicit yes) register it through Convex and bind it to the deployment. Labs — a spend action. If the user already owns a domain, use `domains` instead.",
    "trigger": "the user wants to FIND and BUY a domain for their app ('find me a domain', 'get me a real domain', 'buy a domain for this'). SKIP if they haven't shipped yet (publish first), and SKIP if they already own a domain at their own registrar — that's `domains`.",
    "tier": 2,
    "doc": "/capability/acquire-domain.md"
  },
  {
    "id": "add",
    "namespace": "convex",
    "title": "add",
    "summary": "Add a capability to the current Convex app — consults the served catalog for the always-current procedure; falls back to built-in hosting or @convex-dev component search.",
    "trigger": "the user runs /add or $add, or asks to add hosting/publishing or any backend capability (email, search, billing, crons, domains, agent, auth, …) to an existing Convex app.",
    "tier": 0,
    "doc": "/capability/add.md"
  },
  {
    "id": "agent",
    "namespace": "convex",
    "title": "Add an AI agent / RAG backend",
    "summary": "Build an AI agent or RAG feature on Convex with @convex-dev/agent (threads, messages, tools, vector search), calling models through the Convex AI Gateway.",
    "trigger": "the user wants an AI chatbot / assistant / agent / RAG / 'chat with my docs' / LLM feature backed by Convex.",
    "tier": 0,
    "doc": "/capability/agent.md"
  },
  {
    "id": "auth",
    "namespace": "convex",
    "title": "Add sign-in to the app",
    "summary": "Add authentication (passkeys by default, OAuth/password optional) to the current Convex + web app, wired end to end.",
    "trigger": "the user wants login / sign-in / accounts / 'users can log in' / passkeys / OAuth for the current app. SKIP a brand-new app that should use scaffold's baked-in auth.",
    "tier": 0,
    "doc": "/capability/auth.md"
  },
  {
    "id": "billing",
    "namespace": "convex",
    "title": "Add billing / payments",
    "summary": "Add Stripe billing to a Convex app via the @convex-dev/stripe component — checkout, automatic webhook handling (signature-verified), and subscription state in the database.",
    "trigger": "the user wants payments / billing / subscriptions / 'charge users' / Stripe / a paywall in their Convex app.",
    "tier": 0,
    "doc": "/capability/billing.md"
  },
  {
    "id": "check-updates",
    "namespace": "convex",
    "title": "check-updates",
    "summary": "Check the current app's pinned Convex components against recommended versions and upgrade them behind a build gate.",
    "trigger": "the user runs /check-updates, asks 'are my components up to date' / 'any updates' / 'upgrade my components', or wants the newest component features after a quickstart.",
    "tier": 0,
    "doc": "/capability/check-updates.md"
  },
  {
    "id": "convex-advisor",
    "namespace": "convex",
    "title": "Live-deployment advisor",
    "summary": "Reads the deployment's own 72-hour health evidence (the official Convex MCP `insights` tool: bytes/documents-read limits and thresholds, OCC retries and permanent failures) and cross-joins it with the code to produce root-caused, evidence-backed findings — each with the concrete fix and the capability that applies it. The Supabase-advisors analog, but powered by runtime evidence instead of static heuristics.",
    "trigger": "the user asks 'why is my app slow', 'is my app healthy', 'check my deployment', 'what's wrong in production', 'audit performance', or wants a health/perf/cost review of a RUNNING Convex app; also fired as a pass inside optimize and launch-readiness. SKIP for a brand-new app with no deployment traffic (nothing to read), for pure code review with no deployment (that's convex-reviewer), and for error triage (that's sentinel/monitor).",
    "tier": 0,
    "doc": "/capability/convex-advisor.md"
  },
  {
    "id": "convex-authz",
    "namespace": "convex",
    "title": "Convex Authz Auditor/Hardener",
    "summary": "Audits and hardens a Convex app against the #1 real-defect class: identity trusted from a client-supplied argument instead of ctx.auth, missing per-document ownership checks, public queries that leak PII/financial data by a client-supplied id, and writes that attach rows to a parent/container the caller doesn't own. 44 of 214 confirmed defects in the 30-app corpus (FLYWHEEL.md turns 1-2).",
    "trigger": "the user asks to secure/harden/audit auth or authorization in their Convex app, add login/access control, or asks a question shaped like 'who can access this data' / 'can other users see this' / 'is this endpoint safe'; or an explicit invoke ('audit my authz', 'harden auth', '/convex-authz'). NOT always-on — do not run on every code change; do not fire for a generic 'review my code' (that's convex-reviewer) or a request to design/model a schema (that's design/convex-expert). SKIP entirely when the project has no convex/ directory.",
    "tier": 0,
    "doc": "/capability/convex-authz.md"
  },
  {
    "id": "convex-backup",
    "namespace": "convex",
    "title": "Back up — and prove the restore works",
    "summary": "Set up dependable Convex backups AND do the thing almost nobody does: prove the restore actually works. A backup you have never restored is a hope, not a backup. This runs a restore DRILL — take a snapshot, restore it into a throwaway preview, and assert the data came back intact — so 'we're backed up' becomes a verified fact instead of a comforting assumption.",
    "trigger": "the user wants backups / disaster recovery for a live Convex app — 'set up backups', 'how do I back this up', 'can I recover if something goes wrong', 'do a restore drill', 'is my backup actually restorable', 'export my data on a schedule' — or is about to do something risky and wants a verified safety net first. SKIP a brand-new app with no data worth protecting and a request that's really a forward schema change (that's migrate-rehearse, which shares the snapshot+preview mechanics).",
    "tier": 0,
    "doc": "/capability/convex-backup.md"
  },
  {
    "id": "convex-cost",
    "namespace": "convex",
    "title": "Preview what this app will cost",
    "summary": "Turn a Convex app's actual usage into a spend picture BEFORE the bill surprises you: which functions read the most bytes/documents per call, how that scales with traffic, and which query patterns are the cost drivers — read from the deployment's own insights, not guessed. Plus the confirm-cost discipline for any paid action. The cost-awareness layer every serious app needs and nobody surfaces in-loop.",
    "trigger": "the user asks about SPEND — 'what will this cost', 'why is my Convex bill high', 'which functions are expensive', 'how much bandwidth am I using', 'will this scale affordably' — or is about to take a metered/paid action (custom domain, provisioning) and should see the cost first. SKIP a pure perf/health question with no cost framing (that's convex-advisor — cost composes advisor's read-limit evidence but frames it as MONEY), and a brand-new app with no usage to price.",
    "tier": 0,
    "doc": "/capability/convex-cost.md"
  },
  {
    "id": "convex-docs",
    "namespace": "convex",
    "title": "Pull version-current Convex docs",
    "summary": "Get the RIGHT Convex docs for the version this project actually uses, instead of trusting model memory. The #1 named agent failure across every backend is stale-training-data → hallucinated APIs; this closes it with the Context7/Supabase discipline: check the installed convex version, fetch the current page as markdown, and follow a fixed freshness hierarchy before writing an unfamiliar API.",
    "trigger": "the agent is about to use a Convex API it is not certain is current — a newer/renamed component export, a CLI flag, a config shape — or the user asks 'what's the current way to do X in Convex', 'is this the latest API', 'check the docs for the version I'm on', or a build hit an error that smells like a version mismatch (an export/flag that doesn't exist). NOT a general 'how do I model a schema' question (that's convex-expert's baked knowledge) and NOT always-on — fire only when currentness is actually in doubt.",
    "tier": 0,
    "doc": "/capability/convex-docs.md"
  },
  {
    "id": "convex-expert",
    "namespace": "convex",
    "title": "Convex backend specialist",
    "summary": "Always-on Convex backend knowledge consulted whenever writing code under convex/.",
    "trigger": "before touching any code inside a convex/ directory",
    "tier": 0,
    "doc": "/capability/convex-expert.md"
  },
  {
    "id": "convex-insights",
    "namespace": "convex",
    "title": "Query logs + health in natural language",
    "summary": "Answer operational questions about a running Convex app from its own logs and health signals — 'what failed in the last hour', 'which function is slowest', 'did my last deploy cause this' — using the official Convex MCP (logs, insights, functionSpec). Closes the build→observe→fix loop inside one session, the way Cloudflare's observability MCP does, but over the user's own deployment.",
    "trigger": "the user asks an operational question about a RUNNING Convex app — 'what's erroring', 'why did requests fail', 'which function is slow/expensive', 'what happened after I deployed', 'show me recent failures', 'is anything broken' — or wants to inspect logs/traffic. Fired at the start of an optimize/debug session to establish ground truth. SKIP for a brand-new app with no traffic, for static code review (convex-reviewer), for a live error the agent should WAIT for (monitor/sentinel), and for pure perf-smell root-causing on read limits (that's convex-advisor's insights pass — insights is a shared input, but advisor OWNS the perf-fix framing).",
    "tier": 0,
    "doc": "/capability/convex-insights.md"
  },
  {
    "id": "convex-reviewer",
    "namespace": "convex",
    "title": "Convex Code Reviewer",
    "summary": "Reviews Convex code for security, auth, validators, performance, and best practices.",
    "trigger": "the user asks to review/audit Convex code, or after writing convex/ functions you want checked",
    "tier": 0,
    "doc": "/capability/convex-reviewer.md"
  },
  {
    "id": "convex-verify",
    "namespace": "convex",
    "title": "Prove a feature works — seed, drive, assert",
    "summary": "After building a feature, actually PROVE it works: seed realistic data, drive the feature through its own Convex functions as different mocked users with convex-test, and assert the behavior — including that authorization DENIES the wrong user. The closed build → seed → drive → assert loop that Firebase has the primitives for (rules-unit-tests) but nobody has composed into an agent-run verification. Turns 'it compiles' into 'it behaves'.",
    "trigger": "the user just built or changed a Convex feature and wants to KNOW it works — 'test this', 'prove the auth actually works', 'verify users can't see each other's data', 'does this behave correctly', 'write a test that proves X' — or an agent finished a feature and should confirm behavior before declaring done. Distinct from `test` (which scaffolds a test SUITE / teaches convex-test): convex-verify DRIVES a specific feature end-to-end and asserts its behavior, especially the negative authz cases. SKIP a pure 'set up a testing framework' ask (that's test) and a request with no built feature to exercise.",
    "tier": 0,
    "doc": "/capability/convex-verify.md"
  },
  {
    "id": "crons",
    "namespace": "convex",
    "title": "Add scheduled jobs (crons)",
    "summary": "Set up recurring scheduled functions (crons) on Convex — daily digests, cleanups, polling, retries.",
    "trigger": "the user wants a recurring/scheduled task — cron, 'every day/hour', digest email, cleanup job, periodic poll. SKIP one-off scheduling (use ctx.scheduler.runAfter inline).",
    "tier": 0,
    "doc": "/capability/crons.md"
  },
  {
    "id": "deploy-guard",
    "namespace": "convex",
    "title": "Deployment target guard",
    "summary": "Classify which Convex deployment a command will touch (local-anonymous / dev / preview / prod) BEFORE running it, announce it, and require a fresh explicit yes for anything prod-affecting. Includes a session-wide read-only mode. Kills the #1 operational trap: the deploy that silently lands on the wrong deployment.",
    "trigger": "BEFORE any deployment-affecting Convex action when the target is ambiguous or might be prod (npx convex deploy / run --prod / env set / import / export, an MCP prod deployment selector, a dashboard mutation); when the user asks 'which deployment am I on / is this prod?'; when the user says 'read-only', 'don't change anything', or 'don't touch prod'; and when a deploy APPEARED to do nothing (the classic wrong-deployment symptom). NOT a deploy tool itself — ship/env/migrate/seed USE this discipline; do not fire for a plain 'deploy my app' (that's ship).",
    "tier": 0,
    "doc": "/capability/deploy-guard.md"
  },
  {
    "id": "design",
    "namespace": "convex",
    "title": "design",
    "summary": "Design and build production-grade Convex backends from plain-English product asks.",
    "trigger": "a plain-English product ask ('an app where people can …') or a backend/schema/auth/realtime/storage/scheduling ask, or starting a new project with no named stack. SKIP for non-Convex stacks or pure frontend.",
    "tier": 0,
    "doc": "/capability/design.md"
  },
  {
    "id": "domains",
    "namespace": "convex",
    "title": "Set up a custom domain with your own provider",
    "summary": "Point a domain the user ALREADY OWNS (GoDaddy, Namecheap, Cloudflare, Porkbun, …) at their Convex app: the DNS records to create, the custom-domain attachment, and the auth-origin rebind. No purchase, no registrar credentials.",
    "trigger": "the user already OWNS a domain at their own registrar and wants it pointing at their Convex app ('point my GoDaddy domain at this', 'use my own domain', 'set up example.com for my app'). SKIP if they need to FIND or BUY a domain first.",
    "tier": 0,
    "doc": "/capability/domains.md"
  },
  {
    "id": "env",
    "namespace": "convex",
    "title": "Manage env vars + secrets",
    "summary": "Set and wire deployment environment variables / secrets (API keys) for a Convex app — never hardcoded.",
    "trigger": "the user needs an API key / secret / environment variable in their Convex functions — 'add my OpenAI key', 'set an env var', 'where do secrets go'.",
    "tier": 0,
    "doc": "/capability/env.md"
  },
  {
    "id": "explain-app",
    "namespace": "convex",
    "title": "Explain this Convex app",
    "summary": "Point at an existing Convex app and get a clear, accurate map of how it actually works — the data model and its relationships, every public vs internal function and what it does, the auth/ownership model, the components in use, and the request→data flow — read straight from the schema and function surface, not guessed. The 'understand what you inherited' capability that has to come before you can safely change it.",
    "trigger": "the user (or an agent starting on an unfamiliar codebase) wants to UNDERSTAND an existing Convex app before changing it — 'explain this app', 'how does this backend work', 'what does this codebase do', 'walk me through the data model', 'what functions are exposed', 'how is auth wired here', 'I inherited this Convex project'. Read-only comprehension. SKIP a brand-new empty scaffold (nothing to explain), a request to BUILD something new (design), and a request to AUDIT/FIX (optimize/convex-reviewer) — explain-app describes, it doesn't judge or change.",
    "tier": 0,
    "doc": "/capability/explain-app.md"
  },
  {
    "id": "improve-convex-plugin",
    "namespace": "convex",
    "title": "improve-convex-plugin",
    "summary": "Send this coding session's transcript to the Convex team for an AI post-mortem that improves the quickstart system. Run only when the user explicitly asks.",
    "trigger": "only when the user explicitly asks to send feedback or share this session with the Convex team. Never offer it unprompted.",
    "tier": 0,
    "doc": "/capability/improve-convex-plugin.md"
  },
  {
    "id": "labs-quickstart",
    "namespace": "labs",
    "title": "Quickstart (labs) — the full wow shell",
    "summary": "The experimental quickstart with passkey sign-in and the live Chef feedback panel, built locally. Labs — not launch-ready.",
    "trigger": "the user wants a new app with passkey sign-in and the live Chef feedback panel, asks for the full/labs quickstart, or runs /labs-quickstart. For a plain new-app scaffold with no extras, use quickstart.",
    "tier": 0,
    "doc": "/capability/labs-quickstart.md"
  },
  {
    "id": "launch-readiness",
    "namespace": "convex",
    "title": "Launch-readiness report",
    "summary": "One command that runs every audit-shaped Convex capability (authz, code review, live-deployment advisor, insights), collects their findings into one common report with a single readiness score, and points each finding at the capability that fixes it. Lighthouse for your backend: know exactly what stands between this app and production, ranked, before you ship.",
    "trigger": "the user asks 'is my app ready to launch/ship', 'is this production-ready', 'give me a readiness report', 'what's left before I go live', 'audit everything', or wants a single prioritized picture of an app's security/perf/health before shipping. SKIP a brand-new empty scaffold (nothing to assess yet) and a request scoped to ONE concern ('just check auth' → convex-authz directly; 'just perf' → convex-advisor).",
    "tier": 0,
    "doc": "/capability/launch-readiness.md"
  },
  {
    "id": "migrate",
    "namespace": "convex",
    "title": "Migrate the schema / data on a live app",
    "summary": "Safely change the schema and backfill data on a deployed Convex app using @convex-dev/migrations.",
    "trigger": "the user is changing the schema on a LIVE/deployed app, needs a data backfill, hit a schema-validation error after a change, or asks to 'migrate'/'backfill'/'change the schema safely'. SKIP a fresh local app (just edit the schema).",
    "tier": 0,
    "doc": "/capability/migrate.md"
  },
  {
    "id": "migrate-rehearse",
    "namespace": "convex",
    "title": "Rehearse a schema change on a preview before prod",
    "summary": "Before changing a live app's schema or backfilling data, rehearse the whole change on a throwaway preview deployment seeded with a snapshot of real data — push the new schema (which validates every existing document), run the backfill, verify, and only then promote the identical change to prod. Neon's branch-then-promote safety primitive, built from Convex preview deployments + snapshot import.",
    "trigger": "the user is about to change the schema, narrow a validator, rename/remove a field, or backfill data on a LIVE/deployed app with real data — 'migrate', 'change the schema safely', 'backfill', 'I need to alter this table in prod', or hit a schema-validation error after a change. SKIP a brand-new local app with no real data (just edit schema.ts), and SKIP the pure guidance case where the user only wants the optional-then-tighten pattern explained (that's migrate).",
    "tier": 0,
    "doc": "/capability/migrate-rehearse.md"
  },
  {
    "id": "monitor",
    "namespace": "convex",
    "title": "Watch for the next thing to react to",
    "summary": "A blocking watch that returns the next typed event — a dev error, a prod error, or a user request — so the agent reacts instead of polling.",
    "trigger": "the agent should wait for and react to the next event while building or running a Convex app — surface the next dev or prod error or request rather than poll. Used continuously during a build loop.",
    "tier": 0,
    "doc": "/capability/monitor.md"
  },
  {
    "id": "optimize",
    "namespace": "convex",
    "title": "Audit and optimize an existing Convex app",
    "summary": "The front door for an existing Convex app: a security and scale audit, component upgrades, and production observability.",
    "trigger": "the user points the agent at an EXISTING Convex app and wants an audit, review, upgrade, 'make it production-ready', 'is this scalable', or 'add observability'. SKIP for brand-new projects (use scaffold).",
    "tier": 0,
    "doc": "/capability/optimize.md"
  },
  {
    "id": "quickstart",
    "namespace": "convex",
    "title": "Quickstart: a barebones Convex template, running",
    "summary": "Get a minimal Convex + web template running from scratch — scaffold, install, dev backend + web server up. Minimal by design — no hosting or auth extras.",
    "trigger": "the user wants to START a new Convex app/template from scratch (\"build me an app where users can …\", \"new app\", \"get me a convex template\", ran /quickstart). SKIP if there's already a Convex project in the cwd; SKIP the extras (hosting/publish, pre-baked auth) unless the user asks for them.",
    "tier": 0,
    "doc": "/capability/quickstart.md"
  },
  {
    "id": "quickstart-improve",
    "namespace": "convex",
    "title": "quickstart-improve (alias of improve-convex-plugin)",
    "summary": "Backward-compatible alias for improve-convex-plugin: keeps the former $quickstart-improve name working for existing Codex users; identical behavior.",
    "trigger": "the user runs $quickstart-improve, or after a build wants to send feedback / report how it went.",
    "tier": 0,
    "doc": "/capability/quickstart-improve.md"
  },
  {
    "id": "seed",
    "namespace": "convex",
    "title": "Seed / import data",
    "summary": "Seed the Convex database with starter/fixture data, or import an existing dataset.",
    "trigger": "the user wants starter/sample/fixture data, to seed the db, or to import an existing dataset (CSV/JSON) into Convex.",
    "tier": 0,
    "doc": "/capability/seed.md"
  },
  {
    "id": "self-heal",
    "namespace": "convex",
    "title": "Gated production self-healing loop",
    "summary": "Turn a real production error into a verified, reversible fix PR — automatically triaged, root-caused, repaired, and certified against the backend's OWN invariants (types, schema conformance, the failing behavior actually gone) before a human is asked to merge. The gated error→fix loop competitors stop short of: because the errors live in a Convex table and Convex can run the fixer, the platform — not a generic LLM — certifies the fix is safe.",
    "trigger": "the user wants their live Convex app to triage and propose fixes for production errors on its own — 'set up self-healing', 'auto-fix my prod errors', 'when my app errors, open a fix PR', 'close the loop from error to fix' — or is reacting to a specific captured production error and wants it root-caused + fixed + verified. Requires sentinel (or equivalent prod-error capture) already present, or offers to add it. SKIP a brand-new app with no prod deployment, and SKIP for dev-loop error watching (that's monitor).",
    "tier": 0,
    "doc": "/capability/self-heal.md"
  },
  {
    "id": "sentinel",
    "namespace": "convex",
    "title": "Capture production errors in your own deployment",
    "summary": "A proactive, realtime pipeline that captures production errors into the user's own Convex deployment, redacted at write time, and hands them to the agent to fix.",
    "trigger": "the user wants production error capture / observability / 'why is my live app failing' / 'set up Sentinel' / 'add error tracking' for a Convex app. The component + its tables live in the user's OWN deployment.",
    "tier": 0,
    "doc": "/capability/sentinel.md"
  },
  {
    "id": "ship",
    "namespace": "convex",
    "title": "Ship the app live",
    "summary": "Build + publish the current app to a live URL (*.convex.app), and deploy its Convex backend to the cloud.",
    "trigger": "the user wants to deploy/publish/ship the current app — 'put it live', 'publish', 'deploy', 'give me a URL to share'. Needs a built app in the cwd.",
    "tier": 2,
    "doc": "/capability/ship.md"
  },
  {
    "id": "suggest",
    "namespace": "convex",
    "title": "Proactively suggest the right Convex component",
    "summary": "Passively notice when the user is hand-rolling something a Convex component already solves — counters, rate limiting, scheduled jobs, email, file uploads, search, presence, RAG — and suggest the matching @convex-dev component with a WHY grounded in their own code.",
    "trigger": "you notice the user hand-rolling something a Convex component already solves — a setInterval loop (→ @convex-dev/crons), a raw counter increment many users share (→ @convex-dev/sharded-counter), a .collect().length scan (→ @convex-dev/aggregate), email in an action (→ resend component), rate limiting with a DB counter (→ @convex-dev/rate-limiter), fs.writeFile uploads (→ Convex Storage), Elasticsearch/Algolia search (→ built-in search), presence/typing (→ @convex-dev/presence), multi-step actions that might time out (→ @convex-dev/workflow), collaborative editing (→ @convex-dev/prosemirror-sync), or Pinecone/external vector DB (→ @convex-dev/rag). DO NOT fire for generic coding questions unrelated to Convex.",
    "tier": 0,
    "doc": "/capability/suggest.md"
  },
  {
    "id": "test",
    "namespace": "convex",
    "title": "Generate Convex tests",
    "summary": "Write tests for Convex functions using convex-test (queries, mutations, auth, scheduling).",
    "trigger": "the user wants tests for their Convex functions, to add a test suite, or asks 'how do I test this'. SKIP pure frontend tests.",
    "tier": 0,
    "doc": "/capability/test.md"
  }
]