@raishin/vanguard-frontier-agentic 2.8.0 → 2.10.0

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

@@ -11,19 +11,19 @@
     "kiro",
     "other"
   ],
-  "summary": "Stress-test Azure migration cutovers across assessment quality, landing-zone readiness, dependency sequencing, permissions, rollback, and post-cutover operating ownership.",
+  "summary": "Stress-test Azure migration cutovers across discovery quality, assessment freshness, dependency sequencing, landing-zone readiness, 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"
+    "https://learn.microsoft.com/azure/migrate/migrate-services-overview?view=migrate",
+    "https://learn.microsoft.com/azure/migrate/concepts-migration-planning?view=migrate",
+    "https://learn.microsoft.com/azure/migrate/common-questions-discovery-dependency-analysis?view=migrate",
+    "https://learn.microsoft.com/azure/migrate/overview?view=migrate",
+    "https://learn.microsoft.com/azure/migrate/platform-landing-zone?view=migrate",
+    "https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/"
   ],
   "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",
+  "last_verified": "2026-06-05",
   "path": "skills/azure/azure-migrate-landing-zone-cutover",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.2"
 }

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

@@ -1,37 +1,22 @@
-# MCP and Evidence Path
+# Documentation and Evidence Path
 
-## Official Azure MCP Linkage
+## Preferred evidence order
 
-Use official Azure MCP capabilities only when they are actually exposed in the active runtime.
+1. Microsoft Learn documentation through the user's configured documentation MCP for documented Azure behavior.
+2. Sampled read-only Azure evidence, when safely available, for current configured-environment observations.
+3. Sanitized user-provided evidence.
+4. Clearly labeled inference.
 
-Relevant namespaces may include:
+## What each evidence type can prove
 
