@raishin/vanguard-frontier-agentic 2.7.1 → 2.9.0

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.
 

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

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

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

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

package/skills/azure/azure-platform-automation-devops/references/official-sources.md

@@ -1,16 +1,23 @@
-# Official Sources
+# Official sources
 
-## References
+Use this reference when grounding current Azure behavior for `azure-platform-automation-devops`.
 
-Load these only when needed:
+## Microsoft Learn sources
 
-- [Azure landing zone overview](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/) — use for platform-versus-application landing zone boundaries and Microsoft’s recommended Azure landing zone operating model.
-- [Platform landing zone implementation options](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/implementation-options) — use for choosing between IaC accelerator, Bicep, Terraform, and portal-based approaches.
-- [Azure landing zone Bicep guidance](https://learn.microsoft.com/en-us/azure/architecture/landing-zones/bicep/landing-zone-bicep) — use for Bicep accelerator structure, modular delivery, and deployment-stack-aware platform automation.
-- [Terraform landing zone guidance](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/terraform-landing-zone) — use when the user is standardizing on Terraform for Azure landing zone delivery.
-- [Deployment best practices for Azure App Service](https://learn.microsoft.com/en-us/azure/app-service/deploy-best-practices) — use for deployment-source/build/deploy separation, slot-safe release patterns, and production safety.
-- [App Service staging slots](https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots?view=azure-devops-2020) — use for swap-based rollout, warm-up, and rollback patterns.
-- [Azure MCP Server tools inventory](https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/) — use to verify which official Azure MCP capabilities actually exist before suggesting them.
-- [Azure Deploy tools for Azure MCP Server](https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/azure-deploy) — use when live deploy-oriented MCP support is relevant.
-- [Bicep MCP server](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/bicep-mcp-server) — use when schema-aware Bicep authoring support is relevant and to avoid inventing deploy behavior it does not provide.
-- [Bicep documentation](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/) — use for authoritative Bicep deployment, modules, scopes, and what-if references.
+- https://learn.microsoft.com/azure/azure-resource-manager/bicep/deploy-what-if
+- https://learn.microsoft.com/training/modules/test-bicep-code-using-github-actions/
+- https://learn.microsoft.com/training/modules/test-bicep-code-using-azure-pipelines/
+- https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/
+- https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/implementation-options
+- https://learn.microsoft.com/azure/architecture/landing-zones/bicep/landing-zone-bicep
+- https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/terraform-landing-zone
+
+## Current documentation refresh (2026-06-04)
+
+- Microsoft Learn documentation through the user's configured documentation MCP is the primary source for documented Azure behavior.
+- Documentation evidence is not live customer-state evidence. It does not prove the user's tenant, subscription, RBAC, quotas, deployed resources, incident posture, private connectivity, automation state, or production readiness.
+- Use sampled read-only Azure evidence only when the user has configured it and the task requires current-state confirmation. Label it as sampled evidence, not broad proof.
+
+## Grounding rule
+
+Docs explain service behavior. Current-state claims require sampled read-only evidence or sanitized user-provided evidence. If current state was not queried or shown, say so.

package/skills/azure/azure-platform-automation-devops/references/platform-automation-operations.md

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