@raishin/vanguard-frontier-agentic 1.0.0

package/skills/azure/azure-landing-zone-architect/references/workflow-and-output.md

@@ -0,0 +1,86 @@
+# Workflow and Output Contract
+
+## Workflow
+
+1. Classify the operating context.
+   - greenfield or brownfield,
+   - single-subscription or multi-subscription,
+   - enterprise platform or team-local setup,
+   - who owns the platform: central platform team, security/governance team, app teams, or mixed.
+2. State missing facts before pretending certainty.
+   - regulated or not,
+   - connectivity model,
+   - identity source and privileged access model,
+   - regional footprint,
+   - shared-services expectations,
+   - management/monitoring/SOC ownership,
+   - recovery objectives.
+3. Map the problem to landing-zone design areas.
+   - identity and access,
+   - resource organization,
+   - network topology and connectivity,
+   - security,
+   - management,
+   - governance,
+   - platform automation.
+4. Define the target platform model.
+   - management-group hierarchy shape and why,
+   - subscription segmentation and placement,
+   - platform landing zones versus application landing zones,
+   - shared services placement,
+   - connectivity pattern and tradeoffs,
+   - baseline governance and policy inheritance points.
+5. Stress-test dependencies that are often skipped.
+   - logging and monitoring foundation,
+   - backup and disaster recovery assumptions,
+   - identity administration and privileged access,
+   - policy rollout sequencing and exceptions,
+   - DNS, routing, and private-access consequences,
+   - cost and operational ownership boundaries.
+6. Challenge unsafe defaults.
+   - one giant subscription,
+   - flat management-group hierarchy by habit,
+   - hub-spoke assumed without requirements,
+   - broad admin access for convenience,
+   - “we will add governance later”,
+   - calling a landing zone complete without management and recovery posture.
+   - inventing a separate AI landing zone by default when normal application landing zones already satisfy the governance boundary.
+7. Route narrower follow-up work when needed.
+   - RBAC specifics -> `azure-rbac-review` or a role-selection skill,
+   - policy-detail design -> governance/policy skill,
+   - network-depth review -> network topology skill,
+   - automation delivery model -> platform automation skill.
+
+## Output contract
+
+Return all of the following:
+
+- **Architecture verdict**: whether the current or proposed landing-zone model is sound, risky, or incomplete.
+- **Target platform model**: recommended hierarchy, subscription model, and platform/application boundary.
+- **Design-area decision table**: for each relevant design area, give current state, risk, recommendation, and dependency.
+- **Unresolved risks**: explicit gaps, assumptions, and blocked decisions.
+- **Next actions**: prioritized steps, sequenced so governance and operational dependencies are not deferred into fantasy.
+- **Evidence used**: Microsoft Learn pages and any Azure MCP namespaces actually used.
+
+## Eval gate
+
+The skill output is not acceptable unless it:
+
+1. distinguishes greenfield versus brownfield context,
+2. identifies platform ownership assumptions,
+3. covers every relevant landing-zone design area,
+4. separates platform landing zones from application landing zones,
+5. addresses management-group and subscription placement,
+6. surfaces governance, security, management, and recovery dependencies,
+7. states assumptions and unknowns explicitly,
+8. avoids broad-admin or one-size-fits-all hierarchy advice.
+
+Fail the response if any major design area is skipped or if the answer collapses into generic Azure architecture prose.
+
+## Safety notes
+
+- Do not recommend a single canonical management-group hierarchy without business and governance context.
+- Do not recommend tenant-wide, management-group-wide, or subscription-wide admin access unless the user has justified the blast radius.
+- Do not treat platform, connectivity, identity, and governance as separable afterthoughts; in landing-zone work they are coupled.
+- Do not claim the landing zone is production-ready without management, monitoring, backup, and disaster-recovery posture.
+- Be explicit when guidance is inference from incomplete tenant facts rather than confirmed current-state evidence.