-- `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.
+- Microsoft Learn documentation can prove documented service behavior, supported concepts, limitations, and recommended patterns.
+- Sampled read-only evidence can prove the sampled configured state at the time observed.
+- Sanitized user evidence can prove only what the snippet shows.
+- None of these alone prove broad regional availability, future success, full account posture, or production readiness.
 
-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.
+## Safe usage pattern
 
-## 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.
+- State whether each claim is documentation-based, sampled-current-state, user-provided, or inference.
+- Use read-only queries before recommending changes.
+- Do not include sensitive internal identifiers, tenant identifiers, subscription identifiers, or secrets in committed docs or final findings.
+- If no sampled evidence is available, say the review is documentation-based and list the exact evidence still needed.

package/skills/azure/azure-migrate-landing-zone-cutover/references/migration-cutover-operations.md

@@ -0,0 +1,68 @@
+# Azure Migration Cutover Operations
+
+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
+
+- Calling an assessment green and assuming the cutover is ready.
+- Grouping servers by owner or convenience while ignoring runtime dependencies.
+- Using stale discovery, missing performance data, or incomplete inventory for final go/no-go.
+- Cutting over into an unfinished landing zone with weak DNS, routing, monitoring, backup, or identity.
+- Treating rollback as “restore from backup” without timing and data-loss proof.
+
+## Officially grounded service shape
+
+Microsoft Learn evidence says Azure Migrate supports decide, plan, and execute phases: discovery, business case, Azure readiness, right-sizing, cost estimation, dependency analysis, replication, migration, and modernization. Wave planning quality depends on complete discovery, accurate inventory, dependency analysis, application grouping, metadata enrichment, and assessments. Planning agents can interpret migration data but execution actions remain in Azure Migrate workflows.
+
+- Azure Migrate discovery collects inventory and performance data used for business cases and assessments.
+- Assessments provide readiness, right-sizing, cost estimates, and blockers, but need current data and correct assumptions.
+- Dependency analysis helps group workloads and avoid missed application dependencies.
+- Landing-zone readiness includes identity, network, governance, security, management, and operations foundations.
+- Cutover readiness adds wave sequencing, freeze windows, validation, rollback, and ownership.
+
+## Non-negotiable design rules
+
+- Require current discovery and assessment timestamps before go/no-go.
+- Require dependency evidence for every workload group in a wave.
+- Require target landing-zone controls before migration execution.
+- Require least-privilege migration permissions and named operators.
+- Require rollback checkpoints, data-loss boundary, and post-cutover validation owner.
+
+## Minimal safe implementation flow
+
+- Scope migration wave, workloads, source platform, target region/subscription, landing zone, and business owner.
+- Collect assessment, dependency, business case, replication/test migration, landing-zone, and runbook evidence.
+- Classify blockers by readiness, dependency, permissions, data, network, identity, monitoring, backup, and rollback risk.
+- Decide go, no-go, or conditional go with explicit cutover criteria.
+- Define post-cutover validation, monitoring, handover, and rollback deadline.
+
+## High-risk assumptions to kill
+
+- Assessment readiness is not cutover readiness; final cutover still needs current dependencies, replication state, freeze controls, validation, and fallback.
+- A landing zone that is missing DNS, routing, identity, monitoring, backup, or policy guardrails is not ready because migration tooling can move assets.
+- Near-zero downtime is not a slogan; replication lag, final synchronization, write freeze, traffic switch, and post-cutover validation must all be evidenced.
+- Rollback that loses unreplicated writes or misses DNS/load-balancer reversion is not a rollback plan.
+- Decommission is not safe until source-retention and business validation windows have expired.
+
+## Safe command/code verification targets
+
+- Verify discovery freshness, assessment assumptions, dependency grouping, replication health, and test migration evidence before go/no-go.
+- Confirm landing-zone controls: network connectivity, DNS, identity/RBAC, policy, monitoring, backup, and support ownership.
+- Check cutover runbook for write freeze, final sync, data-integrity checks, DNS/load-balancer switch, and 24-48 hour monitoring owner.
+- Verify fallback decision point, source-environment retention, accepted RPO/RTO, and rollback commands before traffic cutover.
+- Label any missing current Azure Migrate or landing-zone evidence as a blocker, not an assumption.
+
+## Safe verification targets
+
+- Discovery covers all in-scope workloads with current data.
+- Assessment assumptions, sizing, cost, and readiness blockers are reviewed.
+- Dependency groups align to application behavior and outage window.
+- Landing zone has connectivity, DNS, identity, policy, monitoring, backup, and support ownership.
+- Rollback has tested procedure, decision point, and accepted RPO/RTO impact.
+
+## When to push back
+
+- The plan lacks current Azure Migrate evidence.
+- Dependency mapping is guessed or incomplete.
+- Landing-zone controls are “coming later.”
+- Rollback cannot be executed within the business recovery window.

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

@@ -1,12 +1,26 @@
 # Official Sources
 
-## References
+Use these sources to ground the skill. Microsoft Learn documentation proves documented Azure behavior; it does not prove the user's tenant, subscription, RBAC, quota, migration project, network, telemetry, deployed resources, or production readiness.
 
-Load these only when needed:
+## Primary Microsoft Learn sources
 
-- [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)
+- https://learn.microsoft.com/azure/migrate/migrate-services-overview?view=migrate
+- https://learn.microsoft.com/azure/migrate/concepts-migration-planning?view=migrate
+- https://learn.microsoft.com/azure/migrate/common-questions-discovery-dependency-analysis?view=migrate
+- https://learn.microsoft.com/azure/migrate/overview?view=migrate
+- https://learn.microsoft.com/azure/migrate/platform-landing-zone?view=migrate
+- https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/
+
+## Grounding notes
+
+- Documentation-based claim: Microsoft Learn evidence says Azure Migrate supports decide, plan, and execute phases: discovery, business case, Azure readiness, right-sizing, cost estimation, dependency analysis, replication, migration, and modernization. Wave planning quality depends on complete discovery, accurate inventory, dependency analysis, application grouping, metadata enrichment, and assessments. Planning agents can interpret migration data but execution actions remain in Azure Migrate workflows.
+- Current-state claim: requires sampled read-only Azure evidence or sanitized user-provided evidence.
+- Inference: allowed only when labeled and tied to observed fields or documented behavior.
+- Do not include sensitive internal identifiers or secret material in findings.
+
+## Source use rules
+
+- Prefer Microsoft Learn documentation through the user's configured documentation MCP for current Azure service behavior.
+- Use sampled read-only Azure evidence only to validate current configured-environment observations.
+- If documentation and sampled evidence appear to conflict, report both and stop short of a production-ready verdict.
+- Re-check official sources before changing high-risk guidance, because cloud behavior and feature availability can change.

package/skills/azure/azure-migrate-landing-zone-cutover/references/safety-checklist.md

@@ -0,0 +1,28 @@
+# Safety Checklist
+
+## Evidence labels
+
+- `documentation-based`: grounded in Microsoft Learn or listed official documentation.
+- `sampled-current-state`: grounded in read-only Azure observations from the user's configured tools.
+- `user-provided`: grounded in sanitized snippets supplied by the user.
+- `inference`: reasoned from evidence but not directly proven.
+
+## Mutation boundary
+
+- Default to read-only review.
+- Do not perform create, update, delete, activate, approve, cancel, deactivate, migrate, cut over, route, peer, deploy, alert, suppress, or configuration changes unless the user explicitly asks and approval is clear.
+- Prefer preview, assessment, status, list, show, query, activity-log, dependency, and diagnostic evidence before any mutation.
+
+## Credential and data boundary
+
+- Never ask users to paste credentials, tokens, tenant IDs, subscription IDs, customer data, private keys, appliance secrets, migration inventory dumps, log payload secrets, or raw environment dumps.
+- Summarize sensitive evidence by field presence, control state, and risk; do not reproduce secret material.
+
+## Risk gates
+
+- Stop on ambiguous target, ambiguous principal, missing approval, missing owner, missing rollback, stale assessment, incomplete dependency mapping, unclear routing, or missing telemetry for high-impact assets.
+- Separate documented product behavior from sampled configured-environment evidence.
+
+## Asset-specific hard line
+
+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.

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

@@ -1,117 +1,30 @@
 # Workflow and Output Contract
 
-## Safe Workflow
+## Execution flow
 
-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.
+1. Scope the exact target, environment boundary, owner, requested decision, and evidence available.
+2. Load `official-sources.md`, then the component operations guide for service behavior and risk gates.
+3. Gather sampled read-only evidence only when available and safe.
+4. Compare observed posture against documented behavior, least-privilege expectations, and operational safety rules.
+5. Return a verdict with evidence level, blockers, safe next actions, and open questions.
 
-## Role-Specific Stress Checks
+## Required output
 
-- 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.
+- `verdict`: pass, warn, fail, or blocked.
+- `evidence_level`: documentation-based, sampled-current-state, user-provided, inference, or mixed.
+- `scope`: what was reviewed and what was not reviewed.
+- `blockers`: issues that prevent a safe or production-ready conclusion.
+- `findings`: severity-labeled risks with source labels.
+- `safe_next_actions`: reversible actions first; mutation only with explicit approval.
+- `open_questions`: missing facts that would change the verdict.
 
-## Output Template
+## Stress checks
 
-```markdown
-# Azure Migration Cutover Review: <scope>
+- What assumption would make this recommendation unsafe?
+- Which identity, migration, network, telemetry, route, or dispatch decision has the largest blast radius?
+- What evidence would disprove the claimed readiness?
+- Is the answer accidentally treating documentation as configured-environment proof?
 
