@raishin/vanguard-frontier-agentic 2.7.1 → 2.9.0

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

@@ -1,13 +1,21 @@
-# MCP and Evidence Path
+# MCP and evidence path
 
-## Evidence path
+Use this reference when deciding how to ground `azure-rbac-review` guidance.
 
-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`.
+## Evidence order
 
-## Platform-agnostic execution
+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.
 
-- 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.
+## 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.

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

@@ -1,18 +1,23 @@
-# Official Sources
+# Official sources
 
-Load these only when needed:
+Use this reference when grounding current Azure behavior for `azure-rbac-review`.
 
-- [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.
+## Microsoft Learn sources
 
-## Grounded insights worth carrying into the skill
+- https://learn.microsoft.com/azure/role-based-access-control/overview
+- https://learn.microsoft.com/azure/role-based-access-control/best-practices
+- https://learn.microsoft.com/azure/role-based-access-control/scope-overview
+- https://learn.microsoft.com/azure/role-based-access-control/built-in-roles
+- https://learn.microsoft.com/azure/role-based-access-control/custom-roles
+- https://learn.microsoft.com/azure/role-based-access-control/conditions-overview
+- https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-configure
 
-- 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.
+## 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-rbac-review/references/rbac-review-operations.md

@@ -0,0 +1,69 @@
+# Azure RBAC Review 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
+
+- Giving Owner because the exact job-function role was not checked.
+- Assigning broad roles at subscription or management-group scope for convenience.
+- Creating wildcard custom roles that silently inherit future permissions.
+- Assigning roles directly to users instead of groups or managed identities.
+- Treating RBAC as static and ignoring PIM, reviews, and privileged assignment governance.
+
+## Officially grounded service shape
+
+- Microsoft Learn evidence says Azure RBAC defines who can access Azure resources, what actions they can perform, and where they can perform them.
+- Best practices emphasize least privilege, narrow scope, limiting subscription owners, limiting privileged administrator roles, PIM for time-bound access, assigning roles to groups, using unique role IDs in automation, and avoiding wildcard custom-role permissions.
+- Privileged administrator roles require special scrutiny; where role assignment delegation is needed, conditions can constrain what assignees may grant.
+- Built-in job-function roles should be preferred before custom roles, and custom roles should specify explicit Actions and DataActions.
+
+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 from task-required actions and scope, not from a desired role name.
+- Prefer built-in job-function roles and narrow scopes before custom roles or privileged administrator roles.
+- Use groups or managed identities instead of direct user assignments where operationally possible.
+- Use PIM or time-bound access for elevated privileges.
+- Reject wildcard custom roles unless there is a documented, exceptional justification and compensating review.
+
+## Minimal safe implementation flow
+
+- Scope principal, resource, required actions, data-plane needs, assignment duration, and approval path.
+- Inventory existing assignments and inherited assignments at management group, subscription, resource group, and resource scopes.
+- Compare required actions to built-in roles, then custom role only if necessary.
+- Assess privileged role, PIM, condition, group assignment, and review requirements.
+- Return least-privilege recommendation, risks, rollback/removal plan, and verification query targets.
+
+## High-risk assumptions to kill
+
+- Owner or Contributor is not a default troubleshooting role; job-function built-in roles and narrower scopes must be checked first.
+- A role assignment at management-group or subscription scope multiplies blast radius even if the principal only needs one resource.
+- Direct user assignments and standing privileged access are operational debt unless there is a documented exception.
+- Custom roles with wildcards can silently gain future permissions and are not least privilege.
+- RBAC evidence is incomplete unless inherited assignments, data-plane permissions, PIM eligibility, conditions, and review cadence are considered.
+
+## Safe command/code verification targets
+
+- Inventory direct and inherited assignments for the principal at management group, subscription, resource group, and resource scopes.
+- Compare required management-plane and data-plane actions against built-in job-function roles before custom role design.
+- Check privileged administrator roles, assignment conditions, PIM/time-bound controls, group-based assignment, and access review evidence.
+- Verify custom role definitions use explicit Actions/DataActions and stable role IDs for automation.
+- Provide removal/expiry verification so access can be cleanly revoked after the task.
+
+## Safe verification targets
+
+- Chosen role grants only required management-plane and data-plane actions.
+- Assignment scope is the narrowest workable scope.
+- Privileged administrator roles are absent or explicitly justified with PIM/time-bound controls.
+- Custom roles avoid wildcards and use explicit Actions/DataActions.
+- Role assignment can be removed or expires cleanly after the task.
+
+## When to push back
+
+- The user asks for Owner without proving why narrower roles fail.
+- The request grants permissions to an individual user for a standing operational pattern.
+- The custom role uses wildcard permissions.
+- The target scope is broader than the resource set named in the task.

package/skills/azure/azure-rbac-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-rbac-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-rbac-review/references/workflow-and-output.md

@@ -1,33 +1,41 @@
-# Workflow and Output Contract
+# Workflow and output contract
+
+Use this reference for full execution of `azure-rbac-review`.
 
 ## 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
+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.
 
-Return:
+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.
 
-- current access summary,
-- risk findings,
-- least-privilege alternative,
-- validation commands or portal checks,
-- assumptions and missing facts.
+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.
 
-## Security notes
+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:
 
-Do not suggest broad tenant, management-group, or subscription access unless the user has explicitly justified the blast radius.
+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-resilience-bcdr-review/SKILL.md

@@ -4,8 +4,8 @@ description: Use this skill for Azure resilience, business continuity, and disas
 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: resilience
 ---
 
@@ -17,8 +17,8 @@ Act as a ruthless Azure resilience and BCDR reviewer. Your job is to expose fant
 
 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.
+- Prefer Microsoft Learn documentation through the user's configured documentation MCP, then sampled read-only Azure evidence when available, then sanitized user evidence.
+- Use sampled read-only evidence to confirm current posture; use documentation 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.
 
@@ -36,7 +36,7 @@ Use this skill when the user asks to:
 
 ## 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.
@@ -45,7 +45,9 @@ Use this skill when the user asks to:
 
 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 Resilience BCDR Operations](references/resilience-bcdr-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-resilience-bcdr-review/metadata.json

@@ -11,21 +11,19 @@
     "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.",
+  "summary": "Review Azure resilience and disaster-recovery posture for business criticality, RTO/RPO realism, failover and failback assumptions, backup/restore, region/zone strategy, recovery automation, runbooks, and drill evidence.",
   "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/"
+    "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"
   ],
-  "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",
+  "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, inaccessible DR assets, and single-region dependencies as material risks.",
+  "last_verified": "2026-06-05",
   "path": "skills/azure/azure-resilience-bcdr-review",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.2"
 }

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

@@ -1,36 +1,21 @@
-# MCP and Evidence Path
+# MCP and evidence path
 
-## Official Azure MCP Linkage
+Use this reference when deciding how to ground `azure-resilience-bcdr-review` guidance.
 
-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.
+## Evidence order
 
-Useful namespaces for this role 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`
-- `monitor`
-- `advisor`
-- `group`
-- `subscription`
+## Boundaries
 
-Use Azure MCP for evidence such as:
+- 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.
 
-- current subscription or resource scope,
-- resource-health and service-health signals,
-- alerting and monitor configuration posture,
-- Advisor recommendations that affect resiliency or operational readiness.
+## Required phrasing
 
-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.
+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-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