@raishin/vanguard-frontier-agentic 2.8.0 → 2.10.0

package/skills/azure/azure-private-endpoint-adoption-planner/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-private-endpoint-adoption-planner`.
+
+## 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-private-endpoint-adoption-planner/references/workflow-and-output.md

@@ -1,100 +1,41 @@
-# Workflow and Output Contract
+# Workflow and output contract
 
-## Safe Workflow
+Use this reference for full execution of `azure-private-endpoint-adoption-planner`.
 
-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.
+## 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.
 
-- 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.
+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 Private Endpoint Adoption 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
-- Primary decision: HUB / SPOKE / MIXED
-- 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.
 
-## Scope
-- Target service(s):
-- Consumer network(s):
-- Subscription / resource-group boundary:
-- Shared or workload-specific:
-- Requested action:
+## Output contract
 
-## Placement recommendation
-- Recommended pattern:
-- Why:
-- Rejected alternative:
-- Trade-off accepted:
+Return:
 
-## 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.
+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-rbac-review/SKILL.md

@@ -4,8 +4,8 @@ description: Use this skill for Azure RBAC, Entra-backed access, role assignment
 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: security
 ---
 
@@ -17,7 +17,7 @@ Review Azure access decisions against least privilege, scope minimization, and o
 
 ## 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.
@@ -26,7 +26,9 @@ Review Azure access decisions against least privilege, scope minimization, and o
 
 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 RBAC Review Operations](references/rbac-review-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-rbac-review/metadata.json

@@ -11,15 +11,20 @@
     "kiro",
     "other"
   ],
-  "summary": "Review Azure role assignments, custom roles, and scope choices for least privilege and operational safety.",
+  "summary": "Review Azure role assignments, custom roles, privileged administrator roles, conditions, PIM usage, group-based assignment, 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"
+    "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"
   ],
-  "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",
+  "security_notes": "Do not recommend Owner, Contributor, User Access Administrator, Role Based Access Control Administrator, wildcard custom roles, direct user grants, or broad scopes unless the business need is proven and safer job-function, group-based, conditioned, or time-bound alternatives are insufficient.",
+  "last_verified": "2026-06-05",
   "path": "skills/azure/azure-rbac-review",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.2"
 }

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.