@raishin/vanguard-frontier-agentic 2.8.0 → 2.10.0

package/skills/azure/azure-platform-automation-devops/metadata.json

@@ -11,23 +11,20 @@
     "kiro",
     "other"
   ],
-  "summary": "Design and review Azure platform automation delivery across landing-zone IaC choices, bootstrap-versus-run separation, infra-versus-app pipelines, secret handling, validation gates, and safe rollout patterns.",
+  "summary": "Design and review Azure platform automation delivery across landing-zone IaC choices, bootstrap-versus-run separation, infra-versus-app pipelines, secret handling, what-if validation, approval gates, and safe rollout patterns.",
   "source_type": "original",
   "official_docs": [
-    "https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/",
-    "https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/implementation-options",
-    "https://learn.microsoft.com/en-us/azure/architecture/landing-zones/bicep/landing-zone-bicep",
-    "https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/terraform-landing-zone",
-    "https://learn.microsoft.com/en-us/azure/app-service/deploy-best-practices",
-    "https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots?view=azure-devops-2020",
-    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/",
-    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/azure-deploy",
-    "https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/bicep-mcp-server",
-    "https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/"
+    "https://learn.microsoft.com/azure/azure-resource-manager/bicep/deploy-what-if",
+    "https://learn.microsoft.com/training/modules/test-bicep-code-using-github-actions/",
+    "https://learn.microsoft.com/training/modules/test-bicep-code-using-azure-pipelines/",
+    "https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/",
+    "https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/implementation-options",
+    "https://learn.microsoft.com/azure/architecture/landing-zones/bicep/landing-zone-bicep",
+    "https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/terraform-landing-zone"
   ],
-  "security_notes": "Keep bootstrap and steady-state delivery separate, do not mix platform and application pipelines without control boundaries, never store secrets in repo or pipeline definitions, and require preview, validation, approval, and rollback paths before production-impacting Azure changes.",
-  "last_verified": "2026-04-27",
+  "security_notes": "Keep bootstrap and steady-state delivery separate, do not mix platform and application pipelines without control boundaries, never store secrets in repo or pipeline definitions, and require lint, validation, what-if, approval, and rollback paths before production-impacting Azure changes.",
+  "last_verified": "2026-06-05",
   "path": "skills/azure/azure-platform-automation-devops",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.2"
 }

package/skills/azure/azure-platform-automation-devops/references/mcp-and-evidence.md

@@ -1,37 +1,21 @@
-# MCP and Evidence Path
+# MCP and evidence path
 
-## Official Azure MCP Linkage
+Use this reference when deciding how to ground `azure-platform-automation-devops` guidance.
 
-Use only official Azure MCP capabilities that are actually exposed in the active client runtime. Do not invent tools.
+## Evidence order
 
-Preferred official linkage for this role:
+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.
 
-- `deploy` for Azure deployment workflows when the client exposes official Azure deploy tooling.
-- `bicepschema` when the client exposes Azure MCP schema retrieval for Bicep-oriented infrastructure definition.
-- `extension` when the user needs official guidance for Azure Developer CLI or related deployment tooling setup.
+## Boundaries
 
-Rules:
+- Documentation evidence does not prove the user's tenant, subscription, RBAC, quotas, deployed resources, private connectivity, incident state, or production readiness.
+- Sampled read-only evidence proves only the sampled configured environment and time window.
+- User-provided evidence can be incomplete or stale; preserve uncertainty.
+- Never ask for credentials, tokens, secrets, tenant IDs, subscription IDs, resource IDs, customer data, private keys, or raw incident payloads.
 
-- Verify available Azure MCP capabilities from the official Azure MCP tool inventory before leaning on them.
-- Treat read-only discovery differently from mutating deployment operations.
-- Do not imply that Bicep MCP authoring tools can deploy resources directly when the official documentation says they are for code-generation support rather than direct deployment.
-- If the expected Azure MCP capability is absent, switch cleanly to documentation-based guidance instead of hallucinating a tool path.
+## Required phrasing
 
