# MCP and evidence path

Use this reference when deciding how to ground `azure-resource-health-incident-triage` guidance.

## Evidence order

1. Microsoft Learn documentation through the user's configured documentation MCP for documented Azure behavior.
2. Sampled read-only Azure evidence when the user has configured it and current-state confirmation is necessary.
3. Sanitized user-provided evidence when no read-only evidence path is available.
4. Clearly labeled inference when evidence is incomplete.

## Boundaries

- Documentation evidence does not prove the user's tenant, subscription, RBAC, quotas, deployed resources, private connectivity, incident state, or production readiness.
- Sampled read-only evidence proves only the sampled configured environment and time window.
- User-provided evidence can be incomplete or stale; preserve uncertainty.
- Never ask for credentials, tokens, secrets, tenant IDs, subscription IDs, resource IDs, customer data, private keys, or raw incident payloads.

## Required phrasing

Use generic phrasing such as "Microsoft Learn documentation through the user's configured documentation MCP". Do not expose internal tool names, profile names, environment names, or local identifiers in committed docs.

# Official sources

Use this reference when grounding current Azure behavior for `azure-resource-health-incident-triage`.

## Microsoft Learn sources

- https://learn.microsoft.com/azure/service-health/resource-health-overview
- https://learn.microsoft.com/azure/service-health/service-health-notifications-properties
- https://learn.microsoft.com/azure/service-health/service-health-event-properties
- https://learn.microsoft.com/azure/service-health/alerts-activity-log-service-notifications-portal
- https://learn.microsoft.com/azure/azure-monitor/essentials/activity-log
- https://learn.microsoft.com/azure/azure-monitor/alerts/action-groups

## Current documentation refresh (2026-06-04)

- Microsoft Learn documentation through the user's configured documentation MCP is the primary source for documented Azure behavior.
- Documentation evidence is not live customer-state evidence. It does not prove the user's tenant, subscription, RBAC, quotas, deployed resources, incident posture, private connectivity, automation state, or production readiness.
- Use sampled read-only Azure evidence only when the user has configured it and the task requires current-state confirmation. Label it as sampled evidence, not broad proof.

## Grounding rule

Docs explain service behavior. Current-state claims require sampled read-only evidence or sanitized user-provided evidence. If current state was not queried or shown, say so.

# Azure Resource Health Incident Triage Operations

> Version note: Azure service behavior and tooling change over time. Verify exact command syntax, permissions, and feature availability against Microsoft Learn documentation through the user's configured documentation MCP before production use. Do not paste secrets or sensitive identifiers into commands, files, or chat.

Use this reference for current, source-grounded service behavior and the hard review gates that the lean `SKILL.md` intentionally does not carry.

## What people get wrong

- Calling every user-visible incident an Azure outage before Resource Health, Service Health, and tenant changes are checked.
- Treating Resource Health status as root cause instead of first-pass evidence.
- Ignoring Unknown status or unsupported resources instead of stating evidence limits.
- Forgetting that Service Health events and Resource Health events are different alert categories.
- Remediating broadly before blast radius, start time, and recent changes are known.

## Officially grounded service shape

- Microsoft Learn evidence says Resource Health reports current and past health of specific Azure resources using service signals and statuses such as Available, Unavailable, Unknown, and Degraded.
- Service Health notifications are system-generated subscription activity-log events about incidents, maintenance, advisories, security, billing, and action-required items.
- Service Health events appear in the activity log when subscription scoped; some global emerging issues are not activity-log events.
- Resource Health events are recorded in the activity log for specific health annotations or transitions, but some Unknown transitions and short compute transitions are not recorded.

Documentation evidence proves documented Azure service behavior. It does not prove the user's tenant, subscription, RBAC, quotas, deployed resources, incident state, or production readiness.

## Non-negotiable design rules

- Start with exact resource, region, subscription scope, start time, symptom, and suspected blast radius.
- Separate provider incident, planned maintenance, security advisory, tenant-side change, resource-specific degradation, and unknown.
- Use Resource Health for resource-specific state and Service Health for subscription-scoped service notifications.
- Check activity log and alert/action group routing before declaring notification coverage good.
- Do not recommend destructive remediation while platform-caused versus tenant-caused evidence is unresolved.

## Minimal safe implementation flow

- Scope affected resources, services, regions, symptoms, start time, and business impact.
- Collect Resource Health status/history, Service Health notifications, activity log events, recent deployment/change evidence, and monitor alerts.
- Classify evidence as provider incident, planned maintenance, resource-specific issue, tenant-side change, or unknown.
- Define immediate safe actions, communication posture, support escalation evidence, and deeper triage handoff.
- Return evidence level, confidence, open questions, and next checks.

## High-risk assumptions to kill

