@raishin/vanguard-frontier-agentic 2.7.1 → 2.9.0

package/skills/azure/azure-platform-automation-devops/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-platform-automation-devops`.
+
+## 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-platform-automation-devops/references/workflow-and-output.md

@@ -1,109 +1,41 @@
-# Workflow and Output Contract
+# Workflow and output contract
 
-## Safe Workflow
+Use this reference for full execution of `azure-platform-automation-devops`.
 
-1. **Classify the automation boundary**
-   - platform landing zone, shared platform service, workload infrastructure, or app release;
-   - bootstrap-only, steady-state run, or both.
-2. **Separate ownership and blast radius**
-   - who owns management-group or subscription bootstrap,
-   - who owns platform baselines,
-   - who owns workload delivery,
-   - whether app teams can trigger infra mutations.
-3. **Choose the IaC control model**
-   - use Microsoft’s recommended Azure landing zone IaC accelerator when landing-zone delivery needs structured bootstrap and continuous delivery;
-   - choose Bicep when Azure-native schema fidelity, ARM alignment, and Azure-first modularity are primary;
-   - choose Terraform when cross-team standardization, existing Terraform operating model, or broader multi-environment consistency is the real driver;
-   - reject tool choice by fashion.
-4. **Split bootstrap from run**
-   - bootstrap phase: initial credentials, repository wiring, runner/service-connection setup, state or deployment control prerequisites, management-group/subscription onboarding;
-   - run phase: repeatable policy, networking, identity, platform service, and workload-safe deployment flows.
-5. **Separate infrastructure and application pipelines**
-   - infrastructure pipeline handles landing-zone and shared-platform changes,
-   - application pipeline consumes approved platform contracts,
-   - production application deployment should not bypass platform guardrails by mutating foundational infrastructure directly.
-6. **Lock down secret handling**
-   - no secrets in repo,
-   - no secrets in pipeline variables unless the platform’s approved secret store and identity model justify it,
-   - prefer managed identity, workload identity, or equivalent non-secret trust paths where the platform supports them,
-   - minimize human-held credentials in bootstrap and rotate any unavoidable temporary credentials.
-7. **Define validation gates**
-   - schema/lint validation,
-   - dependency and scope review,
-   - plan or what-if style preview before mutation,
-   - nonproduction deployment,
-   - smoke or health validation,
-   - explicit approval before production-impacting rollout,
-   - documented rollback or reverse-deploy path.
-8. **Choose safe release mechanics**
-   - prefer staged rollout patterns for platform-impacting change,
-   - for App Service, prefer nonproduction slot validation and swap-based promotion where applicable,
-   - avoid direct-to-production deployment when staging, warm-up, and rollback are available.
-9. **Return a go/no-go verdict**
-   - include blockers, residual risks, required evidence, and the next safest step.
+## 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 mixes management-group bootstrap, platform governance rollout, and workload deployment into one opaque pipeline with shared credentials.
-- Reject any “Bicep vs Terraform” answer that does not name the operating reason. Tool tribalism is not architecture.
-- Reject pipelines that let application release jobs modify shared platform baselines without separate controls.
-- Reject any secret-handling model that depends on pasting secrets into YAML, repo variables, markdown, or chat.
-- Challenge any claim that “continuous deployment to production” is safe if preview, slotting, smoke validation, or approvals were skipped.
-- Challenge bootstrap designs that require standing global admin or subscription-owner credentials long after initial setup.
-- Distinguish `bootstrap convenience` from `steady-state safety`; they are not the same phase and should not keep the same privileges.
-- Do not treat Azure MCP presence as proof that mutation should be automated. Capability is not authorization.
+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 Platform Automation 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 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.
 
-## Scope
-- Platform boundary:
-- Environment(s):
-- Ownership model:
-- Requested change:
+## Output contract
 
-## Delivery model
-- IaC approach:
-- Why this approach:
-- Bootstrap phase:
-- Run phase:
-- Infra/app pipeline split:
+Return:
 
-## Control and safety findings
-| Area | Finding | Severity | Evidence | Recommendation | Owner |
-|---|---|---|---|---|---|
-
-## Validation gates
-| Gate | Required | Why | Blocking if absent |
-|---|---|---|---|
-
-## Rollout path
-1.
-2.
-3.
-
-## Rollback path
-1.
-2.
-3.
-
-## Open questions
--
-```
-
-## Red Flags
-
-- The plan deploys foundational Azure changes straight to production with no preview, no stage validation, and no rollback.
-- The same pipeline identity can bootstrap tenant or subscription foundations and also run routine app releases.
-- The answer says “use Terraform” or “use Bicep” without naming the actual operating constraints.
-- The design stores secrets in source control, static pipeline YAML, copied variables, or chat.
-- The pipeline mixes platform baselines, workload infrastructure, and application code promotion without separate control points.
-- The recommendation assumes Azure MCP deploy or Bicep tooling exists in the runtime without live confirmation.
-- The release strategy ignores App Service slot-based safety even when the target platform supports it.
+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-private-endpoint-adoption-planner/SKILL.md

