self-healing-deploy

Files (1)

• SKILL.md

SKILL.md (first lines)

# Self-Healing Deploy

Orchestrate the entire lifecycle from merge to production: monitor CI, self-heal failures, run DB migrations, apply terraform, and progressively deploy through dev -> staging -> prod.

## How It Works

This skill runs a 7-phase pipeline. Each phase has built-in monitoring and self-healing. The pipeline stops and reports to you if it hits something it can't fix automatically.

```
PR Approved
  |
  v
[Phase 0] Recon — classify what changed (backend? terraform? migrations? iOS?)
  |
  v
[Phase 1] Merge — squash merge, capture SHA, discover triggered workflows
  |
  v
[Phase 2] Self-Heal — if any workflow fails: read logs, classify, fix, re-push, loop
  |
  v
[Phase 3] DB Migrations (dev) — detect new .sql files, run migration workflow
  |
  v
[Phase 4] Terraform Apply (dev) — if terraform changed, explicitly trigger apply
  |
  v
[Phase 5] Dev Verification — health check, config validation
  |
  v
[Phase 6] Staging — migrations -> terraform -> promote -> verify
  |
  v
[Phase 7] Production — migrations -> terraform -> promote -> verify
```

## State Tracking

Maintain a running status table throughout execution. Update and display it at each major milestone:

```markdown
## Deploy Pipeline Status
| Phase | Status | Duration |
|-------|--------|----------|
| Merge | ... | ... |
| CI/Deploy (dev) | ... | ... |
| DB Migrations (dev) | ... | ... |
| Terraform (dev) | ... | ... |
| Dev Health | ... | ... |
| DB Migrations (staging) | ... | ... |
| Staging Promote | ... | ... |
| Staging Health | ... | ... |
| DB Migrations (prod) | ... | ... |
| Prod Promote | ... | ... |
| Prod Health | ... | ... |
```

Use these status values: `Pending`, `In Progress`, `Done`, `Skipped`, `Failed`, `Passed`.
Track wall-clock duration per phase. Record `PIPELINE_START` time at the beginning.

## Global Rules

These apply across all phases:

### Self-Healing Budget
You get **5 fix attempts total** across the entire pipeline. Each time you modify code and push a fix, that's one attempt. Rerunning a transient failure (`gh run rerun`) does NOT count against this budget. If you exhaust all 5 attempts, stop the pipeline and report what you've tried.

### No Auto-Fix in Production
Production failures are always presented to the user with options. Never automatically fix and push code to resolve a prod deployment failure.

### Commit Attribution
All fix commits must include:
```
Co-Authored-By: Claude <noreply@anthropic.com>
```

### 30-Minute Warning
If the pipeline has been running for over 30 minutes, report current status and ask whether to continue.

### Environment URLs
Read environment URLs from `Infrastructure/docs/api-endpoints.json` rather than hardcoding them. This file is auto-updated by CI after each successful deploy.

---

## Phase 0: Pre-Merge Reconnaissance

Goal: Understand what's changing so the pipeline knows which phases to run.

### Identify the PR

If the user provided a PR number, use it. Otherwise, detect from the current branch:

```bash
gh pr list --head "$(git branch --show-current)" --json number,title,state --jq '.[0]'
```

### Classify Change Scope

Check which files the PR touches:

```bash
gh pr diff <NUMBER> --name-only
```

Categorize into flags — set each to `true` or `false`:

| Flag | Pattern | What It Triggers |
|------|---------|-----------------|
| `HAS_BACKEND` | `Infrastructure/<YOUR_API_PROJECT>/**` (excluding `*.md`) | Dev deploy, staging/prod promotion |
| `HAS_TERRAFORM` | `Infrastructure/terraform/**` | Terraform apply at each environment |
| `HAS_MIGRATIONS` | `Infrastructure/<YOUR_API_PROJECT>/Data/Migrations/*.sql` (new files only) | DB migration workflow at each environment |
| `HAS_IOS` | `<YOUR_APP>/**` (excluding `*.md`) | iOS CI only (no deployment) |

### Check CI Status

```bash
gh pr checks <NUMBER>
```

From bzellman/earp-kit, MIT.

More from bzellman/earp-kit