본문으로 건너뛰기
cccskills
무료GitHub에 공개

convex-self-heal

Investigate Convex production errors, prepare fixes on a branch, and verify them before opening a pull request for human review. After an approved deployment, check whether the same error recurs. Never automatically merge changes or deploy to production.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

원문원문 설명 보기

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.

설치 방법 보기

이럴 때 유용합니다

  • Investigating recurring production errors
  • Preparing verified fixes for code or schema defects
  • Checking data changes against a production snapshot
  • Confirming errors stop after deployment

포함된 파일(1)

  • SKILL.md5.5 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

<!-- 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.

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Review code using shared OpenClaw instructions and a Python helper, while also following the target repository’s review requirements. This skill points to a common installation that supplies the actual review procedure.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Reviewing code with shared OpenClaw instructions
  • Applying repository-specific review requirements
  • Keeping shared review instructions up to date
openclaw/clawhub9.5천2026년 10월 19일 업데이트

Create and manage Axiom alert rules and notification destinations through its API. Connect alerts to email, Slack, or webhooks, check monitor history, and adjust thresholds and evaluation schedules to address excessive or missing alerts.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Set up error alerts and notification destinations
  • Tune monitors that send too many alerts
  • Investigate monitors that never trigger
openclaw/clawhub9.5천2026년 10월 19일 업데이트

axiom-sre

무료

Investigate production incidents and bugs using logs, metrics, and code evidence. The skill guides hypothesis testing, root cause analysis, fix validation, and reusable investigation notes, with access to configured observability tools such as Axiom.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Investigate production outages and rising error rates
  • Trace causes using logs, metrics, and code
  • Reproduce bugs and validate minimal fixes
openclaw/clawhub9.5천2026년 10월 19일 업데이트

Design and build Axiom dashboards from logs or metrics, the numerical measurements of system behavior. Create charts, filters, and layouts for monitoring and reporting, or migrate existing Splunk and Grafana panels while validating queries against available data.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Build a service health monitoring dashboard
  • Create interactive filters for investigating logs
  • Migrate dashboards from Splunk or Grafana
openclaw/clawhub9.5천2026년 10월 19일 업데이트

Drafts, previews, sends, and records emails for existing ClawHub content rights cases. It supports publisher removal notices and requester updates, requires approval of the final draft, and preserves the exact correspondence in the case record.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Preparing a skill removal notice for a publisher
  • Sending a requester a progress update or closure note
  • Preserving sent correspondence in an existing rights case
openclaw/clawhub9.5천2026년 10월 19일 업데이트

Apply ClawHub-specific rules when developing with Convex, including deployment targeting, runtime checks, data migrations, search performance, and skill statistics. It also directs specialized work to the appropriate companion skills.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Changing Convex functions or schemas
  • Planning production data migrations
  • Reviewing search query performance
openclaw/clawhub9.5천2026년 10월 19일 업데이트

openclaw의 스킬 모두 보기

이 스킬의 문제 신고