@raishin/vanguard-frontier-agentic 2.8.0 → 2.10.0

package/skills/azure/azure-resilience-bcdr-review/references/official-sources.md

@@ -1,14 +1,22 @@
-# Official Sources
+# Official sources
 
-## References
+Use this reference when grounding current Azure behavior for `azure-resilience-bcdr-review`.
 
-Load these only when needed:
+## Microsoft Learn sources
 
-- Azure Well-Architected reliability guidance: <https://learn.microsoft.com/en-us/azure/well-architected/reliability/principles>
-- Azure Well-Architected disaster recovery guidance: <https://learn.microsoft.com/en-us/azure/well-architected/reliability/disaster-recovery>
-- Azure landing-zone design areas: <https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-areas>
-- Azure Monitor overview: <https://learn.microsoft.com/en-us/azure/azure-monitor/overview>
-- Azure Monitor alerts overview: <https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-overview>
-- Azure Resource Health overview: <https://learn.microsoft.com/en-us/azure/service-health/resource-health-overview>
-- Azure Service Health overview: <https://learn.microsoft.com/en-us/azure/service-health/overview>
-- Azure MCP tool inventory: <https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/>
+- https://learn.microsoft.com/azure/well-architected/reliability/disaster-recovery
+- https://learn.microsoft.com/azure/reliability/concept-business-continuity-high-availability-disaster-recovery
+- https://learn.microsoft.com/azure/well-architected/reliability/metrics
+- https://learn.microsoft.com/azure/well-architected/reliability/testing-strategy
+- https://learn.microsoft.com/azure/reliability/overview-reliability-guidance
+- https://learn.microsoft.com/azure/service-health/overview
+
+## 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.

package/skills/azure/azure-resilience-bcdr-review/references/resilience-bcdr-operations.md

@@ -0,0 +1,69 @@
+# Azure Resilience BCDR 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
+
+- Claiming zero RTO or zero RPO without proving cost, latency, consistency, and failover mechanics.
+- Treating availability zones as a complete disaster recovery plan.
+- Testing backup creation but never testing restore time and data correctness.
+- Writing failover steps but forgetting failback.
+- Storing DR runbooks, scripts, or credentials only in the failed region or failed platform path.
+
+## Officially grounded service shape
+
+- Microsoft Learn evidence says DR plans must align to recovery targets and cover all components and the system as a whole.
+- RTO and RPO are business-defined recovery metrics; aiming for zero downtime or zero data loss is difficult and costly and must be agreed by technical and business stakeholders.
+- DR is not an automatic feature of Azure. Azure services provide capabilities that must be mapped to a workload-specific DR plan.
+- Well-Architected guidance requires business impact prioritization, disaster thresholds, communication protocols, recovery-aware architecture, backup strategy, drills, current plans, accessible DR assets, and safe automation.
+
+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
+
+- Define workload tier, business impact, RTO, RPO, and disaster declaration threshold before architecture review.
+- Review each dependency, not only the primary compute or database service.
+- Keep failback as a separate documented process from failover.
+- Test restores, failover, failback, operator access, monitoring, and communication paths.
+- Treat DR automation as high risk unless trained operators, approvals, and circuit breakers are defined.
+
+## Minimal safe implementation flow
+
+- Scope business service, components, dependencies, regions/zones, data stores, and recovery owners.
+- Map target RTO/RPO to replication, backup, failover, and restore mechanisms per component.
+- Review runbooks, communication plan, escalation path, DR asset availability, and access model.
+- Assess drill evidence and gaps against component-level and workload-level recovery targets.
+- Return blockers, conditional recovery posture, safe next tests, and required plan updates.
+
+## High-risk assumptions to kill
+
+- Zero RTO or zero RPO is not a realistic default; it must be business-approved with cost, consistency, latency, and operational tradeoffs visible.
+- Availability zones, backups, or paired regions alone are not a disaster recovery plan for the workload as a system.
+- Backup success is weak evidence until restore duration, data correctness, identity access, and dependency recovery are tested.
+- Failover without failback is half a DR plan and can strand production in an unplanned state.
+- DR assets stored only in the primary region, primary tenant path, or failed platform path are not available DR assets.
+
+## Safe command/code verification targets
+
+- Verify business tier, RTO, RPO, disaster threshold, dependency map, and recovery owner for each component.
+- Check backup, replication, failover, failback, restore-test, and drill evidence against documented targets.
+- Confirm runbooks include communication plan, escalation path, operator access, monitoring, and manual decision points.
+- Validate DR automation has approvals, circuit breakers, and current credentials or break-glass paths outside the failed dependency.
+- Label every untested recovery claim as conditional or unproven, not production-ready.
+
+## Safe verification targets
+
+- RTO/RPO are documented and tied to business criticality.
+- Failover and failback have separate runbooks and decision owners.
+- Backups restore within target RTO and meet target RPO in tested evidence.
+- DR scripts, pipelines, credentials, and docs remain accessible during regional outage scenarios.
+- Latest drill evidence covers technical steps and human process steps.
+
+## When to push back
+
+- The user wants DR approval without restore or drill evidence.
+- The plan assumes Azure platform resilience equals workload continuity.
+- Failback is undocumented or deferred.
+- Recovery assets are stored only in the primary region or one operational path.

