self-heal
The self-heal skill automates recovery from deployment and build failures by attempting up to three fixes: first checking a patterns database for known solutions with confidence scores above 70%, then diagnosing logs and applying corrective actions via either direct file writes for S3 sources or pull requests for GitHub sources. Use this skill when deployments fail or build errors occur to avoid manual intervention and escalate only after exhausting retry attempts.
git clone --depth 1 https://github.com/nixopus/nixopus /tmp/self-heal && cp -r /tmp/self-heal/api/skills/self-heal ~/.claude/skills/self-healSKILL.md
# Self-Heal
## Flow (max 3 attempts)
On build_failed: check [deploy-patterns] for a known fix first → if no match, get_deployment_logs → diagnose → apply fix → redeploy → resume monitoring.
Known fixes from [deploy-patterns] have cross-org confidence scores. Prefer high-confidence fixes (>70%) before investigating from scratch.
### Applying the fix
- **S3 sources**: Use write_workspace_files to save the fix — files sync automatically.
- **GitHub sources**: Do NOT use write_workspace_files (it only writes locally and the fix will not reach the repo). Instead, use the GitHub tools: read_skill("github-workflow") and follow the Fix-via-PR flow (create branch → github_create_or_update_file → open PR → ask user to merge → redeploy).
### Rules
- Do not stop to ask the user unless the fix is ambiguous or requires credentials you do not have.
- After each failed attempt, tell the user what broke and what you are trying next.
- Maximum 3 self-heal attempts.
- After 3 failures, read_skill("rollback-strategy") to decide whether to rollback or escalate.
- If escalation is required, tell the user plainly that you could not complete the deployment automatically and that a Nixopus team member will reach out shortly to help finish it.Reference for all Nixopus API operations callable via nixopus_api(method, path, body)
Generate Caddyfile configurations for static sites and reverse proxies — SPA fallback routing, cache headers, compression, redirects, and error pages. Use when deploying a static site that needs custom Caddy configuration, or when the user needs SPA routing, caching, or redirect rules.
Generate docker-compose.yml for multi-service setups including databases, caches, and service dependencies. Use when the app needs a database, cache, message broker, or has multiple independently deployable services.
Size container memory and CPU limits, diagnose OOM kills and CPU throttling, and recommend resource adjustments by ecosystem. Use when containers are being OOM-killed, running slowly, or when setting initial resource limits for a deployment.
Build and deploy C/C++ applications — CMake, Meson, Ninja, and Dockerfile patterns. Use when deploying a C or C++ project, or when CMakeLists.txt or meson.build is detected.
Run database migrations safely during deployment — framework-specific commands, pre-deploy vs post-deploy timing, health gates, and rollback strategies. Use when the app has a database migration system and needs migrations run during deployment.
Build and deploy Deno applications — version detection, dependency caching, and Dockerfile patterns. Use when deploying a Deno project, or when deno.json or deno.jsonc is detected.
Sub-agent routing table — which agent handles diagnostics, machine health, infrastructure, GitHub, billing, and notifications. Load when the current task is not a direct deployment.