Automation Self Healer - Safe Automation Health Triage

Submitted by John McCartan. Internal Microsoft use only.

Automation Self Healer helps Clawpilot users detect repeated automation failures, classify likely root causes, and prepare safe recovery recommendations. This version is intentionally hardened: it is a diagnose-and-recommend workflow by default. It must not execute fixes, change authentication state, close browser processes, edit automation definitions, write to shared locations, or send outbound messages unless the user explicitly approves the exact action.

When to use

Use this skill when a user says:

• /automation-self-healer
• "check automation failures"
• "find failing automations"
• "try to fix automations"
• "run the automation healer"
• "detect automation problems"

Use it when one or more automations are repeatedly failing and the user wants a structured triage loop: what failed, why it likely failed, what to try, what has already been tried, and whether it recovered.

Do not use it for:

• One-off transient failures that have not repeated
• Code-level debugging that requires redesigning an automation
• Any unattended fix that changes auth, files, browser state, automations, or outbound messages
• Incident-management integrations, external webhooks, or third-party notifications

Safety boundaries

These rules are mandatory.

1. Diagnose and recommend by default. The skill may inspect run history, categorize errors, and propose recovery steps.
2. No unattended fixes. Scheduled runs may detect, summarize, dedupe, and notify generically. They must not execute remediation.
3. Preview before action. Before any fix, show the user the automation name, failure evidence, proposed command or action, expected effect, and rollback path.
4. Explicit confirmation required. Do not close browser processes, refresh auth, change settings, edit automations, write files outside the local state folder, or send Teams messages unless the user approves that exact action.
5. No broad process kills. Never run broad process termination commands automatically. If a browser cleanup is recommended, present the exact process IDs or a safe user-run command for approval.
6. No auth changes. The skill may report that authentication appears expired, but it must not sign the user in, sign the user out, clear tokens, refresh credentials, or change tenant context.
7. Teams messages are gated. Draft Teams notifications for review. In unattended mode, only send generic safe metadata if the user previously configured that behavior.
8. Keep state local. State files must stay on the user's device or approved Clawpilot workspace. Do not write private logs to shared locations.
9. Minimize sensitive data. Do not store tokens, secrets, full URLs with credentials, private message bodies, customer data, or full stack traces in state files. Summarize errors.
10. No external integrations. Do not post to PagerDuty, OpsGenie, webhooks, public repos, or external services.

Inputs

Workflow

Step 1 - Locate run history

Find available automation run records from Clawpilot's automation history or the user's provided run log. If no run history is available, explain what is missing and stop.

Do not invent a run database path. If multiple candidate files exist, ask the user which source to use.

Step 2 - Detect repeated failures

Group runs by automation and identify automations with at least failure_threshold consecutive errors inside lookback_minutes.

Track:

• Automation name and ID
• Last successful run, if known
• Failed run timestamps
• Short failure summary
• Whether this is a new alert or already known

Step 3 - Categorize likely root cause

Classify each failing automation into one of these categories:

Step 4 - Deduplicate alerts

Maintain a local state file that records currently alerted automations. Default retention is 48 hours.

Use this shape:

{
  "alerted": {
    "automation-id": {
      "alerted_at": "2026-05-27T02:10:00Z",
      "reason": "2 consecutive auth errors",
      "last_run_id": "run-id",
      "failure_type": "auth"
    }
  },
  "updated": "2026-05-27T02:15:00Z"
}

Do not include secrets, tokens, private message bodies, or full raw stack traces.

Step 5 - Present triage board

Produce a concise triage table:

Then group recommendations:

• Safe to retry later: likely transient
• Needs user action: auth, permissions, missing configuration
• Needs owner review: repeated failures after multiple recommendations
• Needs redesign: code-level or logic failures

Step 6 - Draft notifications

If notification is appropriate, draft a safe Teams message. Do not send it without approval unless the user has already configured generic unattended alerts.

Allowed generic unattended alert:

Automation health alert: 2 automations are repeatedly failing. Open Clawpilot and run /automation-self-healer for details.

User-approved detailed alert may include:

• Automation name
• Failure category
• Short non-sensitive summary
• Suggested next step

Do not include customer data, private emails, tokens, URLs with secrets, or full stack traces.

Step 7 - Ask for approval before any action

For each proposed action, show:

1. Automation name
2. Problem summary
3. Exact proposed action
4. Why it might help
5. Risk level
6. Rollback or undo path

Then ask:

Approve this action?
1. Approve this one
2. Skip this one
3. Dismiss this alert
4. Stop and do nothing

If the user does not respond, do nothing.

Step 8 - Track attempts

If the user approves an action, log only the approved action and outcome in a local append-only autofix.jsonl file:

{"timestamp":"2026-05-27T02:15:00Z","automation_id":"example","strategy":"user-verified-m365-auth","approved":true,"result":"user-completed","details":"User confirmed sign-in was refreshed"}

Keep details short and non-sensitive.

Step 9 - Detect recovery

On the next scan, if a previously alerted automation succeeds:

• Mark it recovered
• Remove it from current alerts
• Optionally draft a generic recovery notification

Do not claim a fix worked unless the run history proves recovery.

Output format

Return:

1. Health summary: number of automations scanned, failing, newly failing, recovered
2. Triage table: automation, failure category, evidence, recommendation
3. Approval queue: any action that requires explicit approval
4. Draft notification: if needed, with exact text and recipient
5. State update summary: local state files updated, with no sensitive details

Maintenance and attribution

• Contributor: John McCartan
• Maintenance owner: John McCartan unless reassigned
• Skill Shack category: General Tools
• Rollback path: remove the Skill Shack card, remove the SharePoint prompt, and mark the submission reverted or declined in the queue if needed