@raishin/vanguard-frontier-agentic 2.8.0 → 2.10.0

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

package/skills/azure/azure-observability-investigator/references/mcp-and-evidence.md

@@ -1,37 +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 Monitor fundamentals and analysis guidance:
-   - https://learn.microsoft.com/en-us/azure/azure-monitor/overview
-   - https://learn.microsoft.com/en-us/azure/azure-monitor/best-practices-analysis
-2. Alerts and notification flow:
-   - 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
-3. Log Analytics and query posture:
-   - 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
-4. Application Insights and application telemetry:
-   - 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
-5. Visualization and reporting:
-   - 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
-6. Azure MCP discovery and monitor tools, when supported in the client:
-   - https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/
-   - https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/azure-monitor
-   - https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/application-insights
+## What each evidence type can prove
 
-Only mention Azure MCP namespaces when they are actually useful to the task. Based on the repo spec, relevant namespaces can include:
+- 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.
 
-- `monitor` for logs and metrics
-- `applicationinsights` for Application Insights resource discovery, not as a substitute for full Azure Monitor analysis
-- `kusto` only if Azure Data Explorer is actually part of the observability stack
-- `workbooks`
-- `grafana`
+## Safe usage pattern
 
-Use live MCP evidence to reduce guesswork. Do not pretend a namespace is available if the client does not expose it.
+- 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-observability-investigator/references/observability-investigation-operations.md

@@ -0,0 +1,68 @@
+# Azure Observability Investigation 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 the first correlated symptom the root cause.
+- Ignoring missing telemetry or sampling gaps.
+- Creating noisy alerts without action owner, severity, and suppression plan.
+- Querying the wrong workspace, time range, or resource scope.
+- Using dashboards as proof that alerting and incident response work.
+
+## Officially grounded service shape
+
+Microsoft Learn evidence says Azure Monitor collects, analyzes, and acts on logs, metrics, traces, and events across cloud and hybrid environments. Log Analytics workspaces store log and trace data queried with KQL, Azure Monitor workspaces store Prometheus/OpenTelemetry metrics, Application Insights provides application performance monitoring, and alerts/action groups support proactive response. Workbooks and Grafana visualize signals, but alerting should use Azure Monitor native alerts for Azure Monitor services.
+
+- Azure Monitor is the unified observability service for metrics, logs, traces, and events.
+- Metrics, logs, traces, activity logs, resource health, and service health answer different questions.
+- Log Analytics uses KQL and workspace scope; workspace design affects access, cost, retention, and query correctness.
+- Application Insights supports OpenTelemetry-based app monitoring, dependency maps, live metrics, failures, performance, and availability.
+- Alerts need action groups, routing, severity, suppression/processing rules, and ownership.
+
+## Non-negotiable design rules
+
+- Separate observation, hypothesis, evidence, and inference.
+- State time range, scope, query, signal source, and sampling caveat for every finding.
+- Prefer narrow diagnostic changes before broad alert rewrites.
+- Validate alert routing and action groups, not just alert rule existence.
+- Protect sensitive telemetry and do not paste secrets or customer data from logs.
+
+## Minimal safe implementation flow
+
+- Scope incident/resource/workload, time window, user impact, and available telemetry.
+- Inventory metrics, logs, traces, alerts, action groups, dashboards, diagnostic settings, and workspace coverage.
+- Run focused KQL/metric checks or request sampled evidence where tools are unavailable.
+- Correlate signals and classify root cause, contributing factor, symptom, or unknown.
+- Return findings, confidence, telemetry gaps, next diagnostics, and safe remediation.
+
+## High-risk assumptions to kill
+
+- The first correlated alert is not the root cause; root cause needs time-bounded, scoped evidence across metrics, logs, traces, events, and changes.
+- A dashboard is not proof that telemetry, alerting, action routing, or incident response works.
+- Missing telemetry is a finding. Do not invent certainty when diagnostic settings, workspace coverage, sampling, or retention are incomplete.
+- Log Analytics workspaces and Azure Monitor workspaces are different stores with different query models; querying the wrong store invalidates conclusions.
+- Alert changes can hide real incidents; suppression, thresholds, and action group changes require ownership and rollback.
+
+## Safe command/code verification targets
+
+- Record resource scope, workspace, time range, query text, signal source, sampling status, and data freshness for every finding.
+- Verify diagnostic settings, data collection rules, workspace retention, Application Insights/OpenTelemetry coverage, and alert/action group routes.
+- Separate observations, hypotheses, inferred causes, confirmed causes, and telemetry gaps in the final output.
+- Test alert routing or action groups with safe evidence before claiming response readiness.
+- Redact secrets, customer identifiers, and sensitive payloads from logs before storing or sharing evidence.
+
+## Safe verification targets
+
+- Diagnostic settings send required platform logs and metrics to the intended destination.
+- Workspace scope, retention, access model, and query performance fit the investigation.
+- Application Insights or OpenTelemetry captures requests, dependencies, exceptions, traces, availability, and sampling status where relevant.
+- Alerts have owner, severity, threshold rationale, action group route, and noise controls.
+- Workbooks/Grafana dashboards reflect authoritative signals and are not the only evidence.
+
+## When to push back
+
+- Telemetry is missing for the claimed root cause.
+- The time window or resource scope is ambiguous.
+- Alert changes would silence production incidents without owner approval.
+- Logs contain secrets or customer data that should be redacted before sharing.

