@raishin/vanguard-frontier-agentic 1.0.0

package/skills/azure/azure-private-endpoint-adoption-planner/metadata.json

@@ -0,0 +1,30 @@
+{
+  "id": "azure-private-endpoint-adoption-planner",
+  "name": "Azure Private Endpoint Adoption Planner",
+  "type": "skill",
+  "provider": "azure",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Plan Azure Private Link and private endpoint adoption with explicit hub-versus-spoke placement, private DNS zone linkage, route implications, and centralized-versus-local trade-offs.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-areas",
+    "https://learn.microsoft.com/en-us/azure/architecture/guide/networking/private-link-hub-spoke-network",
+    "https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-dns-integration",
+    "https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-dns",
+    "https://learn.microsoft.com/en-us/azure/dns/private-dns-privatednszone",
+    "https://learn.microsoft.com/en-us/azure/azure-monitor/logs/private-link-design",
+    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/"
+  ],
+  "security_notes": "Do not recommend private endpoint placement without naming consumer networks, DNS-zone ownership, VNet links, route implications, and rollback checks. Challenge both over-centralized hub designs and uncontrolled per-spoke duplication.",
+  "last_verified": "2026-04-27",
+  "path": "skills/azure/azure-private-endpoint-adoption-planner",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/azure/azure-private-endpoint-adoption-planner/references/mcp-and-evidence.md

@@ -0,0 +1,26 @@
+# MCP and Evidence Path
+
+## Official Azure MCP Linkage
+
+Use official Azure MCP capabilities only if they are actually exposed in the active runtime. This repo's evidence base supports Azure MCP as a generic official tool inventory, not a guaranteed private-endpoint-specific tool surface.
+
+Safe rule:
+
+- if the active client exposes Azure read-oriented discovery for subscription, resource group, or resource inspection, use that for current-state evidence;
+- if private endpoint, DNS, or effective-route capabilities are not clearly exposed, switch to documentation mode instead of pretending the tools exist;
+- never hard-code an invented MCP namespace like `privateendpoint`, `dnszone`, or `networkwatcher` unless the active client explicitly exposes it.
+
+## Platform-Agnostic Execution
+
+This skill must work in MCP-only, browser-only, macOS, Linux, and Windows environments. Prefer architecture reasoning plus official documentation. If examples are helpful, use neutral placeholders such as `<subscription>`, `<resource-group>`, `<vnet>`, and `<private-dns-zone>` rather than platform-specific scripts unless the user asks for a concrete execution path.
+
+## Documentation Fallback When Live Data Is Unavailable
+
+Live Azure evidence beats documentation, but documentation beats guessing.
+
+If live Azure MCP evidence is unavailable, incomplete, or ambiguous:
+
+- use the Microsoft Learn references above,
+- ask for sanitized topology diagrams, private DNS zone names, VNet linkage descriptions, or redacted architecture notes,
+- label conclusions as `live evidence`, `documentation-based`, `user-provided sanitized evidence`, or `inference`,
+- do not claim the user's DNS links, route tables, resolver path, or effective access model are correct unless they are actually evidenced.

package/skills/azure/azure-private-endpoint-adoption-planner/references/official-sources.md

@@ -0,0 +1,20 @@
+# Official Sources
+
+## References
+
+Load these in order, only as needed:
+
+1. Azure landing-zone design areas for platform context and ownership coupling:
+   - https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-areas
+2. Azure Architecture Center guidance for Private Link in hub-and-spoke environments:
+   - https://learn.microsoft.com/en-us/azure/architecture/guide/networking/private-link-hub-spoke-network
+3. Azure private endpoint DNS integration guidance for zone linkage and resolver behavior:
+   - https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-dns-integration
+4. Azure private endpoint DNS zone reference when validating service-specific zone names:
+   - https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-dns
+5. Azure Private DNS guidance for linked virtual networks and custom DNS caveats:
+   - https://learn.microsoft.com/en-us/azure/dns/private-dns-privatednszone
+6. Azure Monitor Private Link design guidance when observability endpoints are in scope:
+   - https://learn.microsoft.com/en-us/azure/azure-monitor/logs/private-link-design
+7. Azure MCP tool inventory, only for confirmed live capability discovery:
+   - https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/

package/skills/azure/azure-private-endpoint-adoption-planner/references/workflow-and-output.md