package/skills/azure/azure-resilience-bcdr-review/references/safety-checklist.md

@@ -0,0 +1,24 @@
+# Safety checklist
+
+Use before recommending production Azure changes, access grants, network connectivity changes, deployment automation, resilience claims, or incident conclusions for `azure-resilience-bcdr-review`.
+
+## 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.

package/skills/azure/azure-resilience-bcdr-review/references/workflow-and-output.md

@@ -1,78 +1,41 @@
-# Workflow and Output Contract
+# Workflow and output contract
 
-## Safe Workflow
+Use this reference for full execution of `azure-resilience-bcdr-review`.
 
-1. **Define business recovery scope**: workload, environment, region footprint, critical transactions, dependency chain, and who declares disaster.
-2. **Force target clarity**: stated RTO, RPO, maximum tolerated data loss, manual-versus-automatic failover expectations, and failback requirements.
-3. **Map the recovery design**: zone redundancy, regional redundancy, backups, replication, warm standby, pilot light, active-active, or restore-only pattern.
-4. **Check shared responsibility**: separate Azure platform resilience from application correctness, data protection, identity dependencies, DNS/traffic management, and operator runbook obligations.
-5. **Collect evidence**: architecture docs, runbooks, drill history, Azure Monitor alerts, Resource Health, Service Health, and any live Azure MCP posture signals.
-6. **Stress-test service realities**: identify where services do not provide cross-region failover, where failover is manual, where recovery is eventual, or where data consistency guarantees are weaker than assumed.
-7. **Judge runbook quality**: prerequisites, decision points, rollback path, failback sequence, contact chain, evidence capture, and last tested date.
-8. **Return a verdict**: READY, READY WITH RISKS, or NOT READY, with explicit blockers, evidence labels, and next drills or design changes.
+## Workflow
 
-## Role-Specific Stress Checks
+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.
 
-- Reject any design that promises near-zero RTO or zero RPO without explicit architecture, cost, operational ownership, and test evidence.
-- Challenge assumptions that zone redundancy equals cross-region disaster recovery.
-- Challenge assumptions that backups alone satisfy low-RTO requirements.
-- Challenge assumptions that Azure-managed failover automatically covers application state, integration endpoints, secrets, DNS, certificates, third-party dependencies, or identity-plane dependencies.
-- Check whether failback is materially harder than failover and whether the plan admits that.
-- Treat untested runbooks as weak evidence, not readiness proof.
-- Treat health and alert signals as detection inputs only; they are not recovery execution.
-- Call out single-region control dependencies, manual approval bottlenecks, and undocumented human handoffs.
+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.
 
-## Output Template
+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.
 
-```markdown
-# Azure Resilience BCDR Review: <scope>
+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.
 
-## Verdict
-- Status: READY / READY WITH RISKS / NOT READY
-- Biggest recovery risk:
-- Evidence level: live evidence / documentation-based / sanitized evidence / inference
+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.
 
-## Business targets
-- Critical service:
-- Region or topology:
-- Required RTO:
-- Required RPO:
-- Disaster declaration owner:
+## Output contract
 
-## Recovery design summary
-- Pattern:
-- Failover mode:
-- Failback mode:
-- Dependencies:
-- Shared-responsibility boundary:
+Return:
 
-## Findings
-| Area | Finding | Severity | Evidence | Recommendation | Owner |
-|---|---|---|---|---|---|
-
-## Runbook and test posture
-- Last tested:
-- Test type:
-- Gaps:
-- Missing proof:
-
-## Service-level recovery gaps
-- ...
-
-## Safe next actions
-1.
-2.
-3.
-
-## Assumptions and unknowns
-- ...
-```
-
-## Red Flags
-
-- The plan says "geo-redundant" but never states real RTO, real RPO, or failback behavior.
-- The answer assumes every Azure service in scope supports automatic cross-region recovery.
-- The design has replicated infrastructure but no tested data or identity recovery path.
-- The runbook has failover steps but no failback criteria, rollback branch, or ownership chain.
-- Recovery readiness is claimed from architecture diagrams alone, with no drill evidence.
-- Monitoring exists, but no alert-to-decision workflow shows who acts, when, and with what authority.
+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

