PluginBench
Skill
Review
Audit score 70

convex-self-heal

get-convex/agent-skills

Production error → triaged, root-caused, repaired, certified, and proposed as a human-reviewed PR; never auto-merges.

What is convex-self-heal?

Convex-self-heal automates the diagnosis and repair of production errors by capturing them via sentinel, root-causing via the findings bus, certifying fixes against real invariants (tsc, schema rehearsal, reproduce-then-confirm), and proposing verified PRs for human review and merge. Use it to close the gap between error detection and deployment: the machine does everything up to merge; the human keeps the button.

  • Captures production errors from sentinel and triages them (transient vs. config vs. code/schema defect)
  • Root-causes via convex-insights, convex-advisor, convex-reviewer, and convex-authz on the findings bus
  • Repairs on a branch using the appropriate fixer (authz, reviewer, expert) without touching prod directly
  • Certifies fixes before proposing: tsc clean, schema migrate-rehearse on prod-snapshot preview, reproduce-then-confirm-gone, no-regression check
  • Proposes verified PRs with certification evidence, original error, and reversibility notes; never auto-merges
  • Confirms error signature stops recurring in prod (via sentinel + logs) after human merge and deploy

How to install convex-self-heal

npx skills add https://github.com/get-convex/agent-skills --skill convex-self-heal
Prerequisites
  • Sentinel must be installed and capturing production errors in the user's own Convex deployment
  • Deploy-guard must be configured with standing consent for the classes of fix the loop may auto-prepare
  • Access to convex-insights, convex-advisor, convex-reviewer, convex-authz, and convex-expert capabilities
Claude Code
Cursor
Windsurf
Cline

How to use convex-self-heal

  1. 1.Install sentinel in your Convex deployment to capture production errors at write time
  2. 2.Configure deploy-guard with your pre-approved fix classes (default-safe: validator, index, ownership, non-destructive backfill)
  3. 3.When a production error is detected, the loop will triage it and classify as transient, config, or code/schema defect
  4. 4.For code/schema defects, the loop runs root-cause analysis via the findings bus and proposes a repair on a branch
  5. 5.Review the certification evidence (tsc, rehearsal, reproduce-then-gone, no-regression) in the PR
  6. 6.Merge the PR; deploy-guard will promote the change to prod and confirm the error signature stops recurring in sentinel + logs

Use cases

Good for
  • Automated triage and root-cause analysis of recurring production errors in Convex backends
  • Self-healing validator fixes, missing-index additions, and ownership-check additions without human coding
  • Verification that a proposed fix actually resolves the original error before human review
  • Audit trail of all auto-prepared fixes and their certification results for compliance and debugging
  • Prevention of unverified or destructive changes from reaching production
Who it's for
  • Backend engineers and platform teams running Convex deployments in production
  • Teams using Sentry, Datadog, or Vercel error monitoring who want verified fixes, not just alerts
  • Organizations that require human approval for production changes but want to accelerate diagnosis and fix preparation
  • DevOps and SRE teams managing error response and incident closure

convex-self-heal FAQ

Does this auto-merge to production?

No. The human keeps the merge button. The loop prepares, certifies, and proposes fixes as PRs; a human must review and merge. After merge and deploy, the loop confirms the error stops recurring.

What happens if root cause is unclear?

The loop stops and reports 'could not determine root cause' with the evidence collected. An uncertain fix is worse than an open, visible error; the human must investigate further.

How does it certify a fix before proposing?

It runs tsc --noEmit, migrate-rehearse on a prod-snapshot preview (if schema is touched), replays the error's triggering input against the fixed code to confirm the failure is gone, and checks for no new findings on the touched function.

What fix classes are auto-prepared by default?

Validator fixes, missing-index additions, ownership-check additions, and non-destructive backfills. Destructive, security-sensitive, or ambiguous changes are always deferred to explicit human direction.

How does it confirm the error is actually fixed in production?

After merge and deploy, it re-checks the sentinel table and logs (not insights) to confirm the error signature stops recurring. If it recurs, the loop reopens with the new evidence.

Full instructions (SKILL.md)

Source of truth, from get-convex/agent-skills.


name: convex-self-heal description: "Production error → triaged, root-caused, repaired, and certified (tsc + rehearsal + reproduce-then-gone) fix PR for a human to merge — then confirm the error stops recurring. Never auto-merges."

<!-- GENERATED from convex-agents content/capabilities/self-heal.json — do not edit by hand. -->

Gated production self-healing loop