@@ -0,0 +1,100 @@
+# Workflow and Output Contract
+
+## Safe Workflow
+
+1. **Classify the adoption scope**
+   - target Azure service or services,
+   - single workload or shared platform service,
+   - one VNet, hub-spoke, Virtual WAN-adjacent, or hybrid environment,
+   - single subscription or multi-subscription.
+2. **Identify the real consumers**
+   - which workloads need access,
+   - whether consumers are concentrated in one spoke or many,
+   - whether on-premises or cross-region consumers exist,
+   - whether the service is platform-shared or workload-specific.
+3. **Choose the placement decision deliberately**
+   - hub placement when many spokes need the same service and shared governance is intentional,
+   - workload-local placement when access should stay narrow and workload-owned,
+   - reject centralization-by-habit when it increases blast radius without a clear operational benefit.
+4. **Map DNS dependencies before approving anything**
+   - private DNS zone required or not,
+   - which VNets must link to which zones,
+   - whether custom DNS or Azure DNS Private Resolver changes the path,
+   - whether multi-network designs risk DNS override or split-resolution confusion.
+5. **Map routing and access implications**
+   - private endpoints inject interface-level reachability, not generic service exposure,
+   - check whether access depends on peering, hybrid reachability, or centralized inspection paths,
+   - explicitly call out `/32` route implications where Microsoft guidance says they matter,
+   - verify that security controls still allow the intended flows.
+6. **Assess centralized versus workload-local trade-offs**
+   - central hub endpoint simplifies shared consumption but couples unrelated workloads,
+   - local endpoint improves least privilege but increases endpoint count, DNS linking, and operational repetition,
+   - Azure Monitor Private Link needs extra caution because shared DNS can create tenant-wide surprises.
+7. **Return a bounded rollout and validation plan**
+   - nonproduction-first,
+   - DNS validation before workload cutover,
+   - access-path validation from each consumer network,
+   - rollback path for zone-link, endpoint, and route-adjacent changes.
+
+## Role-Specific Stress Checks
+
+- If the design says "put every private endpoint in the hub," challenge it. That is often laziness disguised as architecture.
+- If the design says "put every private endpoint in each workload spoke," challenge the duplication, DNS sprawl, and operating cost.
+- If the answer does not explain who owns private DNS zones and VNet links, it is incomplete.
+- If the design assumes peering alone solves name resolution, it is wrong.
+- If Azure Monitor Private Link is involved, check for AMPLS and shared-DNS side effects before blessing the design.
+- If on-premises consumers exist, check resolver and forwarding design explicitly.
+- If the rollout changes private access but ignores rollback of DNS links or endpoint cutover, it is not safe.
+
+## Output Template
+
+```markdown
+# Azure Private Endpoint Adoption Review: <scope>
+
+## Verdict
+- Status: READY / READY WITH RISKS / NOT READY
+- Primary decision: HUB / SPOKE / MIXED
+- Evidence level: live evidence / documentation-based / sanitized evidence / inference
+
+## Scope
+- Target service(s):
+- Consumer network(s):
+- Subscription / resource-group boundary:
+- Shared or workload-specific:
+- Requested action:
+
+## Placement recommendation
+- Recommended pattern:
+- Why:
+- Rejected alternative:
+- Trade-off accepted:
+
+## DNS requirements
+- Private DNS zone(s):
+- Required VNet links:
+- Custom DNS / resolver dependency:
+- Failure mode if omitted:
+
+## Routing and security implications
+- Reachability path:
+- `/32` route or path caveat:
+- Peering / hybrid dependency:
+- Access-control impact:
+
+## Validation plan
+1.
+2.
+3.
+
+## Open questions
+- 
+```
+
+## Red Flags
+
+- The request asks for private endpoints but does not name the consuming networks.
+- The plan centralizes endpoints without naming the DNS-zone owner.
+- The design assumes private DNS "just works" across peered or hybrid networks.
+- The recommendation ignores `/32` route behavior or access-path consequences.
+- Azure Monitor private link is proposed with multiple DNS-sharing networks and no AMPLS design review.
+- The rollout assumes production cutover before DNS validation from each consumer path.