package/skills/azure/azure-resource-health-incident-triage/SKILL.md

@@ -4,8 +4,8 @@ description: Use this skill for Azure Resource Health, Service Health, activity-
 allowed-tools: Read Grep Glob
 metadata:
   author: github: Raishin
-  version: 0.1.0
-  updated: "2026-05-05"
+  version: 0.1.2
+  updated: "2026-06-05"
   category: observability
 ---
 
@@ -17,11 +17,11 @@ Act as a ruthless Azure health triage lead. Your job is to reduce false attribut
 
 Default evidence posture:
 
-- Prefer live Azure MCP evidence when the client actually exposes relevant Azure health and monitor tools.
+- Prefer Microsoft Learn documentation through the user's configured documentation MCP, then sampled read-only Azure evidence when available, then sanitized user evidence.
 - Treat Azure Resource Health, Service Health, and Activity Log as first-pass platform signals, not automatic root cause proof.
 - Separate `provider incident`, `tenant misconfiguration`, `resource-specific failure`, and `unknown` until evidence narrows it.
 - Never ask the user to paste secrets, tokens, customer data, raw credentials, or sensitive payloads into chat.
-- Do not hard-code MCP server names, subscription IDs, tenant IDs, resource IDs, or local file paths.
+- Do not hard-code internal tool names, subscription IDs, tenant IDs, resource IDs, or local file paths.
 
 ## Trigger Situations
 
@@ -43,7 +43,7 @@ Do not use this skill as a substitute for:
 
 ## Lean operating rules
 
-- Prefer live Azure or Microsoft evidence first when the active client exposes it; otherwise fall back to official documentation and sanitized user evidence.
+- Prefer Microsoft Learn documentation through the user's configured documentation MCP, then sampled read-only Azure evidence when available, then sanitized user evidence.
 - Separate confirmed facts from inference. If state was not queried or shown, say so.
 - Challenge broad access, broad scope, destructive changes, and hand-wavy production claims.
 - Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
@@ -52,7 +52,9 @@ Do not use this skill as a substitute for:
 
 Load these only when needed:
 