-## Platform-Agnostic Execution
-
-This skill must work across macOS, Windows, Linux, and MCP-only clients.
-
-- Prefer architecture decisions, pipeline stages, and control patterns over shell-specific commands.
-- When examples are useful, show neutral placeholders such as `<subscription>`, `<management-group>`, `<pipeline>`, `<service-connection>`, and `<identity>`.
-- Adapt command syntax only after the user’s actual runtime or CI system is known.
-- Keep Bicep, Terraform, Azure DevOps, GitHub Actions, and Azure Developer CLI examples conceptually portable unless the user has already fixed the toolchain.
-
-## Documentation Fallback When Live Data Is Unavailable
-
-Live Azure MCP evidence beats static guidance for current-state validation. If live Azure inspection is unavailable, incomplete, unsafe, or denied:
-
-- fall back to official Microsoft Learn and Azure Architecture Center guidance listed above,
-- ask for sanitized pipeline structure, repo layout, stage diagram, or redacted deployment definitions if current-state evidence is required,
-- label conclusions as `live evidence`, `documentation-based`, `user-provided sanitized evidence`, or `inference`,
-- do not claim the user’s current pipeline is safe merely because a Microsoft pattern exists,
-- do not claim a tool is available in the user’s runtime unless it was confirmed live.
+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-platform-automation-devops/references/official-sources.md

@@ -1,16 +1,23 @@
-# Official Sources
+# Official sources
 
-## References
+Use this reference when grounding current Azure behavior for `azure-platform-automation-devops`.
 
-Load these only when needed:
+## Microsoft Learn sources
 