-## Verdict
-- Status: READY / READY WITH RISKS / NOT READY
-- Biggest risk:
-- Evidence level: live evidence / documentation-based / sanitized evidence / inference
+## Response discipline
 
-## 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.
+Use Microsoft Learn documentation through the user's configured documentation MCP for documented Azure behavior. Use sampled read-only Azure evidence only for current configured-environment observations and label it as sampled evidence.

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

@@ -4,8 +4,8 @@ description: Use this skill for Azure network architecture review, hub-spoke cri
 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: networking
 ---
 
@@ -47,7 +47,7 @@ Route private-endpoint-first questions toward `azure-private-endpoint-adoption-p
 
 ## 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.
@@ -56,6 +56,8 @@ Route private-endpoint-first questions toward `azure-private-endpoint-adoption-p
 
 Load these only when needed:
 
+- [Azure Network Topology Operations](references/network-topology-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 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.

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

@@ -11,17 +11,19 @@
     "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.",
+  "summary": "Review Azure hub-spoke and related network topologies for routing, DNS, shared-services boundaries, security inspection, private connectivity, regional blast radius, and platform-versus-workload 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/"
+    "https://learn.microsoft.com/azure/architecture/networking/architecture/hub-spoke",
+    "https://learn.microsoft.com/azure/architecture/networking/architecture/hub-spoke-virtual-wan-architecture",
+    "https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/network-topology-and-connectivity",
+    "https://learn.microsoft.com/azure/architecture/networking/guide/private-link-hub-spoke-network",
+    "https://learn.microsoft.com/azure/dns/private-resolver-architecture",
+    "https://learn.microsoft.com/azure/virtual-network-manager/overview"
   ],
-  "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",
+  "security_notes": "Do not recommend flat or over-centralized network patterns by default. Always address routing, DNS, shared-service blast radius, inspection path, private connectivity, and platform-versus-workload control boundaries before calling a topology safe.",
+  "last_verified": "2026-06-05",
   "path": "skills/azure/azure-network-topology-review",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.2"
 }

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