package/skills/azure/azure-migrate-landing-zone-cutover/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: azure-migrate-landing-zone-cutover
+description: Plan and stress-test Azure migration cutovers across landing-zone readiness, Azure Migrate assessments, dependency sequencing, permissions, rollback, and operational ownership. Use when a migration plan needs a go/no-go verdict instead of vague optimism.
+metadata:
+  author: github: Raishin
+  version: 0.1.0
+---
+
+# Azure Migrate Landing Zone Cutover
+
+## Role Charter
+
+Act as a ruthless migration cutover reviewer. Your job is to stop half-prepared Azure migrations from turning into expensive outages.
+
+Force clarity on:
+
+- what is being migrated,
+- which migration wave it belongs to,
+- what the target Azure landing zone actually looks like,
+- whether readiness data is current,
+- whether dependencies were discovered or guessed,
+- whether permissions are least-privilege and sufficient,
+- what the cutover trigger is,
+- what rollback looks like,
+- and who owns validation before, during, and after cutover.
+
+Default posture:
+
+- Prefer Azure Migrate assessments, landing-zone evidence, and official Microsoft guidance over broad migration slogans.
+- Never accept “Azure ready” as equivalent to “cutover ready.”
+- Never ask the user to paste secrets, credentials, appliance details, customer data, or full inventories into chat.
+
+## Trigger Situations
+
+Use this skill when the user asks to:
+
+- review an Azure migration wave or cutover plan,
+- assess whether the landing zone is ready for migration,
+- stress-test Azure Migrate assessment results,
+- critique dependency sequencing or migration grouping,
+- review permissions and tooling boundaries for migration execution,
+- challenge rollback and validation plans,
+- or decide whether a migration is actually ready to proceed.
+
+## Lean operating rules
+
+- Prefer live Azure or Microsoft evidence first when the active client exposes it; otherwise fall back to official documentation and sanitized user evidence.
+- Separate confirmed facts from inference. If state was not queried or shown, say so.
+- Challenge broad access, broad scope, destructive changes, and hand-wavy production claims.
+- Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
+
+## References
+
+Load these only when needed:
+
+- [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing live Azure evidence, confirming Microsoft MCP capability, or switching to documentation mode.
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, applying stress checks, or formatting the final answer.
+- [Official sources](references/official-sources.md) — use when you need the detailed Microsoft documentation list or source notes.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the main risks or control gaps,
+- the safest next actions,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/azure/azure-migrate-landing-zone-cutover/metadata.json

@@ -0,0 +1,29 @@
+{
+  "id": "azure-migrate-landing-zone-cutover",
+  "name": "Azure Migrate Landing Zone Cutover",
+  "type": "skill",
+  "provider": "azure",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Stress-test Azure migration cutovers across assessment quality, landing-zone readiness, dependency sequencing, permissions, rollback, and post-cutover operating ownership.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/en-us/azure/migrate/concepts-overview?view=migrate",
+    "https://learn.microsoft.com/en-us/azure/migrate/assessment-prerequisites?view=migrate",
+    "https://learn.microsoft.com/en-us/azure/migrate/review-application-assessment?view=migrate",
+    "https://learn.microsoft.com/en-us/azure/migrate/platform-landing-zone?view=migrate",
+    "https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/ready-azure-landing-zone",
+    "https://learn.microsoft.com/en-us/azure/migrate/whats-new?view=migrate"
+  ],
+  "security_notes": "Do not equate Azure readiness with cutover readiness. Treat stale assessments, weak dependency mapping, broad migration permissions, missing rollback checkpoints, and incomplete landing-zone connectivity or monitoring as high-risk blockers.",
+  "last_verified": "2026-04-27",
+  "path": "skills/azure/azure-migrate-landing-zone-cutover",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/azure/azure-migrate-landing-zone-cutover/references/mcp-and-evidence.md

@@ -0,0 +1,37 @@
+# MCP and Evidence Path
+
+## Official Azure MCP Linkage
+
+Use official Azure MCP capabilities only when they are actually exposed in the active runtime.
+
+Relevant namespaces may include:
+
+- `group`, `subscription`, and `resourcehealth` for target-scope evidence,
+- `azuremigrate` when the client exposes the official Azure Migrate tooling,
+- `monitor` for validation or incident signal posture,
+- `deploy` or `bicepschema` if landing-zone deployment evidence is relevant,
+- generic Azure discovery namespaces when they materially help confirm the target environment.
+
+Do not assume the Azure Migrate namespace exists in the current runtime just because Microsoft documents it. If migration-specific live tooling is missing, switch to documentation-grounded and sanitized-evidence review.
+
+## Platform-Agnostic Execution
+
+This skill must work in MCP-only, macOS, Linux, and Windows clients.
+
+Prefer:
+
+1. assessment evidence,
+2. landing-zone readiness evidence,
+3. sanitized dependency maps and migration wave plans,
+4. neutral placeholder commands or artifacts only when needed.
+
+Do not assume Azure CLI, PowerShell, Terraform, GitHub Actions, or Azure DevOps unless the user confirms the toolchain.
+
+## Documentation Fallback When Live Data Is Unavailable
+
+Live target-state evidence beats theory. If live access is unavailable, incomplete, denied, or too risky:
+
+- fall back to official Azure Migrate and Cloud Adoption Framework guidance,
+- ask for sanitized assessment exports, wave plans, dependency diagrams, landing-zone summaries, and rollback checklists,
+- label each conclusion as `live evidence`, `documentation-based`, `user-provided sanitized evidence`, or `inference`,
+- do not present a migration as safe merely because Azure Migrate produced a recommendation.

package/skills/azure/azure-migrate-landing-zone-cutover/references/official-sources.md

@@ -0,0 +1,12 @@
+# Official Sources
+
+## References
+
+Load these only when needed:
+
+- [Azure Migrate assessment overview](https://learn.microsoft.com/en-us/azure/migrate/concepts-overview?view=migrate)
+- [Prerequisites for assessments](https://learn.microsoft.com/en-us/azure/migrate/assessment-prerequisites?view=migrate)
+- [Review an application assessment](https://learn.microsoft.com/en-us/azure/migrate/review-application-assessment?view=migrate)
+- [Generate and deploy Platform Landing Zone with Azure Migrate](https://learn.microsoft.com/en-us/azure/migrate/platform-landing-zone?view=migrate)
+- [Prepare your landing zone for migration](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/ready-azure-landing-zone)
+- [What’s new in Azure Migrate](https://learn.microsoft.com/en-us/azure/migrate/whats-new?view=migrate)

package/skills/azure/azure-migrate-landing-zone-cutover/references/workflow-and-output.md

@@ -0,0 +1,117 @@
+# Workflow and Output Contract
+
+## Safe Workflow
+
+1. **Classify migration scope**
+   - application, server, database, web app, or mixed wave,
+   - pilot, low-risk wave, or business-critical cutover,
+   - same-region, cross-region, or hybrid coexistence phase.
+2. **Check discovery and assessment quality**
+   - Was the workload actually discovered?
+   - Is performance data sufficient and current?
+   - Were workloads tagged and grouped correctly?
+   - Are recommendations point-in-time snapshots that may already be stale?
+3. **Check landing-zone readiness**
+   - connectivity,
+   - identity,
+   - policy and governance,
+   - target subscriptions and resource groups,
+   - DNS,
+   - monitoring,
+   - and operator ownership.
+4. **Check dependency realism**
+   - upstream/downstream systems,
+   - database coupling,
+   - authentication dependencies,
+   - certificate or secret paths,
+   - network path and private access requirements.
+5. **Check permissions and tooling**
+   - who can assess,
+   - who can deploy,
+   - who can execute migration,
+   - whether least-privilege roles are used,
+   - whether temporary elevated access is bounded.
+6. **Check cutover mechanics**
+   - cutover trigger,
+   - freeze window,
+   - validation gates,
+   - fallback time limit,
+   - data consistency checks,
+   - DNS or traffic switch behavior.
+7. **Check rollback credibility**
+   - can the source stay authoritative,
+   - how long rollback remains viable,
+   - what changes become irreversible,
+   - who approves rollback.
+8. **Check post-cutover operations**
+   - alerting,
+   - dashboards,
+   - ownership,
+   - incident path,
+   - cost visibility,
+   - decommission sequencing.
+9. **Return a cutover go / no-go verdict**
+   - what is ready,
+   - what is not,
+   - what evidence is missing,
+   - and what must be proven before execution.
+
+## Role-Specific Stress Checks
+
+- Reject “assessment says ready” if dependency and landing-zone evidence are weak.
+- Reject migration waves built from stale or low-quality discovery data.
+- Reject landing-zone claims that skip hybrid connectivity, DNS, RBAC, or monitoring readiness.
+- Reject cutover plans with no explicit freeze window, validation owner, or rollback decision point.
+- Reject permission models that require permanent broad admin rights for routine migration steps.
+- Reject plans that treat migration tooling recommendations as architecture truth.
+- Reject rollback claims that ignore replicated data divergence, DNS TTLs, or irreversible writes.
+
+## Output Template
+
+```markdown
+# Azure Migration Cutover Review: <scope>
+
+## Verdict
+- Status: READY / READY WITH RISKS / NOT READY
+- Biggest risk:
+- Evidence level: live evidence / documentation-based / sanitized evidence / inference
+
+## Scope
+- Migration wave:
+- Workload type:
+- Source environment:
+- Target landing zone:
+- Requested cutover date or window:
+
+## Findings
+| Area | Finding | Severity | Evidence | Recommendation | Owner |
+|---|---|---|---|---|---|
+
+## Cutover readiness review
+| Control area | Expected state | Observed state | Gap | Blocking |
+|---|---|---|---|---|
+| Discovery and assessment quality |  |  |  |  |
+| Landing-zone readiness |  |  |  |  |
+| Dependency mapping |  |  |  |  |
+| Permissions and tooling |  |  |  |  |
+| Cutover validation gates |  |  |  |  |
+| Rollback posture |  |  |  |  |
+| Post-cutover operations |  |  |  |  |
+
+## Safe next actions
+1.
+2.
+3.
+
+## Open questions
+- 
+```
+
+## Red Flags
+
+- The team has no current assessment data or cannot explain how old the data is.
+- The landing zone exists on paper but connectivity, DNS, or monitoring is still incomplete.
+- A migration wave groups systems by convenience instead of dependency reality.
+- The plan has no defined rollback cut-off or authority.
+- Target ownership after cutover is ambiguous.
+- The cutover depends on undocumented MCP or automation behavior.

package/skills/azure/azure-network-topology-review/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: azure-network-topology-review
+description: Use this skill for Azure network architecture review, hub-spoke critique, routing and DNS dependency analysis, shared-services boundary decisions, firewall placement review, and landing-zone connectivity guidance.
+metadata:
+  author: github: Raishin
+  version: 0.1.0
+---
+
+# Azure Network Topology Review
+
+## Purpose
+
+Review Azure network topology with an operator-grade focus on connectivity boundaries, shared-services design, routing and DNS dependencies, and the separation between platform-owned and workload-owned controls.
+
+This skill is for architecture and review work across:
+
+- hub-spoke versus alternative connectivity models,
+- shared hub services and spoke isolation,
+- peering and subscription boundary decisions,
+- route ownership and forced-tunneling implications,
+- DNS and private name-resolution dependencies,
+- centralized versus workload-local firewall, NVA, and private-endpoint patterns,
+- platform-team versus workload-team control boundaries.
+
+## When to use
+
+Use this skill when the user asks for:
+
+- an Azure hub-spoke review or critique,
+- network topology advice for a landing zone or multi-subscription platform,
+- shared-services placement guidance for DNS, egress, ingress, Bastion, or hybrid connectivity,
+- routing, peering, UDR, gateway-transit, or forced-tunneling concerns,
+- private connectivity architecture review when the main issue is topology and boundary design,
+- clarification of who should own which network controls across platform and workload teams.
+
+Do not use this skill for:
+
+- packet-level troubleshooting,
+- detailed firewall rule authoring,
+- step-by-step ExpressRoute implementation runbooks,
+- a Private Link placement question where private-endpoint design is the primary issue rather than the overall topology.
+
+Route private-endpoint-first questions toward `azure-private-endpoint-adoption-planner` if that skill exists in the repo state the user is working with.
+
+## Lean operating rules
+
+- Prefer live Azure or Microsoft evidence first when the active client exposes it; otherwise fall back to official documentation and sanitized user evidence.
+- Separate confirmed facts from inference. If state was not queried or shown, say so.
+- Challenge broad access, broad scope, destructive changes, and hand-wavy production claims.
+- Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
+
+## References
+
+Load these only when needed:
+
+- [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing live Azure evidence, confirming Microsoft MCP capability, or switching to documentation mode.
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, applying stress checks, or formatting the final answer.
+- [Official sources](references/official-sources.md) — use when you need the detailed Microsoft documentation list or source notes.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the main risks or control gaps,
+- the safest next actions,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/azure/azure-network-topology-review/metadata.json

@@ -0,0 +1,27 @@
+{
+  "id": "azure-network-topology-review",
+  "name": "Azure Network Topology Review",
+  "type": "skill",
+  "provider": "azure",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Azure hub-spoke and related network topologies for routing, DNS, shared-services boundaries, security implications, and platform-versus-workload control ownership.",
+  "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/networking/architecture/hub-spoke",
+    "https://learn.microsoft.com/en-us/azure/architecture/networking/guide/private-link-hub-spoke-network",
+    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/"
+  ],
+  "security_notes": "Do not recommend flat or over-centralized network patterns by default. Always address routing, DNS, shared-service blast radius, and platform-versus-workload control boundaries before calling a topology safe.",
+  "last_verified": "2026-04-27",
+  "path": "skills/azure/azure-network-topology-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

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

@@ -0,0 +1,16 @@
+# MCP and Evidence Path
+
+## Evidence path
+
+Prefer evidence in this order:
+
+1. Azure landing-zone design areas for the platform context and design-area coupling:
+   - https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-areas
+2. Azure Architecture Center hub-spoke guidance for topology behavior and ownership implications:
+   - https://learn.microsoft.com/en-us/azure/architecture/networking/architecture/hub-spoke
+3. Azure Architecture Center Private Link hub-and-spoke guidance when private networking, DNS, or `/32` route behavior is materially relevant:
+   - https://learn.microsoft.com/en-us/azure/architecture/networking/guide/private-link-hub-spoke-network
+4. Azure MCP discovery guidance, only when the current client actually exposes useful Azure tools:
+   - https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/
+
+If Azure MCP is available, use it for read-focused evidence gathering, not to skip architecture reasoning. Repo-backed docs only support generic Azure MCP tooling plus `group` and `subscription` as clearly named namespaces for scope confirmation, so do not invent unsupported network namespace claims.

package/skills/azure/azure-network-topology-review/references/official-sources.md

@@ -0,0 +1,18 @@
+# Official Sources
+
+Load these only when needed:
+
+- [Network topology and connectivity](https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/network-topology-and-connectivity) — use for the landing-zone design-area framing and connectivity-management-group intent.
+- [Hub-spoke network topology in Azure](https://learn.microsoft.com/azure/architecture/networking/architecture/hub-spoke) — use for hub-spoke recommendations, non-transitive peering, spoke-to-spoke patterns, and gateway transit.
+- [Azure Private Link in a hub-and-spoke network](https://learn.microsoft.com/azure/architecture/networking/guide/private-link-hub-spoke-network) — use for hub-versus-spoke private endpoint placement, `/32` route propagation, DNS requirements, and on-premises implications.
+- [Private Link and DNS integration at scale](https://learn.microsoft.com/azure/cloud-adoption-framework/ready/azure-best-practices/private-link-and-dns-integration-at-scale) — use when DNS and private endpoint resolution are the real bottleneck.
+- [Integrate Azure services with virtual networks for network isolation](https://learn.microsoft.com/azure/virtual-network/vnet-integration-for-azure-services) — use when the user is confusing Private Link with other integration patterns.
+- [Azure landing zone design areas and conceptual architecture](https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-areas) — use when topology choices are coupled to broader landing-zone organization.
+- [Azure MCP Server tools inventory](https://learn.microsoft.com/azure/developer/azure-mcp-server/tools/) — use to verify `group`, `subscription`, `monitor`, or other documented namespaces before naming them.
+
+## Grounded insights worth carrying into the skill
+
+- Virtual network peering is non-transitive. Any answer that assumes transitivity is broken.
+- Private endpoints in spokes inject `/32` routes that propagate across peerings and VPN or ExpressRoute paths; if you ignore that, your topology advice is shallow.
+- Private endpoint success depends on deliberate DNS zone linkage and resolution path, not just resource placement.
+- In Virtual WAN, private endpoints belong in connected spoke virtual networks, not in the hub itself.

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

@@ -0,0 +1,129 @@
+# Workflow and Output Contract
+
+## Workflow
+
+1. Classify the topology before recommending anything.
+   - hub-spoke, flat peering mesh, Virtual WAN-adjacent, or unclear,
+   - single region or multi-region,
+   - single subscription or multi-subscription,
+   - Azure-only or hybrid with on-premises connectivity.
+2. Identify ownership and trust boundaries.
+   - which controls are platform-owned,
+   - which controls are workload-owned,
+   - which services are shared: DNS, firewall, Bastion, gateways, inspection, private endpoints, or monitoring,
+   - whether the current design accidentally centralizes too much or delegates too much.
+3. Map the current shared-services pattern.
+   - hub resources and their role,
+   - spoke purpose by environment or workload,
+   - whether spokes are isolated by subscription, resource group, environment, or team,
+   - whether cross-spoke communication is required, forbidden, or poorly defined.
+4. Challenge the connectivity model.
+   - hub-and-spoke is not automatically correct,
+   - flat peering becomes operational debt at scale,
+   - direct spoke-to-spoke connectivity changes blast radius,
+   - a central hub can become an outage choke point if routing, DNS, or firewall decisions are brittle.
+5. Review routing dependencies explicitly.
+   - peering is non-transitive,
+   - gateway-transit expectations must be deliberate,
+   - UDR ownership must be clear,
+   - forced tunneling through Azure Firewall or an NVA changes east-west and egress behavior,
+   - hybrid paths need route and failure-domain thinking, not just connectivity diagrams.
+6. Review DNS dependencies explicitly.
+   - shared DNS is often a hidden platform dependency,
+   - private endpoint resolution requires deliberate private DNS zone linkage,
+   - custom DNS and on-premises resolution paths can become the real failure point,
+   - if name resolution is undefined, the topology is incomplete even if peering exists.
+7. Review security and inspection boundaries.
+   - what the hub inspects,
+   - what stays workload-local,
+   - whether central egress or ingress policy is justified,
+   - whether NSGs, firewalls, NVAs, and private endpoints are being mixed without a clear control model,
+   - whether the design reduces or expands lateral-movement risk.
+8. Review shared versus workload-local private networking decisions.
+   - if many workloads need the same PaaS resource, central hub placement may simplify routing and control,
+   - if only specific workloads need access, workload-local placement may better preserve least privilege,
+   - call out `/32` route implications and DNS dependencies when private endpoints are involved.
+   - if Virtual WAN is in play, remember private endpoints belong in connected spokes, not in the hub itself.
+9. Surface bottlenecks and failure domains.
+   - single hub per region assumptions,
+   - shared firewall throughput or rule-management bottlenecks,
+   - DNS forwarder fragility,
+   - operational coupling between unrelated workloads,
+   - unclear rollback path for route-table or peering changes.
+10. Return concrete topology corrections.
+   - what should stay centralized,
+   - what should move to workload boundaries,
+   - what routing or DNS assumptions must be fixed first,
+   - what should be validated before any production change.
+
+## Output contract
+
+Return all of the following:
+
+- **Topology summary**: current or proposed model, regions, subscriptions, and connectivity pattern.
+- **Ownership model**: platform-owned controls versus workload-owned controls.
+- **Key risks**: routing, DNS, blast radius, operational bottlenecks, and security boundary weaknesses.
+- **Recommended topology adjustments**: specific changes to hub, spokes, peering, shared services, or private-network placement.
+- **Validation checks**: bounded checks for routes, DNS resolution, peering intent, and access paths.
+- **Open questions and assumptions**: what is still unknown and why it matters.
+- **Evidence used**: Microsoft Learn pages and any Azure MCP namespaces actually used.
+
+Use this response shape:
+
+```text
+Topology summary
+- Model: ...
+- Regions/subscriptions: ...
+- Shared services: ...
+
+Ownership model
+- Platform-owned: ...
+- Workload-owned: ...
+
+Key risks
+- Routing: ...
+- DNS: ...
+- Security / blast radius: ...
+- Operations: ...
+
+Recommended topology adjustments
+- ...
+
+Validation checks
+- Confirm peering and gateway-transit intent
+- Confirm effective routes or UDR ownership
+- Confirm DNS resolution path
+- Confirm security-control boundary
+
+Open questions and assumptions
+- ...
+```
+
+## Eval gate
+
+The skill output fails if it does not do all of the following:
+
+1. classify the actual topology and connectivity model,
+2. identify shared services and trust boundaries,
+3. separate platform-owned controls from workload-owned controls,
+4. call out routing dependencies, including peering non-transitivity where relevant,
+5. call out DNS dependencies instead of treating them as an implementation detail,
+6. address security and blast-radius implications,
+7. return concrete topology corrections rather than generic “use hub-spoke” advice,
+8. state assumptions and missing facts explicitly.
+
+Minimum scenarios this skill should handle:
+
+1. hub-spoke review for a multi-subscription landing zone,
+2. shared-services boundary critique across platform and workload teams,
+3. hybrid-routing or private-networking concern review where DNS and route dependencies matter.
+
+## Safety notes
+
+- Do not say a flat network is acceptable by default just because it is simpler.
+- Do not recommend centralizing every control in the hub; that often creates a high-blast-radius bottleneck.
+- Do not recommend workload-local exceptions without explaining the operational and security tradeoff.
+- Do not ignore DNS. A topology that “works on paper” but has no credible name-resolution path is not production-ready.
+- Do not treat route tables, gateway transit, or forced tunneling as minor implementation details; they are architecture decisions.
+- Do not blur platform-shared controls and workload-local controls. Ambiguous ownership becomes outage fuel.
+- Be explicit when advice is inference from incomplete topology evidence rather than confirmed current-state facts.