-- [Azure landing zone overview](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/) — use for platform-versus-application landing zone boundaries and Microsoft’s recommended Azure landing zone operating model.
-- [Platform landing zone implementation options](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/implementation-options) — use for choosing between IaC accelerator, Bicep, Terraform, and portal-based approaches.
-- [Azure landing zone Bicep guidance](https://learn.microsoft.com/en-us/azure/architecture/landing-zones/bicep/landing-zone-bicep) — use for Bicep accelerator structure, modular delivery, and deployment-stack-aware platform automation.
-- [Terraform landing zone guidance](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/terraform-landing-zone) — use when the user is standardizing on Terraform for Azure landing zone delivery.
-- [Deployment best practices for Azure App Service](https://learn.microsoft.com/en-us/azure/app-service/deploy-best-practices) — use for deployment-source/build/deploy separation, slot-safe release patterns, and production safety.
-- [App Service staging slots](https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots?view=azure-devops-2020) — use for swap-based rollout, warm-up, and rollback patterns.
-- [Azure MCP Server tools inventory](https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/) — use to verify which official Azure MCP capabilities actually exist before suggesting them.
-- [Azure Deploy tools for Azure MCP Server](https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/azure-deploy) — use when live deploy-oriented MCP support is relevant.
-- [Bicep MCP server](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/bicep-mcp-server) — use when schema-aware Bicep authoring support is relevant and to avoid inventing deploy behavior it does not provide.
-- [Bicep documentation](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/) — use for authoritative Bicep deployment, modules, scopes, and what-if references.
+- https://learn.microsoft.com/azure/azure-resource-manager/bicep/deploy-what-if
+- https://learn.microsoft.com/training/modules/test-bicep-code-using-github-actions/
+- https://learn.microsoft.com/training/modules/test-bicep-code-using-azure-pipelines/
+- https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/
+- https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/implementation-options
+- https://learn.microsoft.com/azure/architecture/landing-zones/bicep/landing-zone-bicep
+- https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/terraform-landing-zone
+
+## 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-platform-automation-devops/references/platform-automation-operations.md

@@ -0,0 +1,69 @@
+# Azure Platform Automation 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 green pipeline as proof that a platform change is safe.
+- Mixing bootstrap, shared platform, and workload deployments into one uncontrolled flow.
+- Skipping what-if or equivalent preview because the template compiled.
+- Assuming Bicep, Terraform, or a landing-zone accelerator is automatically the right answer.
+- Putting publish profiles, client secrets, or service connection secrets into repo or chat.
+
+## Officially grounded service shape
+
+- Microsoft Learn evidence says Bicep what-if previews predicted resource changes without making changes and works at resource group, subscription, management group, and tenant scopes.
+- What-if has real limits: nested template expansion limits, short-circuiting, unevaluated expressions, and possible noise from defaulted properties.
+- Microsoft Learn training for Bicep delivery emphasizes linting, preflight validation, what-if checks, manual approval steps, and post-deployment verification.
+- Azure landing-zone guidance separates platform foundations from workload adoption and supports multiple implementation options rather than one universal IaC path.
+
+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
+
+- Classify bootstrap, platform, and workload scope before proposing a pipeline.
+- Require lint, static validation, what-if or equivalent preview, human approval for risky changes, and post-deployment verification.
+- Use least-privilege deployment identities scoped to the deployment boundary.
+- Treat what-if output as evidence with limitations, not as absolute proof of safety.
+- Refuse production rollout advice when rollback, blast radius, or approval ownership is missing.
+
+## Minimal safe implementation flow
+
+- Scope landing zone, subscriptions, management groups, target regions, IaC tool, and owner boundary.
+- Separate bootstrap prerequisites from steady-state platform operations and workload delivery.
+- Review identity, secrets, service connections, module source, state storage, and environment promotion model.
+- Require lint, validation, what-if preview, approval, deployment, smoke checks, and rollback evidence.
+- Return a go, no-go, or conditional-go verdict with blockers and verification targets.
+
+## High-risk assumptions to kill
+
+- A compiled template or green pipeline is not proof of safe platform change; preview, approval, and post-deploy verification are separate evidence gates.
+- What-if is useful but imperfect; nested templates, unevaluated expressions, defaulted properties, and unsupported Deployment Stack what-if paths can hide risk or create noise.
+- A deployment identity that can mutate management groups, subscriptions, networking, and workloads is a blast-radius problem unless explicitly justified and gated.
+- Deployment Stacks add lifecycle ownership; action-on-unmanage and deny settings can detach, delete, or lock resources in ways normal release rollback will not undo.
+- Secret-free automation is non-negotiable: service principals, publish profiles, client secrets, and tenant-specific identifiers do not belong in repo docs or chat.
+
+## Safe command/code verification targets
+
+- Verify Bicep/Terraform lint, schema/preflight validation, what-if/plan output, and manual approval for the exact deployment scope.
+- Inspect preview output for creates, modifies, deletes, ignores, unevaluated expressions, deny settings, and action-on-unmanage behavior.
+- Check deployment identity permissions against least privilege and target boundary before running automation.
+- Confirm environment promotion, module source integrity, state storage, and secret handling are documented and enforced.
+- Verify post-deployment smoke checks, drift checks, and rollback/redeploy limits before calling the platform path production-ready.
+
+## Safe verification targets
+
+- IaC lint and schema validation pass for the exact target scope.
+- What-if preview or equivalent plan is reviewed for create, modify, delete, ignore, and unevaluated-expression risks.
+- Deployment identity permissions match target scope and do not require broad Owner by default.
+- Secrets are stored in approved secret stores or platform-protected variables, not repo files.
+- Rollback or redeploy path is tested or explicitly bounded.
+
+## When to push back
+
+- A single pipeline can mutate management groups, subscriptions, networking, and workloads without gates.
+- The user wants to deploy without reviewing preview output.
+- Secrets or tenant-specific identifiers are requested in chat.
+- The plan confuses application release rollback with platform rollback.

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.