@@ -1,16 +1,22 @@
-# MCP and Evidence Path
+# Documentation and Evidence Path
 
-## Evidence path
+## Preferred evidence order
 
-Prefer evidence in this order:
+1. Microsoft Learn documentation through the user's configured documentation MCP for documented Azure behavior.
+2. Sampled read-only Azure evidence, when safely available, for current configured-environment observations.
+3. Sanitized user-provided evidence.
+4. Clearly labeled inference.
 
-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/
+## What each evidence type can prove
 
-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.
+- Microsoft Learn documentation can prove documented service behavior, supported concepts, limitations, and recommended patterns.
+- Sampled read-only evidence can prove the sampled configured state at the time observed.
+- Sanitized user evidence can prove only what the snippet shows.
+- None of these alone prove broad regional availability, future success, full account posture, or production readiness.
+
+## Safe usage pattern
+
+- State whether each claim is documentation-based, sampled-current-state, user-provided, or inference.
+- Use read-only queries before recommending changes.
+- Do not include sensitive internal identifiers, tenant identifiers, subscription identifiers, or secrets in committed docs or final findings.
+- If no sampled evidence is available, say the review is documentation-based and list the exact evidence still needed.

package/skills/azure/azure-network-topology-review/references/network-topology-operations.md

@@ -0,0 +1,68 @@
+# Azure Network Topology Operations
+
+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
+
+- Drawing hubs and spokes without route tables, DNS, and ownership boundaries.
+- Assuming peering is transitive.
+- Centralizing every flow through a firewall without proving latency, SNAT, throughput, and failure-domain impact.
+- Ignoring private endpoint DNS when adopting Private Link.
+- Letting workload teams and platform teams both own the same control without decision authority.
+
+## Officially grounded service shape
+
+Microsoft Learn evidence says hub-spoke topology uses a hub for shared network services and cross-premises connectivity, while spokes isolate workloads and may live across subscriptions and environments. Peering is nontransitive, DNS is a common hub-spoke dependency, forced tunneling and UDRs can centralize inspection, and regional hubs reduce blast radius. Virtual WAN is a managed alternative with different routing, scale, and operational tradeoffs.
+
+- Hub virtual networks host shared services such as gateways, firewall, Bastion, DNS, and egress/ingress controls.
+- Spoke virtual networks isolate workloads and usually peer to one regional hub.
+- Spoke-to-spoke traffic needs explicit peering, direct connectivity, Virtual Network Manager, or routing through an NVA/firewall.
+- DNS resolution must align with Private Link, cross-premises routing, and firewall FQDN rules.
+- Virtual WAN can replace customer-managed hubs when managed transit and scale tradeoffs fit.
+
+## Non-negotiable design rules
+
+- Start with traffic flows, ownership, regions, and failure domains before choosing topology.
+- Prove routing symmetry and DNS behavior for every critical path.
+- Keep hubs regional unless cross-region routing is explicitly designed and monitored.
+- Use direct spoke connectivity only for justified same-workload or same-environment flows.
+- Separate platform-owned guardrails from workload-owned network controls.
+
+## Minimal safe implementation flow
+
+- Scope regions, subscriptions, hubs, spokes, shared services, cross-premises links, and private connectivity.
+- Map flows: north-south, east-west, management, DNS, private endpoint, ingress, egress, and break-glass.
+- Review peering, UDRs, gateway transit, firewall/NVA, DNS resolver, and monitoring design.
+- Rank risks by blast radius: DNS, routing loops, asymmetric paths, firewall bottleneck, and shared-service outage.
+- Return a target topology or remediation sequence with assumptions and verification evidence.
+
+## High-risk assumptions to kill
+
+- A hub-spoke diagram without route tables, DNS paths, security rules, and ownership is not an architecture review.
+- Virtual network peering is nontransitive; spoke-to-spoke paths need explicit design through peering, Virtual Network Manager, or routed inspection.
+- Central firewall inspection can create SNAT, throughput, latency, DNS, and blast-radius risks that must be measured or bounded.
+- Private endpoint adoption without private DNS design will fail in ways that look like application or firewall issues.
+- Cross-region hubs and shared services reduce duplication but can expand failure domains unless regional isolation is deliberate.
+
+## Safe command/code verification targets
+
+- Verify hub, spoke, region, subscription, route table, peering, gateway transit, DNS, firewall/NVA, and Private Link evidence for every critical flow.
+- Check whether direct spoke connectivity is justified by same-workload or same-environment needs.
+- Validate forced tunneling, forwarded traffic settings, SNAT capacity, firewall logs, and Network Watcher coverage.
+- Confirm private DNS zone links/resolvers for private endpoints and cross-premises consumers.
+- Require connection tests or sampled path evidence before approving production topology claims.
+
+## Safe verification targets
+
+- Every spoke has intended hub, route table, DNS path, and ownership.
+- Private endpoint DNS zones and resolvers are designed for all consuming networks.
+- Firewall/NVA throughput, SNAT, logging, and failover fit expected traffic.
+- Cross-premises and inter-spoke paths are explicit and tested.
+- Network Watcher, diagnostics, flow logs, and connection monitors cover critical paths.
+
+## When to push back
+
+- The user wants topology approval without route and DNS evidence.
+- A single shared hub creates unacceptable blast radius.
+- Private endpoint adoption ignores DNS resolution.
+- Forced tunneling will break PaaS, update, or control-plane dependencies.

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

