agentleFS
Sign inStart free
convexconvex/agent-skills/skills/convex-deploy-guard/SKILL.md

convex-deploy-guard

Skill68 starsChanged 14 days agoApache-2.0View on GitHub

Classify + announce the target Convex deployment before any deployment-affecting command; fresh explicit consent for prod actions; session read-only mode.

  • Reads credentials

6 other projects use a version of this, 1 of them edited.

Adopted by

Steady: 0 new projects took it in the last 4 weeks, none the 4 weeks before.thin data

Week of Sep 13: 0 new projectsWeek of Sep 20: 0 new projectsWeek of Sep 27: 0 new projectsWeek of Oct 4: 0 new projectsWeek of Oct 11: 0 new projectsWeek of Oct 18: 0 new projectsWeek of Oct 25: 0 new projectsWeek of Nov 1: 0 new projects
Sep 2026Oct 2026Nov 2026
New projects taking a version of this file each week, over the 8 weeks our latest run read: only 0 in all, so this is a hint, not a trend.

Most recently taken up by

Used with

Projects with it also use convex-acquire-domain, convex-check-updates and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • FabienGreardSkill

    convex-acquire-domain

    Find and buy a domain for the current Convex app through Convex, then bind it (labs; spend action).

    Also in 4 projects that use this

  • FabienGreardSkill

    convex-check-updates

    Check the current app's pinned Convex components against recommended versions and upgrade them behind a build gate.

    Also in 4 projects that use this

  • openclawSkill

    clawhub-ban-appeals

    Review ClawHub account-ban appeals, distinguish bans from moderation holds or blocked releases, and prepare an evidence-backed moderation decision. Route validated scanner inaccuracies to clawhub-clawscan.

    Also in 3 projects that use this

  • openclawSkill

    clawhub-clawscan

    Investigate ClawScan health alerts, diagnose scanner or ClawHub integration failures, prepare operational repairs, and route validated verdict inaccuracies upstream. Account ban appeals use clawhub-ban-appeals.

    Also in 3 projects that use this

  • +8 more from openclaw

The file

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 1 is distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    READ-ONLY session mode: when the user says 'read-only' / 'don't change anything', honor it absolutely for the rest of the session — no …

    line 18
  2. Very specific:

    Keep the two prod MCP flags split by risk: --cautiously-allow-production-pii (read-only) for an audit.

    line 26
  3. Distinctive:

    Read-only mode, once requested, is absolute for the session — including 'harmless' mutations.

    line 27

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md
<!-- 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.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free