ClawHub Convex

Use the managed Convex guidance for general framework behavior and this skill for ClawHub's repository-specific boundaries.

Start Here

1. Read convex/_generated/ai/guidelines.md before editing Convex code.
2. Name the target runtime before running a Convex command: local, dev, or prod. Include the exact deployment when known and whether the current function/schema code has already been pushed there.
3. Route to the most specific companion skill:
   • Query cost, indexes, read amplification, subscriptions, or OCC: convex-performance-audit
   • Production migration, backfill, schema narrowing, or table reshaping: convex-migration-helper and create-and-cleanup-migration
   • Tables, TTL fields, cleanup crons, retention, auth/session cleanup, metric dedupe cleanup, or deprecated table removal: convex-retention
   • Auth, reusable components, or setup: use the matching managed Convex skill.

Do not edit upstream-managed Convex skills to store ClawHub policy.

Commands And Runtime Validation

• Push new or changed functions before convex run:
  • dev: bunx convex dev --once
  • prod: deploy through the workflow described by clawhub-production-release
• For a non-interactive direct production deploy when explicitly required, use bunx convex deploy -y.
• If bunx convex run --env-file .env.local ... returns 401 MissingAccessToken after login, omit --env-file and target the deployment with --deployment <name> or --prod.
• Regenerate committed API/types with bunx convex codegen after Convex API/schema changes.
• Import mutations from convex/functions.ts, not convex/_generated/server, so ClawHub's trigger wrapper runs. Type imports can still come from convex/_generated/server.
• Do not disable typechecking for an ordinary direct deploy. The production workflow owns its explicit deploy behavior and exceptions.