convex-deploy-guard — Claude Code skill: what it does, how to install
Classifies and announces the target Convex deployment before running mutations. Requires explicit approval for production and enforces read-only session modes.
npx skills add convex/agent-skills --skill convex-deploy-guard -a claude-codeWhat convex-deploy-guard does
The skill enforces target verification before executing deployment-affecting actions. It checks CONVEX_DEPLOYMENT in .env.local, inspects convex.json, or calls the Convex MCP status tool. The agent must announce the target in one line before running any mutation. If configuration sources disagree or the target is ambiguous, the agent stops immediately instead of guessing.
Production actions require fresh consent inside the active session. Commands like npx convex deploy resolving to prod, npx convex run --prod, and snapshot imports stay blocked until explicitly confirmed. Permissions inside Convex MCP remain separated: read-only audits use --cautiously-allow-production-pii, while mutating tools stay locked behind --dangerously-enable-production-deployments.
Session-wide read-only requests disable destructive actions immediately. In read-only mode, the MCP starts with --disable-tools run,envSet,envRemove. If a deployment produces no visible changes, the skill forbids running the deploy command again; it forces the agent to re-verify which deployment actually received the update.
What it helps with
- prevent accidental mutations on Convex production deployments
- verify target deployment before executing
npx convex deploy - enforce a strict read-only mode during audit or inspection sessions
- diagnose target mismatches when deployments show no visible result
Example prompts for the agent
- Check our Convex deployment target before running any changes
- Switch to read-only mode and do not touch environment variables
- Inspect production logs through Convex MCP without mutating tools
How to install convex-deploy-guard
1Skills CLI (Vercel)
npx skills add convex/agent-skills --skill convex-deploy-guard -a claude-code2Manually: put the files in place
~/.claude/skills/convex-deploy-guard/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/convex-deploy-guard/
1Skills CLI (Vercel)
npx skills add convex/agent-skills --skill convex-deploy-guard -a codex2Manually: put the files in place
.agents/skills/convex-deploy-guard/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add convex/agent-skills --skill convex-deploy-guard -a cursor2Manually: put the files in place
.cursor/skills/convex-deploy-guard/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install convex/agent-skills convex-deploy-guard2Manually: put the files in place
.github/skills/convex-deploy-guard/SKILL.md1Skills CLI (Vercel)
npx skills add convex/agent-skills --skill convex-deploy-guard -a gemini-cli2Platform CLI
gemini skills install https://github.com/convex/agent-skills --path skills/convex-deploy-guardManually: put the files in place
.devin/skills/convex-deploy-guard/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add convex/agent-skills --skill convex-deploy-guard -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
Step by step, with commands for each platform: How to install skills in Claude Code: five ways
Questions about convex-deploy-guard
How to install convex-deploy-guard in Claude Code?
Run npx skills add convex/agent-skills --skill convex-deploy-guard -a claude-code in your terminal.
What does convex-deploy-guard do?
It identifies and announces the Convex deployment target before running commands, gates production changes behind explicit consent, and controls MCP flags.
How does the skill handle Convex MCP flags for production?
Read-only audits use --cautiously-allow-production-pii. Mutating access via --dangerously-enable-production-deployments stays disabled unless explicitly granted for that session.
Source text
SKILL.md · Apache-2.0
--- name: convex-deploy-guard description: "Classify + announce the target Convex deployment before any deployment-affecting command; fresh explicit consent for prod actions; session read-only mode." --- <!-- GENERATED from convex-agents content/capabilities/deploy-guard.json — do not edit by hand. --> # Deployment target guard Deployments are not interchangeable, and most incidents start with a command aimed at the wrong one. Every Convex project has several (personal dev, preview, prod — often across multiple projects on one machine). This guard is the standing discipline: identify, announce, then act — and treat prod as consent-gated, per action, per session. ## Workflow 1. IDENTIFY before you act: read `CONVEX_DEPLOYMENT` in .env.local, `convex.json`, and whether `CONVEX_DEPLOY_KEY` is set; or call the official Convex MCP `status` tool. Classify the target: local-anonymous | dev | preview | prod. If two sources disagree, resolve before proceeding. 2. ANNOUNCE in one line before any deployment-affecting command: `target: dev (joyful-capybara-123, personal dev)`. Never run the command in the same breath as discovering the target — announce first. 3. PROD needs a FRESH explicit yes: before `npx convex deploy` (when it resolves to prod), `npx convex run --prod`, `env set` on prod, snapshot `import`/`export` on prod, or starting the MCP with prod access — state exactly what will change on which deployment and get an explicit yes in THIS session. A yes given earlier, or for a different target, does not carry. 4. MCP safety defaults: start the official MCP scoped non-prod (`--deployment dev`). The two prod flags are DIFFERENT risk levels — keep them split: a read-only prod audit (advisor/insights reading data/logs/insights) passes ONLY `--cautiously-allow-production-pii` (read tools); `--dangerously-enable-production-deployments` (which enables MUTATING prod tools) stays OFF unless the user explicitly asked to CHANGE prod this session. Never pair them by default — 'look at prod' must not silently grant 'mutate prod'. 5. READ-ONLY session mode: when the user says 'read-only' / 'don't change anything', honor it absolutely for the rest of the session — no deploy, no env set/remove, no mutations via `run`, no imports; start the MCP with `--disable-tools run,envSet,envRemove`. 6. Wrong-deployment diagnosis: when a deploy 'didn't change anything', do NOT re-deploy harder. Re-run step 1 — the deploy almost certainly landed on a different deployment than the one being observed. 7. Ambiguity = stop: if you cannot determine which deployment a command will hit, find out (status tool) — never guess. ## Rules - Classify and announce the target BEFORE every deployment-affecting command — identification and action are two separate steps. - Prod consent is per-action, per-target, per-session: state what changes where, get a fresh explicit yes. - Keep the two prod MCP flags split by risk: --cautiously-allow-production-pii (read-only) for an audit; --dangerously-enable-production-deployments (mutating) only when the user explicitly asks to change prod. Both are user-spoken-only; default every MCP start to a non-prod deployment selector. - Read-only mode, once requested, is absolute for the session — including 'harmless' mutations. - A deploy that seemed to do nothing means the WRONG deployment changed — diagnose the target, don't re-run. - This guard composes: ship, env, migrate, and seed run it as their step 0; it is not itself a deploy tool.
© convex · Apache-2.0 · convex/agent-skills