@@ -1,18 +1,26 @@
 # Official Sources
 
-Load these only when needed:
+Use these sources to ground the skill. Microsoft Learn documentation proves documented Azure behavior; it does not prove the user's tenant, subscription, RBAC, quota, migration project, network, telemetry, deployed resources, or production readiness.
 
-- [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.
+## Primary Microsoft Learn sources
 
-## Grounded insights worth carrying into the skill
+- https://learn.microsoft.com/azure/architecture/networking/architecture/hub-spoke
+- https://learn.microsoft.com/azure/architecture/networking/architecture/hub-spoke-virtual-wan-architecture
+- https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/network-topology-and-connectivity
+- https://learn.microsoft.com/azure/architecture/networking/guide/private-link-hub-spoke-network
+- https://learn.microsoft.com/azure/dns/private-resolver-architecture
+- https://learn.microsoft.com/azure/virtual-network-manager/overview
 
-- 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.
+## Grounding notes
+
+- Documentation-based claim: Microsoft Learn evidence says hub-spoke topology uses a hub for shared network services and cross-premises connectivity, while spokes isolate workloads and may live across subscriptions and environments. Peering is nontransitive, DNS is a common hub-spoke dependency, forced tunneling and UDRs can centralize inspection, and regional hubs reduce blast radius. Virtual WAN is a managed alternative with different routing, scale, and operational tradeoffs.
+- Current-state claim: requires sampled read-only Azure evidence or sanitized user-provided evidence.
+- Inference: allowed only when labeled and tied to observed fields or documented behavior.
+- Do not include sensitive internal identifiers or secret material in findings.
+
+## Source use rules
+
+- Prefer Microsoft Learn documentation through the user's configured documentation MCP for current Azure service behavior.
+- Use sampled read-only Azure evidence only to validate current configured-environment observations.
+- If documentation and sampled evidence appear to conflict, report both and stop short of a production-ready verdict.
+- Re-check official sources before changing high-risk guidance, because cloud behavior and feature availability can change.

package/skills/azure/azure-network-topology-review/references/safety-checklist.md

@@ -0,0 +1,28 @@
+# Safety Checklist
+
+## Evidence labels
+
+- `documentation-based`: grounded in Microsoft Learn or listed official documentation.
+- `sampled-current-state`: grounded in read-only Azure observations from the user's configured tools.
+- `user-provided`: grounded in sanitized snippets supplied by the user.
+- `inference`: reasoned from evidence but not directly proven.
+
+## Mutation boundary
+
+- Default to read-only review.
+- Do not perform create, update, delete, activate, approve, cancel, deactivate, migrate, cut over, route, peer, deploy, alert, suppress, or configuration changes unless the user explicitly asks and approval is clear.
+- Prefer preview, assessment, status, list, show, query, activity-log, dependency, and diagnostic evidence before any mutation.
+
+## Credential and data boundary
+
+- Never ask users to paste credentials, tokens, tenant IDs, subscription IDs, customer data, private keys, appliance secrets, migration inventory dumps, log payload secrets, or raw environment dumps.
+- Summarize sensitive evidence by field presence, control state, and risk; do not reproduce secret material.
+
+## Risk gates
+
+- Stop on ambiguous target, ambiguous principal, missing approval, missing owner, missing rollback, stale assessment, incomplete dependency mapping, unclear routing, or missing telemetry for high-impact assets.
+- Separate documented product behavior from sampled configured-environment evidence.
+
+## Asset-specific hard line
+
+Do not recommend flat or over-centralized network patterns by default. Always address routing, DNS, shared-service blast radius, inspection path, private connectivity, and platform-versus-workload control boundaries before calling a topology safe.