@raishin/vanguard-frontier-agentic 2.7.1 → 2.9.0

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.

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

@@ -1,129 +1,30 @@
 # Workflow and Output Contract
 
-## Workflow
+## Execution flow
 
-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.
+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.
 
-## Output contract
+## Required output
 
-Return all of the following:
+- `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.
 
-- **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.
+## Stress checks
 
-Use this response shape:
+- 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?
 
-```text
-Topology summary
-- Model: ...
-- Regions/subscriptions: ...
-- Shared services: ...
+## Response discipline
 
-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.
+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-observability-investigator/SKILL.md

@@ -4,8 +4,8 @@ description: Use this skill for Azure Monitor, Log Analytics, Application Insigh
 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: observability
 ---
 
@@ -46,7 +46,7 @@ Do not use this skill as a substitute for:
 
 ## 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.
@@ -55,6 +55,8 @@ Do not use this skill as a substitute for:
 
 Load these only when needed:
 
+- [Azure Observability Investigation Operations](references/observability-investigation-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-observability-investigator/metadata.json

@@ -11,28 +11,23 @@
     "kiro",
     "other"
   ],
-  "summary": "Investigate Azure Monitor, Log Analytics, Application Insights, alerting, KQL triage, telemetry gaps, and observability workflows with explicit evidence-versus-inference handling.",
+  "summary": "Investigate Azure Monitor, Log Analytics, Application Insights, alerting, KQL triage, telemetry gaps, workbooks, Grafana, and incident hypotheses with explicit evidence-versus-inference handling.",
   "source_type": "original",
   "official_docs": [
-    "https://learn.microsoft.com/en-us/azure/azure-monitor/overview",
-    "https://learn.microsoft.com/en-us/azure/azure-monitor/best-practices-analysis",
-    "https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-overview",
-    "https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/action-groups",
-    "https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-processing-rules",
-    "https://learn.microsoft.com/en-us/azure/azure-monitor/logs/log-analytics-workspace-overview",
-    "https://learn.microsoft.com/en-us/azure/azure-monitor/logs/workspace-design",
-    "https://learn.microsoft.com/en-us/azure/azure-monitor/logs/get-started-queries",
-    "https://learn.microsoft.com/en-us/azure/azure-monitor/app/app-insights-overview",
-    "https://learn.microsoft.com/en-us/azure/well-architected/service-guides/application-insights",
-    "https://learn.microsoft.com/en-us/azure/azure-monitor/visualize/workbooks-overview",
-    "https://learn.microsoft.com/en-us/azure/azure-monitor/visualize/visualize-grafana-overview",
-    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/",
-    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/monitor",
-    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/azure-monitor"
+    "https://learn.microsoft.com/azure/azure-monitor/fundamentals/overview",
+    "https://learn.microsoft.com/azure/azure-monitor/fundamentals/best-practices-operation",
+    "https://learn.microsoft.com/azure/azure-monitor/alerts/alerts-overview",
+    "https://learn.microsoft.com/azure/azure-monitor/alerts/action-groups",
+    "https://learn.microsoft.com/azure/azure-monitor/alerts/alerts-processing-rules",
+    "https://learn.microsoft.com/azure/azure-monitor/logs/log-analytics-overview",
+    "https://learn.microsoft.com/azure/azure-monitor/logs/workspace-design",
+    "https://learn.microsoft.com/azure/azure-monitor/app/app-insights-overview",
+    "https://learn.microsoft.com/azure/azure-monitor/visualize/workbooks-overview",
+    "https://learn.microsoft.com/azure/managed-grafana/how-to-use-azure-monitor-alerts"
   ],
-  "security_notes": "Do not over-attribute symptoms as root cause, ignore missing telemetry, or recommend broad alerting changes without signal-quality review, routing checks, and bounded verification steps.",
-  "last_verified": "2026-04-27",
+  "security_notes": "Do not over-attribute symptoms as root cause, ignore missing telemetry, or recommend broad alerting changes without signal-quality review, routing checks, query scope, and bounded verification steps.",
+  "last_verified": "2026-06-05",
   "path": "skills/azure/azure-observability-investigator",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.2"
 }