Sentry/Datadog/Vercel can go error→investigate→draft-PR, but they treat the backend as opaque and stop at the human merge gate with an unverified diff. Convex can do the step they can't: because the error rows live in the user's own deployment and the fix can be rehearsed on a preview of that deployment, the platform certifies the fix against real invariants before anyone reviews it. This capability is the composition capstone — it wires sentinel (capture) → the findings bus (diagnose) → the fixers (repair) → migrate-rehearse/tsc/probe (certify) → a human PR (decide) → deploy-guard (promote). The human keeps the merge button; the machine does everything up to and including proving the fix works.

Workflow

  1. GUARD: deploy-guard — this loop reads prod and PROPOSES prod changes; classify + announce the deployment and get the standing consent for the loop's scope up front (what classes of fix it may auto-prepare vs must always defer). Never auto-merge; the human merge is the fixed boundary.
  2. CAPTURE: require sentinel (prod errors in the user's own deployment, redacted at write time). If absent, offer to install it and stop — there is nothing to heal without capture.
  3. TRIAGE a new/ recurring error: pull it via the official MCP (data/run-once-query over the sentinel table, or the monitor's prod_error event). Classify: transient (retry/ignore — do NOT open a PR for a one-off network blip), config (env/secret — hand to env, never guess a secret), or a code/schema defect (proceed).
  4. ROOT-CAUSE on the findings bus: run the relevant audit pass on the implicated function — convex-insights (the failing requests + stacks), convex-advisor (if it's a read-limit/OCC cause), convex-reviewer/convex-authz (if it's a logic/authz defect). Produce a bus finding with evidence (the stack + the reproducing input) and a fixCapability. If root cause is unclear, STOP and report — a wrong fix is worse than an open error.
  5. REPAIR via the finding's fixCapability (convex-authz, reviewer fixers, convex-expert for perf) on a branch — never on prod directly.
  6. CERTIFY against the backend's own invariants BEFORE proposing (this is the differentiator — do not skip any that apply): (a) tsc --noEmit clean; (b) if the fix touches schema/data, run it through migrate-rehearse on a preview seeded with a prod snapshot — the schema-conformance gate must pass on real-shaped data; (c) reproduce-then-confirm-gone: replay the error's triggering input against the fixed code (a convex-test case or an MCP run on the preview) and assert the failure no longer occurs; (d) no-regression: the finding must be gone AND no new bus finding introduced on the touched function. A fix that fails any applicable certification is NOT proposed — it's reported as 'attempted, could not certify' with what failed.
  7. PROPOSE, never merge: open a PR (or a diff for review) containing the fix, the certification evidence (tsc result, rehearsal outcome, the reproduced-then-gone assertion), the original error + finding, and the reversibility note. Label the change class. The human reviews and merges.
  8. PROMOTE on merge via deploy-guard's prod consent; after deploy, re-check the sentinel table + logs (failures) to confirm that error signature stops recurring (do NOT use insights for this — it tracks only OCC/read-limit perf events, not arbitrary error signatures) — the loop is only closed when the error stops recurring in prod. If it recurs, reopen with the new evidence.
  9. BOUND it: only classes the user pre-approved in step 1 are auto-prepared (default-safe set: validator fixes, missing-index adds, ownership-check adds, non-destructive backfills); anything destructive, security-sensitive beyond an added check, or ambiguous is always deferred to explicit human direction. Log every action to an append-only record so the loop is auditable.

Rules

  • The human keeps the merge button — this loop prepares and certifies fixes, it NEVER auto-merges or auto-deploys to prod (matches the industry boundary: no credible system ships unattended prod auto-merge).
  • Certify before proposing: tsc + (schema→migrate-rehearse on a prod-snapshot preview) + reproduce-then-confirm-the-failure-is-gone + no new bus finding. An uncertified fix is reported as 'could not certify', never proposed as done.
  • Triage first: transient blips get retried/ignored, config errors go to env (never guess a secret), only real code/schema defects enter the repair loop.
  • Repair on a branch/preview, never on prod directly; promote only through deploy-guard's fresh prod consent.
  • Only pre-approved fix classes are auto-prepared (default-safe: validator/index/ownership/non-destructive backfill); destructive or ambiguous changes are always deferred to the human.
  • Close the loop for real: after merge+deploy, confirm the error signature stops recurring via the sentinel table + logs (not insights, which only sees perf events); reopen if it persists.
  • Every action is logged to an append-only, auditable record; data residency stays in the user's own deployment (sentinel discipline).
  • If root cause is unclear, STOP and report — an uncertain fix is worse than an open, visible error.