package/skills/azure/azure-observability-investigator/references/official-sources.md

@@ -1,18 +1,30 @@
 # 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.
 
-- [Monitor Azure resources with Azure Monitor](https://learn.microsoft.com/azure/azure-monitor/platform/monitor-azure-resource) — use for the basic monitoring surface: Activity Log, Alerts, Metrics, Diagnostic settings, and Logs.
-- [Introduction to Application Insights - OpenTelemetry observability](https://learn.microsoft.com/azure/azure-monitor/app/app-insights-overview) — use for Application Insights investigation views, telemetry paths, and OpenTelemetry-oriented instrumentation expectations.
-- [Architecture strategies for designing a monitoring system](https://learn.microsoft.com/azure/well-architected/operational-excellence/observability) — use for the broader observability-system architecture, including Azure Monitor, Log Analytics, Network Watcher, and operational design.
-- [Architecture best practices for Log Analytics](https://learn.microsoft.com/azure/well-architected/service-guides/azure-log-analytics) — use for workspace design, reliability, retention, and operational-excellence tradeoffs.
-- [Architecture best practices for Application Insights](https://learn.microsoft.com/azure/well-architected/service-guides/application-insights) — use for environment separation, workspace dependency, and alerting or instrumentation quality.
-- [Azure Monitor alerts overview](https://learn.microsoft.com/azure/azure-monitor/alerts/alerts-overview) — use for alert types, routing, and action-group behavior.
-- [Azure MCP Server tools inventory](https://learn.microsoft.com/azure/developer/azure-mcp-server/tools/) — use to verify `monitor`, `applicationinsights`, `workbooks`, `grafana`, or other documented namespaces before naming them.
+## Primary Microsoft Learn sources
 
-## Grounded insights worth carrying into the skill
+- 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
 
-- Resource logs do not become queryable just because a service exists; Microsoft explicitly states you need diagnostic settings to route them.
-- Application Insights is part of Azure Monitor and depends on its underlying workspace and routing design; do not treat it as a standalone magic box.
-- Microsoft recommends one Application Insights resource per workload per environment to avoid mixed telemetry and investigation confusion.
-- Dashboards and workbooks are downstream views. If the underlying logs and metrics are missing or misrouted, the pretty dashboard proves nothing.
+## Grounding notes
+
+- Documentation-based claim: Microsoft Learn evidence says Azure Monitor collects, analyzes, and acts on logs, metrics, traces, and events across cloud and hybrid environments. Log Analytics workspaces store log and trace data queried with KQL, Azure Monitor workspaces store Prometheus/OpenTelemetry metrics, Application Insights provides application performance monitoring, and alerts/action groups support proactive response. Workbooks and Grafana visualize signals, but alerting should use Azure Monitor native alerts for Azure Monitor services.
+- 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-observability-investigator/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 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.

package/skills/azure/azure-observability-investigator/references/workflow-and-output.md

@@ -1,131 +1,30 @@
 # Workflow and Output Contract
 
-## Workflow
+## Execution flow
 
-1. Classify the problem before querying anything.
-   - metrics symptom,
-   - logs symptom,
-   - traces or dependency symptom,
-   - alerting symptom,
-   - configuration or coverage gap,
-   - mixed incident where multiple signal types must be correlated.
-2. Establish incident frame and uncertainty.
-   - what broke,
-   - when it started,
-   - whether the issue is current or historical,
-   - affected workload, region, environment, and blast radius,
-   - what telemetry is expected but may be missing.
-3. Gather the highest-value evidence first.
-   - current or recent alerts,
-   - resource and application metrics,
-   - relevant Log Analytics tables,
-   - Application Insights failures, dependencies, requests, exceptions, or availability signals,
-   - workbook or dashboard views only after validating the underlying data source.
-4. Separate evidence from correlation from inference.
-   - **Evidence**: direct signal observed in metrics, logs, traces, or alert configuration.
-   - **Correlation**: timing or co-occurrence that suggests a relationship.
-   - **Inference**: likely explanation that is not directly proven by the collected signals.
-5. Investigate alert quality, not just whether an alert fired.
-   - signal type and threshold quality,
-   - action-group wiring,
-   - alert-processing rules that suppress, route, or mutate behavior,
-   - duplicate or overlapping alerts,
-   - stale alerts tied to bad dimensions, wrong scope, or wrong evaluation windows,
-   - absence-of-data situations that may actually be ingestion or telemetry failure.
-6. Review telemetry coverage and workspace posture.
-   - whether the right resource or app emits telemetry at all,
-   - whether logs, metrics, and traces land in the expected workspace or resource,
-   - whether workspace sprawl is obscuring triage,
-   - whether retention, table design, or access mode blocks investigation,
-   - whether cross-resource or cross-workspace queries are required.
-   - whether diagnostic settings were ever enabled; without them, many platform logs will never be queryable.
-   - whether Application Insights is separated per workload and environment or mixed together into unusable noise.
-7. Use KQL deliberately.
-   - start narrow with timeframe, resource, operation, or failure boundary,
-   - verify table/schema assumptions before writing fancy joins,
-   - correlate requests, dependencies, exceptions, and platform logs only when the data actually exists,
-   - if no query can prove the claim, say so.
-8. Assess observability outputs.
-   - workbooks should reflect validated source data, not decorative charts,
-   - Grafana or workbook dashboards are downstream views, not primary evidence,
-   - recommend query, visualization, or ownership fixes only after validating source signals.
-9. End with operator actions.
-   - immediate triage next steps,
-   - alert tuning or suppression fixes,
-   - telemetry additions or routing corrections,
-   - ownership handoff if platform versus application responsibility is split,
-   - residual blind spots that prevent stronger conclusions.
+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.
 
-- **Issue summary**: what symptom is being investigated and its apparent blast radius.
-- **Signals reviewed**: metrics, logs, traces, alerts, workbooks, dashboards, and namespaces actually used.
-- **Evidence table**: direct evidence, correlated signals, and explicit inferences kept separate.
-- **Likely failure domain**: application, platform configuration, alerting design, workspace design, telemetry gap, or unresolved.
-- **Telemetry gaps**: what data is missing, delayed, misrouted, or too low-quality to support confident diagnosis.
-- **Recommended improvements**: concrete query, alert, action-group, alert-processing-rule, workbook, or workspace changes.
-- **Next diagnostic steps**: bounded follow-up actions in priority order.
-- **Assumptions and unknowns**: what remains unproven.
+## Stress checks
 
-Use a response shape like:
+- 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
-Issue summary
-- ...
+## Response discipline
 
-Signals reviewed
-- Metrics: ...
-- Logs: ...
-- Traces/Application Insights: ...
-- Alerts and routing: ...
-
-Evidence vs inference
-- Evidence: ...
-- Correlation: ...
-- Inference: ...
-
-Likely failure domain
-- ...
-
-Telemetry gaps
-- ...
-
-Recommended improvements
-- ...
-
-Next diagnostic steps
-- ...
-
-Assumptions and unknowns
-- ...
-```
-
-## Eval gate
-
-Treat the answer as failing if it does any of the following:
-
-- claims root cause without separating evidence from inference,
-- ignores ingestion delay or missing telemetry risk,
-- recommends alert changes without checking signal quality, scope, or routing,
-- treats workbook or dashboard visuals as proof without validating underlying data,
-- skips Log Analytics or Application Insights when they are central to the ask,
-- omits telemetry gaps and residual blind spots,
-- returns generic Azure Monitor advice with no operator next steps.
-
-Minimum scenarios this skill should handle:
-
-1. noisy or duplicate alert review,
-2. recent application or platform failure investigation,
-3. baseline telemetry-gap assessment for an under-instrumented workload.
-
-## Safety notes
-
-- Do not pretend logs prove what they do not prove.
-- Do not collapse correlation into causation.
-- Do not assume lack of logs means lack of failure; it may mean telemetry never arrived.
-- Do not recommend broad alert proliferation as a fix for poor signal design.
-- Do not expose secrets, customer payloads, tokens, or sensitive query results in the response.
-- Do not suggest mutating production alerting or workbook content without calling out rollback or verification steps.
-- Be explicit when a conclusion is based on partial telemetry, stale dashboards, or unverified workspace assumptions.
+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-platform-automation-devops/SKILL.md

@@ -4,8 +4,8 @@ description: Design and review Azure platform automation and DevOps delivery for
 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: delivery
 ---
 
@@ -26,7 +26,7 @@ Force clarity on:
 
 Default posture:
 
-- Prefer official Microsoft guidance and official Azure MCP capabilities when they reduce guesswork.
+- Prefer Microsoft Learn documentation through the user's configured documentation MCP, then sampled read-only Azure evidence when available, then sanitized user evidence.
 - Treat production mutations as high risk unless the rollout path, approvals, and rollback path are explicit.
 - Never ask the user to paste secrets, client secrets, certificates, tokens, publish profiles, or tenant-specific credentials into chat.
 - Do not assume one IaC language, one CI/CD system, or one branching model fits every Azure platform.
@@ -52,7 +52,7 @@ Do not use this skill 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.
@@ -61,7 +61,9 @@ Do not use this skill for:
 
 Load these only when needed:
 
-- [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing live Azure evidence, confirming Microsoft MCP capability, or switching to documentation mode.
+- [Azure Platform Automation Operations](references/platform-automation-operations.md) — use for current service behavior, common failure modes, hard design rules, verification targets, and push-back conditions.
+- [Safety checklist](references/safety-checklist.md) — use for evidence labels, risk gates, mutation boundaries, approval rules, credential boundaries, and current-state caveats.
+- [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing documentation-based evidence, sampled read-only evidence, or sanitized user evidence.
 - [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, applying stress checks, or formatting the final answer.
 - [Official sources](references/official-sources.md) — use when you need the detailed Microsoft documentation list or source notes.