-- [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing live Azure evidence, confirming Microsoft MCP capability, or switching to documentation mode.
+- [Azure Resource Health Incident Triage Operations](references/resource-health-triage-operations.md) — use for current service behavior, common failure modes, hard design rules, verification targets, and push-back conditions.
+- [Safety checklist](references/safety-checklist.md) — use for evidence labels, risk gates, mutation boundaries, approval rules, credential boundaries, and current-state caveats.
+- [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing documentation-based evidence, sampled read-only evidence, or sanitized user evidence.
 - [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, applying stress checks, or formatting the final answer.
 - [Official sources](references/official-sources.md) — use when you need the detailed Microsoft documentation list or source notes.
 

package/skills/azure/azure-resource-health-incident-triage/metadata.json

@@ -11,22 +11,19 @@
     "kiro",
     "other"
   ],
-  "summary": "Triage Azure Resource Health, Service Health, activity-log alerts, and first-pass cloud-health incidents with explicit separation between provider incidents, tenant-side changes, and unresolved evidence.",
+  "summary": "Triage Azure Resource Health, Service Health, activity-log alerts, and first-pass cloud-health incidents with explicit separation between provider incidents, resource-specific health, tenant-side changes, and unresolved evidence.",
   "source_type": "original",
   "official_docs": [
-    "https://learn.microsoft.com/en-us/azure/service-health/resource-health-overview",
-    "https://learn.microsoft.com/en-us/azure/service-health/",
-    "https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/activity-log",
-    "https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-create-activity-log-alert-rule",
-    "https://learn.microsoft.com/en-us/azure/service-health/service-health-alert-overview",
-    "https://learn.microsoft.com/en-us/azure/service-health/alerts-activity-log-service-notifications-portal",
-    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/",
-    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/azure-resource-health",
-    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/azure-monitor"
+    "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"
   ],
-  "security_notes": "Do not over-attribute platform health signals as root cause, ignore recent tenant-side changes, invent unsupported MCP tools, or recommend broad remediation before blast radius and evidence are clear.",
-  "last_verified": "2026-04-27",
+  "security_notes": "Do not over-attribute platform health signals as root cause, ignore recent tenant-side changes, expose sensitive incident payloads, invent unsupported tools, or recommend broad remediation before blast radius and evidence are clear.",
+  "last_verified": "2026-06-05",
   "path": "skills/azure/azure-resource-health-incident-triage",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.2"
 }

package/skills/azure/azure-resource-health-incident-triage/references/mcp-and-evidence.md

@@ -1,34 +1,21 @@
-# MCP and Evidence Path
+# MCP and evidence path
 
-## Official Azure MCP Linkage
+Use this reference when deciding how to ground `azure-resource-health-incident-triage` guidance.
 
-Use official Azure MCP capabilities as exposed in the active client. Do not invent a namespace, tool, or server label.
+## Evidence order
 
-Based on the repo spec and Microsoft Azure MCP documentation, relevant capability families can include:
+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.
 
-- `resourcehealth` for resource availability status and service-impacting health events,
-- `monitor` for activity-log retrieval and related Azure Monitor evidence,
-- `group` and `subscription` when scope discovery is required before health checks.
+## Boundaries
 
-Rules:
+- 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.
 
-- Prefer read-only health and activity evidence first.
-- If the expected Azure health tooling is absent, switch to documentation mode instead of pretending live checks happened.
-- Ask for the configured Azure MCP server name only if the client exposes multiple ambiguous Azure servers and the correct one is unclear.
-- Never ask for secrets, credential exports, tenant dumps, or subscription-wide privileged changes just to triage health.
+## Required phrasing
 
-## Platform-Agnostic Execution
-
-This skill must work on macOS, Windows, Linux, and MCP-only clients. Prefer Azure MCP evidence. When portal, CLI, PowerShell, REST, or ARM examples are useful, keep them neutral with `<placeholders>` until the user confirms the active platform and access path.
-
-## Documentation Fallback When Live Data Is Unavailable
-
-Live Azure evidence beats documentation, but documentation is safer than guessing.
-
-If live Azure MCP access is unavailable, incomplete, denied, or clearly out of scope:
-
-- use Microsoft Learn documentation to define what Resource Health, Service Health, Activity Log, and health alerts can and cannot prove,
-- ask for sanitized screenshots, exported alert payloads, event timestamps, activity-log entries, or redacted incident notes,
-- label each conclusion as `live evidence`, `documentation-based`, `user-provided sanitized evidence`, or `inference`,
-- explicitly say when current tenant state is unverified,
-- do not claim a real Azure incident exists unless current evidence shows it.
+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.

package/skills/azure/azure-resource-health-incident-triage/references/official-sources.md

@@ -1,15 +1,22 @@
-# Official Sources
+# Official sources
 
-## References
+Use this reference when grounding current Azure behavior for `azure-resource-health-incident-triage`.
 
-Load these only when needed:
+## Microsoft Learn sources
 
-- [Azure Resource Health overview](https://learn.microsoft.com/en-us/azure/service-health/resource-health-overview)
-- [Azure Service Health documentation](https://learn.microsoft.com/en-us/azure/service-health/)
-- [Azure Monitor activity log](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/activity-log)
-- [Create or edit an activity log, service health, or resource health alert rule](https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-create-activity-log-alert-rule)
-- [Service Health alerts overview](https://learn.microsoft.com/en-us/azure/service-health/service-health-alert-overview)
-- [Create Service Health alerts for Azure service notifications](https://learn.microsoft.com/en-us/azure/service-health/alerts-activity-log-service-notifications-portal)
-- [Azure MCP Server tools inventory](https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/)
-- [Azure MCP Server tools for Azure Resource Health](https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/azure-resource-health)
-- [Azure MCP Server tools for Azure Monitor and Workbooks](https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/azure-monitor)
+- 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.

package/skills/azure/azure-resource-health-incident-triage/references/resource-health-triage-operations.md

@@ -0,0 +1,69 @@
+# 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.

package/skills/azure/azure-resource-health-incident-triage/references/safety-checklist.md

@@ -0,0 +1,24 @@
+# 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.