@@ -4,8 +4,8 @@ description: Use this skill for Azure Private Link and private endpoint adoption
 allowed-tools: Read Grep Glob WebFetch
 metadata:
   author: github: Raishin
-  version: 0.1.0
-  updated: "2026-05-05"
+  version: 0.1.2
+  updated: "2026-06-05"
   category: networking
 ---
 
@@ -17,9 +17,8 @@ Act as a ruthless Azure private connectivity planner. Your job is to stop weak P
 
 Default posture:
 
-- Prefer official Microsoft Learn and Azure Architecture Center guidance over memory or blog lore.
-- Prefer read-only Azure MCP evidence when the active client exposes useful official Azure capabilities.
-- Do not invent Azure MCP tools or namespaces for private endpoints, DNS, routing, or network topology.
+- 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 Azure evidence only for current-state claims; do not invent tool capabilities for private endpoints, DNS, routing, or network topology.
 - Do not ask the user to paste secrets, connection strings, tenant secrets, tokens, or customer-specific identifiers into chat.
 
 ## Trigger Situations
@@ -44,7 +43,7 @@ Route broader network-architecture reviews toward `azure-network-topology-review
 
 ## 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.
@@ -53,7 +52,9 @@ Route broader network-architecture reviews toward `azure-network-topology-review
 
 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 Private Endpoint Adoption Operations](references/private-endpoint-adoption-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-private-endpoint-adoption-planner/metadata.json

@@ -11,20 +11,19 @@
     "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.",
+  "summary": "Plan Azure Private Link and private endpoint adoption with explicit hub-versus-spoke placement, private DNS zone linkage, DNS Private Resolver choices, 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/"
+    "https://learn.microsoft.com/azure/private-link/private-endpoint-dns-integration",
+    "https://learn.microsoft.com/azure/private-link/private-endpoint-dns",
+    "https://learn.microsoft.com/azure/cloud-adoption-framework/ready/azure-best-practices/private-link-and-dns-integration-at-scale",
+    "https://learn.microsoft.com/azure/architecture/networking/guide/private-link-virtual-wan-dns-guide",
+    "https://learn.microsoft.com/azure/dns/private-resolver-endpoints-rulesets",
+    "https://learn.microsoft.com/azure/networking/foundations/network-foundations-overview"
   ],
-  "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",
+  "security_notes": "Do not recommend private endpoint placement without naming consumer networks, private DNS zone ownership, VNet links, DNS forwarding path, route implications, and rollback checks. Challenge both over-centralized hub designs and uncontrolled per-spoke duplication.",
+  "last_verified": "2026-06-05",
   "path": "skills/azure/azure-private-endpoint-adoption-planner",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.2"
 }

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

@@ -1,26 +1,21 @@
-# MCP and Evidence Path
+# MCP and evidence path
 
-## Official Azure MCP Linkage
+Use this reference when deciding how to ground `azure-private-endpoint-adoption-planner` guidance.
 
-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.
+## Evidence order
 
-Safe rule:
+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.
 
-- 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.
+## Boundaries
 
-## Platform-Agnostic Execution
+- 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.
 
-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.
+## Required phrasing
 
-## 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.
+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-private-endpoint-adoption-planner/references/official-sources.md

@@ -1,20 +1,22 @@
-# Official Sources
+# Official sources
 
-## References
+Use this reference when grounding current Azure behavior for `azure-private-endpoint-adoption-planner`.
 
-Load these in order, only as needed:
+## Microsoft Learn sources
 