- A customer-visible outage is not automatically an Azure platform outage; tenant-side deployments, configuration, quota, identity, and networking changes must be checked.
- Resource Health status is signal, not root cause; it must be correlated with Service Health, activity log, metrics, logs, and recent changes.
- Service Health and Resource Health alerts are distinct; one does not prove coverage for the other.
- Unknown or unsupported health states are evidence limits, not permission to invent certainty.
- Restart/delete/redeploy advice before blast-radius and health classification is reckless.

## Safe command/code verification targets

- Verify exact resource, region, subscription scope, start time, symptom, Resource Health status/history, and Service Health notifications.
- Check activity log health events, recent deployments, configuration changes, access changes, quota/limit signals, and monitor alerts.
- Classify evidence as provider incident, planned maintenance, health/security advisory, resource-specific degradation, tenant-side change, or unknown.
- Validate alert rules and action groups separately for Service Health and Resource Health coverage.
- Preserve support/escalation evidence with timestamps while redacting customer data and sensitive payloads.

## Safe verification targets

- Resource Health status and history are checked for each named resource where supported.
- Service Health notifications are checked for affected subscription, service, and region.
- Activity log includes or excludes relevant health events with timestamp and category caveats.
- Recent deployments, configuration changes, quota/limit signals, and access changes are not ignored.
- Action groups and alert rules exist for future health notifications where required.

## When to push back

- The user asks for root cause with only a screenshot or rumor.
- The request jumps to restart/delete/redeploy before health and change evidence are collected.
- The resource type is unsupported or Unknown and the user wants certainty anyway.
- Incident data contains customer or sensitive payloads that should be redacted.

# Safety checklist

Use before recommending production Azure changes, access grants, network connectivity changes, deployment automation, resilience claims, or incident conclusions for `azure-resource-health-incident-triage`.

## Non-negotiables

- Do not ask for or print credentials, client secrets, certificates, private keys, access tokens, tenant IDs, subscription IDs, resource IDs, customer data, raw incident payloads, or environment-specific identifiers.
- Prefer Microsoft Learn documentation through the user's configured documentation MCP for documented Azure behavior.
- Use sampled read-only Azure evidence only for current-state claims and label it as sampled evidence.
- Require explicit approval before recommending live mutation, broad access, destructive remediation, production deployment, DNS changes, failover, failback, or alert suppression.
- Keep recommendations least-privilege, reversible where possible, and scoped to the named resource or workload.
- Separate documentation-based claims, sampled evidence, user-provided evidence, and inference.

## Component risks

- **Identity and RBAC:** broad privileged roles, direct user grants, wildcard custom roles, missing PIM/time-bound controls, inherited scope surprises.
- **Automation and IaC:** missing preview, unreviewed delete/modify changes, overbroad deployment identities, unsafe secret handling, no rollback path.
- **Networking and Private Link:** DNS misconfiguration, duplicate private DNS zones, missing VNet links, resolver/forwarder gaps, route surprises, broken application connectivity.
- **Resilience and BCDR:** fantasy RTO/RPO, untested restore, undocumented failback, inaccessible DR assets, hidden single-region dependencies.
- **Health triage:** false provider attribution, unsupported resource health, ignored activity-log changes, sensitive incident payload exposure, broad remediation before blast-radius evidence.

## Evidence labels

Use `documentation-based`, `sampled read-only evidence`, `repo evidence`, `user-provided evidence`, or `inference`. Documentation alone never proves the user's live Azure environment.

# Workflow and output contract

Use this reference for full execution of `azure-resource-health-incident-triage`.

## Workflow

1. **Classify the request**
   - Identify service/domain, resource scope, environment, production impact, and whether mutation is requested.
   - Identify whether the task needs documentation-only guidance, sampled read-only current-state evidence, or sanitized user evidence.

2. **Ground in current sources**
   - Prefer Microsoft Learn documentation through the user's configured documentation MCP.
   - Read the component operations guide before issuing design, safety, or readiness conclusions.
   - Treat current-state claims as unproven unless supported by sampled read-only evidence or sanitized user-provided evidence.

3. **Stress-test the plan**
   - Kill broad permissions, vague ownership, missing rollback, missing validation, and unsupported production-readiness claims.
   - Separate facts from inference.
   - State blockers before recommendations.

4. **Recommend minimal safe action**
   - Prefer read-only inspection, preview, what-if, dry run, diagnostic query, or staged rollout before mutation.
   - Require explicit approval for live or destructive actions.
   - Keep the recommendation scoped and reversible where possible.

5. **Validate and hand off**
   - Name verification targets and evidence gaps.
   - Provide safe next actions and escalation criteria.
   - Do not claim tenant, subscription, resource, quota, or incident state that was not observed.

## Output contract

Return:

1. Scope and target
2. Evidence level: documentation-based, sampled read-only evidence, user-provided evidence, repo evidence, or inference
3. Key findings and risks
4. Blockers or missing evidence
5. Minimal safe next actions
6. Verification targets
7. Rollback, cleanup, or reversal path where applicable