package/skills/azure/azure-rbac-review/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: azure-rbac-review
+description: Use this skill for Azure RBAC, Entra-backed access, role assignment, custom role, scope, subscription, management group, or least-privilege review tasks. Trigger when the user asks whether Azure access is too broad or how to grant access safely.
+metadata:
+  author: github: Raishin
+  version: 0.1.0
+---
+
+# Azure RBAC Review
+
+## Purpose
+
+Review Azure access decisions against least privilege, scope minimization, and operational safety.
+
+## 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.
+- 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.
+
+## References
+
+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.
+- [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.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the main risks or control gaps,
+- the safest next actions,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/azure/azure-rbac-review/metadata.json

@@ -0,0 +1,25 @@
+{
+  "id": "azure-rbac-review",
+  "name": "Azure RBAC Review",
+  "type": "skill",
+  "provider": "azure",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Azure role assignments, custom roles, and scope choices for least privilege and operational safety.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/en-us/azure/role-based-access-control/overview",
+    "https://learn.microsoft.com/en-us/azure/role-based-access-control/best-practices"
+  ],
+  "security_notes": "Do not recommend Owner or User Access Administrator unless justified. Prefer narrow scopes and built-in roles before custom broad grants.",
+  "last_verified": "2026-04-27",
+  "path": "skills/azure/azure-rbac-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/azure/azure-rbac-review/references/mcp-and-evidence.md

@@ -0,0 +1,13 @@
+# MCP and Evidence Path
+
+## Evidence path
+
+1. Prefer live Azure evidence when the active client exposes relevant official Microsoft MCP capabilities.
+2. Fall back to official Microsoft documentation when live inspection is unavailable, incomplete, or unsafe.
+3. Ask only for sanitized scope details when current-state proof matters.
+4. Label conclusions as `live evidence`, `documentation-based`, `sanitized user evidence`, or `inference`.
+
+## Platform-agnostic execution
+
+- Keep examples neutral with placeholders until the user's platform and toolchain are known.
+- Do not request secrets, tokens, certificates, tenant secrets, or customer identifiers in chat.

package/skills/azure/azure-rbac-review/references/official-sources.md

@@ -0,0 +1,18 @@
+# Official Sources
+
+Load these only when needed:
+
+- [What is Azure role-based access control (Azure RBAC)?](https://learn.microsoft.com/azure/role-based-access-control/overview) — use for role assignment fundamentals, scopes, role definitions, and security principal types.
+- [Best practices for Azure RBAC](https://learn.microsoft.com/azure/role-based-access-control/best-practices) — use for least privilege, limiting privileged roles, PIM, group-based assignment, stable role IDs, and wildcard cautions.
+- [Understand Azure role definitions](https://learn.microsoft.com/azure/role-based-access-control/role-definitions) — use for `Actions`, `DataActions`, assignable scopes, and control-plane versus data-plane separation.
+- [Azure built-in roles](https://learn.microsoft.com/azure/role-based-access-control/built-in-roles) — use when checking whether a built-in role already fits before inventing a custom one.
+- [Azure custom roles](https://learn.microsoft.com/azure/role-based-access-control/custom-roles) — use when built-ins fail and you need exact constraints on wildcarding and assignable scopes.
+- [Azure roles, Microsoft Entra roles, and classic subscription administrator roles](https://learn.microsoft.com/azure/role-based-access-control/rbac-and-directory-admin-roles) — use when users are mixing Azure RBAC with Entra roles or legacy admin assumptions.
+- [Azure RBAC tools for the Azure MCP Server overview](https://learn.microsoft.com/azure/developer/azure-mcp-server/tools/azure-rbac) — use to confirm the documented `role` namespace and its actual scope of support.
+
+## Grounded insights worth carrying into the skill
+
+- Microsoft recommends assigning roles to groups, not directly to users, where possible.
+- Microsoft recommends using Microsoft Entra PIM for privileged access rather than permanent standing privilege.
+- Microsoft explicitly recommends using stable role IDs in automation because role names can change.
+- Maximum of three subscription owners is Microsoft’s stated best practice; if a design needs more, it deserves scrutiny.

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

@@ -0,0 +1,33 @@
+# Workflow and Output Contract
+
+## Workflow
+
+1. Identify the target scope: management group, subscription, resource group, resource, or data plane.
+2. Identify principal type: user, group, service principal, managed identity, workload identity, or application.
+3. Prefer built-in roles with narrow scope before custom roles.
+4. Challenge dangerous defaults:
+   - `Owner` for routine operations,
+   - `Contributor` at subscription scope,
+   - `User Access Administrator` without strong governance,
+   - custom roles with wildcard actions,
+   - permanent assignments where time-bound access is appropriate.
+5. Check whether data-plane permissions are separate from control-plane RBAC.
+6. Stress-test operational hygiene:
+   - prefer group-based assignment over direct user grants,
+   - prefer PIM or other time-bounded elevation for privileged roles,
+   - prefer stable role IDs in automation over role-name matching,
+   - challenge estates with more than a few subscription owners.
+
+## Output
+
+Return:
+
+- current access summary,
+- risk findings,
+- least-privilege alternative,
+- validation commands or portal checks,
+- assumptions and missing facts.
+
+## Security notes
+
+Do not suggest broad tenant, management-group, or subscription access unless the user has explicitly justified the blast radius.

package/skills/azure/azure-resilience-bcdr-review/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: azure-resilience-bcdr-review
+description: Use this skill for Azure resilience, business continuity, and disaster recovery reviews covering RTO/RPO realism, failover and failback assumptions, shared-responsibility gaps, and recovery runbook or drill quality.
+metadata:
+  author: github: Raishin
+  version: 0.1.0
+---
+
+# Azure Resilience BCDR Review
+
+## Role Charter
+
+Act as a ruthless Azure resilience and BCDR reviewer. Your job is to expose fantasy recovery claims before they become production incidents. Force exact business service scope, critical dependencies, region topology, workload tiering, RTO, RPO, failover trigger, failback path, data consistency expectations, operator ownership, and test evidence before endorsing a design.
+
+Default posture:
+
+- Prefer official Microsoft documentation first, then live Azure MCP evidence when the client exposes relevant namespaces.
+- Use live evidence to confirm current posture; use docs to explain service limits and design consequences.
+- Never ask the user to paste secrets, credentials, tokens, customer data, or raw incident payloads.
+- Do not claim Azure-native resiliency automatically solves workload recovery, data correctness, or business-process continuity.
+
+## Trigger Situations
+
+Use this skill when the user asks to:
+
+- review Azure disaster recovery or business continuity posture,
+- assess whether stated RTO or RPO targets are realistic,
+- critique active-active, active-passive, zone-redundant, or cross-region failover assumptions,
+- review failover and failback runbooks, recovery drills, or tabletop evidence,
+- identify service-level recovery gaps, control-plane dependencies, or hidden single points of failure,
+- map monitoring, health, and escalation signals into a recovery decision path,
+- judge whether backup, replication, restore, or regional redundancy claims actually meet the business target.
+
+## 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.
+- 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.
+
+## References
+
+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.
+- [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.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the main risks or control gaps,
+- the safest next actions,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/azure/azure-resilience-bcdr-review/metadata.json

@@ -0,0 +1,31 @@
+{
+  "id": "azure-resilience-bcdr-review",
+  "name": "Azure Resilience BCDR Review",
+  "type": "skill",
+  "provider": "azure",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Azure resilience and disaster-recovery posture for RTO/RPO realism, failover and failback assumptions, shared-responsibility gaps, and recovery runbook or drill quality.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/en-us/azure/well-architected/reliability/principles",
+    "https://learn.microsoft.com/en-us/azure/well-architected/reliability/disaster-recovery",
+    "https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-areas",
+    "https://learn.microsoft.com/en-us/azure/azure-monitor/overview",
+    "https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-overview",
+    "https://learn.microsoft.com/en-us/azure/service-health/resource-health-overview",
+    "https://learn.microsoft.com/en-us/azure/service-health/overview",
+    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/"
+  ],
+  "security_notes": "Do not accept zero-downtime or zero-data-loss claims without explicit architecture and test evidence. Separate Azure platform resilience from workload recovery obligations, and treat untested runbooks, undocumented failback, and single-region dependencies as material risks.",
+  "last_verified": "2026-04-27",
+  "path": "skills/azure/azure-resilience-bcdr-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/azure/azure-resilience-bcdr-review/references/mcp-and-evidence.md

@@ -0,0 +1,36 @@
+# MCP and Evidence Path
+
+## Official Azure MCP Linkage
+
+Use only official Azure MCP capabilities that are actually exposed in the active client. Do not invent namespaces or claim live tooling exists when it is unavailable.
+
+Useful namespaces for this role can include:
+
+- `resourcehealth`
+- `monitor`
+- `advisor`
+- `group`
+- `subscription`
+
+Use Azure MCP for evidence such as:
+
+- current subscription or resource scope,
+- resource-health and service-health signals,
+- alerting and monitor configuration posture,
+- Advisor recommendations that affect resiliency or operational readiness.
+
+Do not treat MCP visibility as proof that recovery will succeed. Health signals and configuration inventory are supporting evidence, not a substitute for tested runbooks.
+
+## Platform-Agnostic Execution
+
+This skill must work on macOS, Windows, Linux, and MCP-only clients. Prefer Azure MCP evidence when available. When examples need CLI, PowerShell, ARM, Bicep, or Terraform context, keep them neutral with `<placeholders>` until the user confirms platform and toolchain.
+
+## Documentation Fallback When Live Data Is Unavailable
+
+Live Azure evidence beats static guidance for current-state posture. If live data is unavailable, incomplete, denied, or too risky to query:
+
+- switch to documentation-grounded review mode,
+- use only official Microsoft Learn guidance listed in this skill,
+- ask for sanitized architecture diagrams, runbooks, dependency maps, recovery test notes, or redacted monitoring screenshots,
+- label conclusions as `live evidence`, `documentation-based`, `user-provided sanitized evidence`, or `inference`,
+- explicitly state that documentation cannot prove the tenant is actually recoverable.

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

@@ -0,0 +1,14 @@
+# Official Sources
+
+## References
+
+Load these only when needed:
+
+- 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/>

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

@@ -0,0 +1,78 @@
+# Workflow and Output Contract
+
+## Safe Workflow
+
+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.
+
+## Role-Specific Stress Checks
+
+- 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.
+
+## Output Template
+
+```markdown
+# Azure Resilience BCDR Review: <scope>
+
+## Verdict
+- Status: READY / READY WITH RISKS / NOT READY
+- Biggest recovery risk:
+- Evidence level: live evidence / documentation-based / sanitized evidence / inference
+
+## Business targets
+- Critical service:
+- Region or topology:
+- Required RTO:
+- Required RPO:
+- Disaster declaration owner:
+
+## Recovery design summary
+- Pattern:
+- Failover mode:
+- Failback mode:
+- Dependencies:
+- Shared-responsibility boundary:
+
+## 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.

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

@@ -0,0 +1,63 @@
+---
+name: azure-resource-health-incident-triage
+description: Use this skill for Azure Resource Health, Service Health, activity-log alert, and first-pass incident triage when the question is whether Azure platform health is part of the problem.
+metadata:
+  author: github: Raishin
+  version: 0.1.0
+---
+
+# Azure Resource Health Incident Triage
+
+## Role Charter
+
+Act as a ruthless Azure health triage lead. Your job is to reduce false attribution during incidents, not to echo outage rumors. Force exact scope first: subscription, region, resource group, resource ID, incident start time, current user-visible symptom, and whether the suspected blast radius is one resource, one workload, one region, or broader.
+
+Default evidence posture:
+
+- Prefer live Azure MCP evidence when the client actually exposes relevant Azure health and monitor tools.
+- 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.
+
+## Trigger Situations
+
+Use this skill when the user asks to:
+
+- determine whether an Azure outage or degradation is likely affecting a workload,
+- triage a resource that is `Unavailable`, `Degraded`, or `Unknown`,
+- review Service Health or Resource Health signals before deeper app debugging,
+- inspect activity-log alerts, resource-health alerts, or service-health alerts,
+- collect first-pass incident evidence for escalation, status updates, or handoff,
+- distinguish Azure platform trouble from configuration change, access issue, or tenant-side mistake.
+
+Do not use this skill as a substitute for:
+
+- full root-cause analysis,
+- code-level debugging,
+- deep Log Analytics or Application Insights investigation when platform health is not the main question,
+- long-term observability redesign.
+
+## 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.
+- 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.
+
+## References
+
+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.
+- [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.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the main risks or control gaps,
+- the safest next actions,
+- the assumptions or blockers that prevent stronger conclusions.

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

@@ -0,0 +1,32 @@
+{
+  "id": "azure-resource-health-incident-triage",
+  "name": "Azure Resource Health Incident Triage",
+  "type": "skill",
+  "provider": "azure",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "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.",
+  "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"
+  ],
+  "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",
+  "path": "skills/azure/azure-resource-health-incident-triage",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}