-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/
+- https://learn.microsoft.com/azure/private-link/private-endpoint-dns-integration
+- https://learn.microsoft.com/azure/private-link/private-endpoint-dns
+- https://learn.microsoft.com/azure/cloud-adoption-framework/ready/azure-best-practices/private-link-and-dns-integration-at-scale
+- https://learn.microsoft.com/azure/architecture/networking/guide/private-link-virtual-wan-dns-guide
+- https://learn.microsoft.com/azure/dns/private-resolver-endpoints-rulesets
+- https://learn.microsoft.com/azure/networking/foundations/network-foundations-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-private-endpoint-adoption-planner/references/private-endpoint-adoption-operations.md

@@ -0,0 +1,69 @@
+# Azure Private Endpoint Adoption 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
+
+- Treating a private endpoint as complete before DNS resolution is designed.
+- Creating duplicate private DNS zones with the same name across VNets and hoping Azure merges records.
+- Linking private DNS zones to the wrong VNets in hub-spoke or Virtual WAN topologies.
+- Assuming central hub placement is always safer than workload-local endpoints.
+- Ignoring private endpoint record lifecycle when endpoints are deleted or moved.
+
+## Officially grounded service shape
+
+- Microsoft Learn evidence says the service FQDN must resolve to the private endpoint IP, so DNS configuration is central to Private Link success.
+- For peered hub-spoke workloads, Microsoft Learn calls for a single private DNS zone linked to all hub and spoke networks that need resolution.
+- DNS zone groups associate private endpoints with private DNS zones and can manage records as endpoints change or are deleted, within documented limits.
+- At scale, central private DNS zones, policy-driven DNS zone groups, DNS Private Resolver, conditional forwarding, and regional endpoint strategy become governance decisions.
+
+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
+
+- Design DNS before endpoint placement.
+- Use the recommended private DNS zone name for each Azure service and avoid mixing unrelated services in one zone.
+- Name every consumer VNet, peering path, hub, resolver, and on-premises forwarding dependency.
+- Decide central versus workload-local endpoint placement from traffic flow, ownership, and regional resilience, not aesthetics.
+- Require rollback checks for DNS records, VNet links, firewall/DNS proxy settings, and application connection strings.
+
+## Minimal safe implementation flow
+
+- Scope PaaS services, consumers, regions, subscriptions, VNets, and current DNS authority.
+- Map resolution path from each consumer to the private endpoint FQDN and private IP.
+- Choose endpoint placement and DNS zone ownership pattern.
+- Define IaC or policy mechanism for DNS zone group creation and record lifecycle.
+- Validate name resolution, connectivity, routing, monitoring, and rollback before broad rollout.
+
+## High-risk assumptions to kill
+
+- Private endpoint creation without DNS design is incomplete; Microsoft Learn is blunt that DNS is critical for correct private endpoint connectivity.
+- Overriding an actively used public zone without forwarding can break existing public endpoint resolution.
+- Same-name private DNS zones and mixed-service records can delete or conflict with records and cause intermittent resolution failures.
+- Hub-hosted central DNS does not prove every spoke, on-premises resolver, and private endpoint consumer resolves through the intended path.
+- A successful test from one VNet is not evidence for peered VNets, on-premises clients, hybrid DNS, or regional failover paths.
+
+## Safe command/code verification targets
+
+- Verify service-specific private DNS zone names, DNS zone groups, A records, VNet links, resolver/forwarder paths, and endpoint network interfaces.
+- Test FQDN resolution to private IP from each consumer network, including hub, spoke, and on-premises paths where applicable.
+- Check for duplicate same-name zones, mixed-service records, missing VNet links, and stale records after endpoint deletion or movement.
+- Confirm firewall, DNS proxy, Private Resolver, and conditional forwarding behavior before broad rollout.
+- Validate rollback by restoring DNS path, public access posture, connection strings, and endpoint record lifecycle.
+
+## Safe verification targets
+
+- Private DNS zones match Microsoft service-specific zone names.
+- Required VNets are linked to the authoritative private DNS zones.
+- On-premises or custom DNS forwards to the correct resolver path.
+- Endpoint FQDN resolves to expected private IP from each consumer network.
+- Deleting or moving endpoints has a defined DNS cleanup path.
+
+## When to push back
+
+- The design says “private endpoint enabled” but cannot explain DNS.
+- Multiple same-name zones are proposed without record-management ownership.
+- Virtual WAN DNS behavior is assumed to match traditional hub-spoke behavior.
+- The rollout has no staged validation or rollback for application connectivity.

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"
 }