@raishin/vanguard-frontier-agentic 2.8.0 → 2.10.0

package/skills/azure/azure-live-aks-rollout-guard/metadata.json

@@ -11,17 +11,22 @@
     "kiro",
     "other"
   ],
-  "summary": "Guard live AKS deployment rollouts with PDB audit, maxUnavailable/surge validation, rollout pause/undo gates, and post-rollout health verification.",
+  "summary": "Guard live AKS deployment and node-pool rollouts with PDB audit, maxUnavailable/surge validation, pause/undo gates, capacity checks, and post-rollout health verification.",
   "source_type": "original",
   "official_docs": [
-    "https://learn.microsoft.com/en-us/azure/aks/operator-best-practices-cluster-security",
-    "https://learn.microsoft.com/en-us/azure/aks/concepts-clusters-workloads",
-    "https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment",
-    "https://kubernetes.io/docs/tasks/run-application/configure-pdb/"
+    "https://learn.microsoft.com/azure/aks/upgrade-aks-node-pools-rolling",
+    "https://learn.microsoft.com/azure/aks/upgrade-options",
+    "https://learn.microsoft.com/azure/aks/upgrade-conceptual",
+    "https://learn.microsoft.com/azure/aks/blue-green-node-pool-upgrade",
+    "https://learn.microsoft.com/azure/architecture/operator-guides/aks/aks-upgrade-practices",
+    "https://learn.microsoft.com/azure/aks/concepts-clusters-workloads",
+    "https://learn.microsoft.com/azure/aks/operator-best-practices-cluster-security",
+    "https://kubernetes.io/docs/tasks/run-application/configure-pdb/",
+    "https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment"
   ],
-  "security_notes": "Never advance an AKS rollout without PDB audit and replica health check. kubectl rollout undo is safe but must be confirmed before execution to avoid double-rollback churn.",
-  "last_verified": "2026-04-30",
+  "security_notes": "Never advance an AKS rollout without target, principal, approval, PDB audit, replica health, capacity, and rollback evidence. Treat undo, drain, cordon, scale, and node-pool upgrade operations as live mutations requiring explicit approval.",
+  "last_verified": "2026-06-05",
   "path": "skills/azure/azure-live-aks-rollout-guard",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.4"
 }

package/skills/azure/azure-live-aks-rollout-guard/references/aks-rollout-operations.md

@@ -0,0 +1,68 @@
+# Azure AKS Rollout 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 a rollout safe because kubectl apply succeeded.
+- Ignoring PDBs, replicas, readiness probes, and maxUnavailable until a drain is already blocked.
+- Using maxUnavailable to avoid quota issues without admitting the disruption tradeoff.
+- Starting a node-pool upgrade without IP, compute quota, and rollback-window evidence.
+- Running rollback commands twice because no one tracked current rollout state.
+
+## Officially grounded service shape
+
+Microsoft Learn evidence says AKS rolling upgrades add surge nodes, cordon and drain old nodes, optionally wait for soak time, reimage nodes, repeat, and remove surge nodes. Production node pools are recommended to use max surge rather than disruptive in-place unavailability where possible. Max unavailable can disrupt workloads and increase failures from unsatisfied PodDisruptionBudgets. Blue-green node-pool upgrade includes a final soak window during which rollback is available before old nodes are removed.
+
+- Deployment rollouts and AKS node-pool upgrades are separate but coupled failure domains.
+- AKS node rolling upgrades use surge, cordon, drain, optional soak, reimage, and cleanup phases.
+- PDBs can protect availability but can also block drains when configured too tightly for replicas and topology.
+- Blue-green upgrade provides a validation and rollback window, but rollback disappears after the final commit/removal point.
+- Read-only evidence can prove current health snapshots, not future rollout success.
+
+## Non-negotiable design rules
+
+- Stop if target subscription/resource group/cluster/namespace/workload/principal or approval is ambiguous.
+- Require preflight evidence for pods, deployments, events, PDBs, HPA, nodes, quotas, and recent errors before mutation.
+- Prefer pause/status/describe/dry-run/plan checks before apply, restart, drain, upgrade, or undo.
+- Define rollback trigger, command, owner, and verification before execution.
+- Sanitize outputs; never print tokens, kubeconfig contents, environment values, or customer data.
+
+## Minimal safe implementation flow
+
+- Confirm target and read-only context: cluster, namespace, workload, node pool, current principal, and requested operation.
+- Collect rollout status, deployment spec, PDBs, replicas, readiness, events, node health, capacity, and monitoring signals.
+- Compare rollout strategy, maxUnavailable/maxSurge, PDB, and drain/soak settings against documented AKS and Kubernetes behavior.
+- Gate mutation on explicit approval, rollback plan, and health criteria.
+- After action, verify deployment availability, events, logs/metrics summary, and rollback posture.
+
+## High-risk assumptions to kill
+
+- `kubectl apply` success is not rollout success; availability, events, probes, PDBs, HPA behavior, and monitored health must be checked.
+- A PDB can protect or deadlock a rollout; the math must fit replica count, maxUnavailable, topology, and node drain behavior.
+- Max surge consumes compute and IP quota, while max unavailable trades capacity for disruption; neither setting is safe without explicit evidence.
+- Force or bypass paths that ignore PDBs can create complete service unavailability and need explicit emergency justification.
+- Rollback is not real if revision history, previous ReplicaSet, blue-green soak window, or node-pool recovery path is unknown.
+
+## Safe command/code verification targets
+
+- Inspect deployment manifests for replicas, strategy, maxSurge, maxUnavailable, probes, termination grace, resource requests, and topology spread.
+- Review PDB and HPA manifests together to prove eviction allowance cannot deadlock under expected rollout or drain conditions.
+- Check AKS node-pool settings for max surge, max unavailable, drain timeout, soak duration, version skew, node image, zones, quotas, and subnet IP headroom.
+- Verify preflight commands use status/describe/events/dry-run style evidence before mutation and avoid printing kubeconfig, tokens, or environment values.
+- Confirm rollback playbook names the exact pause, undo, history, node-pool rollback/blue-green decision point, and post-rollback health checks.
+
+## Safe verification targets
+
+- Deployment has enough replicas and PDB allowance for expected disruption.
+- Node pools have surge/capacity/IP quota or an explicit accepted maxUnavailable tradeoff.
+- Readiness/liveness/startup probes and termination grace match rollout and drain behavior.
+- Rollback command and validation window are known before mutation.
+- Post-rollout status shows desired replicas available, no new critical events, and monitored health criteria met.
+
+## When to push back
+
+- The user asks to mutate a live cluster without explicit approval.
+- PDBs or replicas make disruption mathematically unavoidable.
+- Quota/capacity evidence is missing for surge-based upgrades.
+- Rollback cannot be explained before starting the rollout.

package/skills/azure/azure-live-aks-rollout-guard/references/mcp-and-evidence.md

@@ -0,0 +1,26 @@
+# Documentation and Evidence Path
+
+## Preferred evidence order
+
+1. Microsoft Learn documentation through the user's configured documentation MCP for documented Azure behavior.
+2. Sampled read-only Azure or Kubernetes evidence, when safely available, for current configured-environment observations.
+3. Sanitized user-provided evidence.
+4. Clearly labeled inference.
+
+## What each evidence type can prove
+
+- Microsoft Learn documentation can prove documented service behavior, supported concepts, 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.
+
+## Asset guidance
+
+Use Microsoft Learn documentation through the user's configured documentation MCP for documented AKS behavior. Use sampled read-only Azure or Kubernetes evidence only for current cluster observations and label it as sampled evidence.

package/skills/azure/azure-live-aks-rollout-guard/references/official-sources.md

@@ -1,19 +1,37 @@
-# Official Sources: Azure Live AKS Rollout Guard
+# Official Sources
 
-## Azure AKS
+Use these sources to ground the skill. Microsoft Learn documentation proves documented Azure behavior; it does not prove the user's tenant, RBAC, quotas, deployed resources, or production readiness.
 
-- https://learn.microsoft.com/en-us/azure/aks/operator-best-practices-cluster-security
-- https://learn.microsoft.com/en-us/azure/aks/concepts-clusters-workloads
-- https://learn.microsoft.com/en-us/azure/aks/manage-azure-rbac
-- https://learn.microsoft.com/en-us/azure/aks/use-azure-ad
+## Primary Microsoft Learn sources
 
-## Kubernetes rolling updates and rollback
-
-- https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment
-- https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-back-a-deployment
+- https://learn.microsoft.com/azure/aks/upgrade-aks-node-pools-rolling
+- https://learn.microsoft.com/azure/aks/upgrade-options
+- https://learn.microsoft.com/azure/aks/upgrade-conceptual
+- https://learn.microsoft.com/azure/aks/blue-green-node-pool-upgrade
+- https://learn.microsoft.com/azure/architecture/operator-guides/aks/aks-upgrade-practices
+- https://learn.microsoft.com/azure/aks/concepts-clusters-workloads
+- https://learn.microsoft.com/azure/aks/operator-best-practices-cluster-security
 - https://kubernetes.io/docs/tasks/run-application/configure-pdb/
+- https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment
+
+## Grounding notes
+
+- Documentation-based claim: Microsoft Learn evidence says AKS rolling upgrades add surge nodes, cordon and drain old nodes, optionally wait for soak time, reimage nodes, repeat, and remove surge nodes. Production node pools are recommended to use max surge rather than disruptive in-place unavailability where possible. Max unavailable can disrupt workloads and increase failures from unsatisfied PodDisruptionBudgets. Blue-green node-pool upgrade includes a final soak window during which rollback is available before old nodes are removed.
+- 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.
+
+## Current Microsoft Learn deltas checked on 2026-06-05
 
-## Source-grounding rule
+- Production AKS upgrade guidance uses surge capacity as the normal safety path, but more surge is not automatically safer when quota, subnet IPs, or workload capacity are constrained.
+- MaxUnavailable behavior is constrained by node-pool type and can deadlock or disrupt workloads when PodDisruptionBudgets, drain timeout, or capacity are wrong.
+- Force upgrade bypasses normal disruption protections and must be treated as a high-risk live operation, not a routine rollout fix.
+- Rollback is not a generic one-command undo; capture current state and rollback limits before any node-pool or workload rollout mutation.
 
-Use official Microsoft Learn and Kubernetes.io documentation as source of truth.
-Do not override official guidance with secondary examples or training data assumptions.

package/skills/azure/azure-live-aks-rollout-guard/references/permission-model.md

@@ -16,13 +16,15 @@
     "Microsoft.ContainerService/managedClusters/agentPools/write"
   ],
   "AssignableScopes": [
-    "/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<TARGET_RG>/providers/Microsoft.ContainerService/managedClusters/<CLUSTER_NAME>"
+    "<cluster-resource-scope>"
   ]
 }
 ```
 
 `listClusterUserCredential` grants a user-level kubeconfig. What the user can do inside
 the cluster is governed by AKS-integrated Entra ID RBAC, not this control-plane role.
+Use the exact AKS cluster resource scope from approved change records; do not paste raw
+subscription identifiers into chat.
 
 ## Kubernetes RBAC (data plane — in-cluster namespace scope)
 
@@ -33,7 +35,7 @@ apiVersion: rbac.authorization.k8s.io/v1
 kind: Role
 metadata:
   name: rollout-guard
-  namespace: <TARGET_NAMESPACE>
+  namespace: <namespace-name>
 rules:
 - apiGroups: ["apps"]
   resources: ["deployments", "replicasets"]

package/skills/azure/azure-live-aks-rollout-guard/references/preflight-commands.md

@@ -1,34 +1,40 @@
 # Preflight Commands: Azure Live AKS Rollout Guard
 
+Use shell variables for examples instead of raw identifiers. Populate them from an approved change record or already configured shell context; never paste tenant, subscription, resource, or secret values into chat.
+
+## Evidence-variable convention
+
+Variables such as $AZURE_RESOURCE_GROUP_NAME, $APP_SERVICE_APP_NAME, or $KEY_VAULT_NAME are local operator placeholders. Do not commit real values, and redact them from shared evidence unless the change record explicitly allows disclosure.
+
 Run these commands before any AKS rollout mutation. Paste sanitized output as evidence.
 
 ## 1. Confirm identity and cluster target
 
 ```bash
-az account show --query "{subscription:id, name:name, user:user.name}"
-az aks show -g <RESOURCE_GROUP> -n <CLUSTER_NAME> \
+az account show --query "{subscriptionName:name, user:user.name}"
+az aks show -g $AZURE_RESOURCE_GROUP_NAME -n $AKS_CLUSTER_NAME \
   --query "{provisioningState:provisioningState, kubernetesVersion:kubernetesVersion, fqdn:fqdn}"
 ```
 
 ## 2. Fetch user-level kubeconfig
 
 ```bash
-az aks get-credentials -g <RESOURCE_GROUP> -n <CLUSTER_NAME> --overwrite-existing
+az aks get-credentials -g $AZURE_RESOURCE_GROUP_NAME -n $AKS_CLUSTER_NAME --overwrite-existing
 kubectl config current-context
 ```
 
 ## 3. Audit PodDisruptionBudgets in target namespace
 
 ```bash
-kubectl get pdb -n <NAMESPACE> -o wide
+kubectl get pdb -n $KUBERNETES_NAMESPACE -o wide
 # minAvailable or maxUnavailable must leave at least one pod available during rollout
 ```
 
 ## 4. Check current deployment rollout status
 
 ```bash
-kubectl rollout status deployment/<DEPLOYMENT_NAME> -n <NAMESPACE>
-kubectl get deployment <DEPLOYMENT_NAME> -n <NAMESPACE> -o jsonpath='{.spec.strategy}'
+kubectl rollout status deployment/$KUBERNETES_DEPLOYMENT_NAME -n $KUBERNETES_NAMESPACE
+kubectl get deployment $KUBERNETES_DEPLOYMENT_NAME -n $KUBERNETES_NAMESPACE -o jsonpath='{.spec.strategy}'
 ```
 
 ## 5. Verify node readiness and resource headroom
@@ -36,13 +42,13 @@ kubectl get deployment <DEPLOYMENT_NAME> -n <NAMESPACE> -o jsonpath='{.spec.stra
 ```bash
 kubectl get nodes -o wide
 kubectl top nodes
-kubectl get pods -n <NAMESPACE> -o wide
+kubectl get pods -n $KUBERNETES_NAMESPACE -o wide
 ```
 
 ## 6. Confirm maxSurge / maxUnavailable strategy
 
 ```bash
-kubectl get deployment <DEPLOYMENT_NAME> -n <NAMESPACE> \
+kubectl get deployment $KUBERNETES_DEPLOYMENT_NAME -n $KUBERNETES_NAMESPACE \
   -o jsonpath='{.spec.strategy.rollingUpdate}'
 # maxUnavailable=0 is safest for production; maxSurge=1 is a conservative default
 ```
@@ -50,6 +56,6 @@ kubectl get deployment <DEPLOYMENT_NAME> -n <NAMESPACE> \
 ## 7. Check HorizontalPodAutoscaler (if present)
 
 ```bash
-kubectl get hpa -n <NAMESPACE>
+kubectl get hpa -n $KUBERNETES_NAMESPACE
 # HPA minReplicas must exceed PDB minAvailable or the rollout will deadlock
 ```

package/skills/azure/azure-live-aks-rollout-guard/references/rollback-playbook.md

@@ -4,24 +4,24 @@
 
 ```bash
 # Pause the rollout first to stop further progress
-kubectl rollout pause deployment/<DEPLOYMENT_NAME> -n <NAMESPACE>
+kubectl rollout pause deployment/<deployment-name> -n <namespace-name>
 
 # Check rollout history to identify the target revision
-kubectl rollout history deployment/<DEPLOYMENT_NAME> -n <NAMESPACE>
+kubectl rollout history deployment/<deployment-name> -n <namespace-name>
 
 # Undo to the immediately prior revision
-kubectl rollout undo deployment/<DEPLOYMENT_NAME> -n <NAMESPACE>
+kubectl rollout undo deployment/<deployment-name> -n <namespace-name>
 
 # Or undo to a specific revision
-kubectl rollout undo deployment/<DEPLOYMENT_NAME> -n <NAMESPACE> --to-revision=<N>
+kubectl rollout undo deployment/<deployment-name> -n <namespace-name> --to-revision=<N>
 ```
 
 ## Verify rollback success
 
 ```bash
-kubectl rollout status deployment/<DEPLOYMENT_NAME> -n <NAMESPACE>
-kubectl get pods -n <NAMESPACE> -o wide
-kubectl describe deployment <DEPLOYMENT_NAME> -n <NAMESPACE> | grep -A 5 "Conditions:"
+kubectl rollout status deployment/<deployment-name> -n <namespace-name>
+kubectl get pods -n <namespace-name> -o wide
+kubectl describe deployment <deployment-name> -n <namespace-name> | grep -A 5 "Conditions:"
 ```
 
 ## Rollback limitations
@@ -33,6 +33,6 @@ kubectl describe deployment <DEPLOYMENT_NAME> -n <NAMESPACE> | grep -A 5 "Condit
 
 ## Escalation path
 
-1. If rollback leaves pods in `CrashLoopBackOff`: check logs with `kubectl logs <POD> -n <NAMESPACE> --previous`
-2. If node is under memory pressure: drain the node with `kubectl drain <NODE> --ignore-daemonsets`
+1. If rollback leaves pods in `CrashLoopBackOff`: check logs with `kubectl logs <pod-name> -n <namespace-name> --previous`
+2. If node is under memory pressure: drain the node with `kubectl drain <node-name> --ignore-daemonsets`
 3. If the cluster is unresponsive: escalate to AKS support via Azure portal → cluster → Support + troubleshooting

package/skills/azure/azure-live-aks-rollout-guard/references/safety-checklist.md

@@ -0,0 +1,29 @@
+# Safety Checklist
+
+## Evidence labels
+
+- `documentation-based`: grounded in Microsoft Learn or official Kubernetes documentation where listed.
+- `sampled-current-state`: grounded in read-only Azure or Kubernetes 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, rotate, purge, recover, apply, restart, drain, cordon, scale, rollout, role-assignment, policy-assignment, or network changes unless the user explicitly asks and approval is clear.
+- Prefer preview, dry-run, status, describe, what-if, list, show, and policy evaluation evidence before any mutation.
+
+## Credential and data boundary
+
+- Never ask users to paste credentials, tokens, tenant IDs, subscription IDs, customer data, private keys, kubeconfig contents, CA requester credentials, secret values, or connection strings.
+- 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 rollback, or missing owner for high-impact assets.
+- Treat broad permissions, permanent privileged access, public exposure, purge authority, destructive operations, and live rollout changes as high-risk.
+- Separate documented product behavior from sampled configured-environment evidence.
+
+## Asset-specific hard line
+
+Never advance an AKS rollout without target, principal, approval, PDB audit, replica health, capacity, and rollback evidence. Treat undo, drain, cordon, scale, and node-pool upgrade operations as live mutations requiring explicit approval.

package/skills/azure/azure-live-aks-rollout-guard/references/workflow-and-output.md

@@ -0,0 +1,30 @@
+# Workflow and Output Contract
+
+## Execution flow
+
+1. Scope the exact asset, environment boundary, owner, and requested decision.
+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.
+
+## Required output
+
+- `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.
+
+## Stress checks
+
+- What assumption would make this recommendation unsafe?
+- Which role, policy, network, lifecycle, or rollout action has the largest blast radius?
+- What evidence would disprove the claimed readiness?
+- Is the answer accidentally treating documentation as tenant-specific proof?
+
+## Response discipline
+
+Use Microsoft Learn documentation through the user's configured documentation MCP for documented AKS behavior. Use sampled read-only Azure or Kubernetes evidence only for current cluster observations and label it as sampled evidence.

package/skills/azure/azure-live-app-service-slot-swap-guard/SKILL.md

@@ -4,8 +4,8 @@ description: Guard live App Service slot swaps with sticky-settings audit, warmu
 allowed-tools: Read Grep Glob WebFetch
 metadata:
   author: "github: Raishin"
-  version: "0.1.0"
-  updated: "2026-05-05"
+  version: 0.1.6
+  updated: "2026-06-05"
   category: delivery
 ---
 
@@ -25,7 +25,7 @@ Use this skill when:
 
 ## Lean operating rules
 
-- Prefer Azure CLI (`az`) official documentation when available; fall back to Microsoft Learn docs and sanitized user evidence.
+- Prefer Microsoft Learn documentation through the user's configured documentation MCP; use sampled read-only Azure evidence when available, then sanitized user evidence.
 - Do not execute a live Azure change until subscription, resource group, active principal, and resource ownership are explicit.
 - Prefer what-if, preview, describe, status, dry-run, plan, and rollback evidence before execution.
 - If the request skips preview or rollback design, push back.
@@ -36,9 +36,13 @@ Use this skill when:
 
 Load these only when needed:
 
+- [Azure App Service Slot Swap Operations](references/slot-swap-operations.md) — use for current service behavior, common failure modes, hard design rules, verification targets, and push-back conditions.
 - [Preflight commands](references/preflight-commands.md) — CLI commands to run before any mutation.
 - [Rollback playbook](references/rollback-playbook.md) — concrete rollback steps for this service.
 - [Permission model](references/permission-model.md) — RBAC role definitions and PIM guidance.
+- [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing documentation-based evidence, sampled read-only evidence, or sanitized user evidence.
+- [Safety checklist](references/safety-checklist.md) — use for evidence labels, slot-swap gates, sticky settings, warm-up status, production target confirmation, and rollback limits.
+- [Workflow and output contract](references/workflow-and-output.md) — execution flow and final response contract.
 - [Official sources](references/official-sources.md) — authoritative Azure documentation links.
 
 ## Response minimum

package/skills/azure/azure-live-app-service-slot-swap-guard/metadata.json

@@ -11,16 +11,18 @@
     "kiro",
     "other"
   ],
-  "summary": "Guard live App Service slot swaps with sticky-settings audit, warmup probe verification, swap-with-preview staging, and instant rollback posture.",
+  "summary": "Guard live App Service slot swaps with sticky-settings audit, warmup probe verification, swap-with-preview staging, activity-log checks, and immediate rollback posture.",
   "source_type": "original",
   "official_docs": [
-    "https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots",
-    "https://learn.microsoft.com/en-us/azure/app-service/deploy-best-practices",
-    "https://learn.microsoft.com/en-us/azure/app-service/configure-common"
+    "https://learn.microsoft.com/azure/app-service/deploy-staging-slots",
+    "https://learn.microsoft.com/azure/app-service/reference-app-settings#deployment-slots",
+    "https://learn.microsoft.com/azure/app-service/deploy-best-practices",
+    "https://learn.microsoft.com/azure/app-service/configure-common",
+    "https://learn.microsoft.com/azure/app-service/overview-local-cache"
   ],
-  "security_notes": "Never perform a production slot swap without sticky-settings diff audit and warmup health confirmation. A bad swap with no rollback plan can take a production app offline instantly.",
-  "last_verified": "2026-04-30",
+  "security_notes": "Never perform a production slot swap without target-slot confirmation, sticky-settings diff, warm-up evidence, authentication limitation check, activity-log monitoring path, and immediate rollback plan.",
+  "last_verified": "2026-06-05",
   "path": "skills/azure/azure-live-app-service-slot-swap-guard",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.6"
 }

package/skills/azure/azure-live-app-service-slot-swap-guard/references/mcp-and-evidence.md

@@ -0,0 +1,26 @@
+# Documentation and Evidence Path
+
+## Preferred evidence 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.
+
+## What each evidence type can prove
+
+- 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.
+
+## Live-operation rule
+
+For live operations, documentation is never enough. Require target confirmation, current-state evidence, explicit approval, rollback constraints, and post-action verification.

package/skills/azure/azure-live-app-service-slot-swap-guard/references/official-sources.md

@@ -1,12 +1,34 @@
-# Official Sources: Azure Live App Service Slot Swap Guard
+# Official Sources
 
-## App Service staging slots
+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, deployed resources, current cost, vault state, app health, or production readiness.
 
-- https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots
-- https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots#swap-operation-steps
-- https://learn.microsoft.com/en-us/azure/app-service/configure-common
+## Primary Microsoft Learn sources
 
-## Source-grounding rule
+- https://learn.microsoft.com/azure/app-service/deploy-staging-slots
+- https://learn.microsoft.com/azure/app-service/reference-app-settings#deployment-slots
+- https://learn.microsoft.com/azure/app-service/deploy-best-practices
+- https://learn.microsoft.com/azure/app-service/configure-common
+- https://learn.microsoft.com/azure/app-service/overview-local-cache
+
+## Grounding notes
+
+- Documentation-based claim: Microsoft Learn evidence says App Service deployment slots are live apps and swaps apply target-slot settings to source instances, restart and warm source instances, then switch routing. Swap with preview pauses after target settings are applied so the operator can validate before completing or resetting. Sticky slot settings and warm-up app settings decide whether secrets, connection strings, networking-sensitive settings, and health paths behave safely during swap.
+- Current-state claim: requires sampled read-only Azure evidence or sanitized user-provided evidence.
+- Live-operation claim: requires target, principal, approval, preflight evidence, rollback constraints, and post-action verification.
+- 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.
+
+## Current Microsoft Learn deltas checked on 2026-06-05
+
+- Deployment slots require a supported App Service plan tier; do not promise slot workflows for unsupported plans.
+- For staging-to-production swaps, production should be the target slot and preview/reset/swap state must be verified before completion.
+- Swap with preview is not universally available; authentication differences between slots can block that path.
+- Managed identities, VNet integration, custom domains, TLS settings, and IP restrictions are not ordinary swapped app content; treat them as environment-bound controls.
 
-Use official Microsoft Learn documentation as the source of truth for App Service behavior.
-Slot-sticky setting behavior must be verified from official docs before every swap operation.

package/skills/azure/azure-live-app-service-slot-swap-guard/references/permission-model.md

@@ -1,5 +1,9 @@
 # Permission Model: Azure Live App Service Slot Swap Guard
 
+## Evidence-variable convention
+
+Shell variables in examples are local operator placeholders from an approved change record or already configured shell context. Do not commit real values, and redact them from shared evidence unless disclosure is explicitly approved.
+
 ## Custom role — slot swap only, no config writes
 
 ```json
@@ -22,7 +26,7 @@
     "Microsoft.Web/sites/slots/delete"
   ],
   "AssignableScopes": [
-    "/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<TARGET_RG>/providers/Microsoft.Web/sites/<APP_NAME>"
+    "$APPROVED_APP_SERVICE_SCOPE"
   ]
 }
 ```
@@ -38,3 +42,5 @@ Use only when custom role scope is impractical — and scope it to the single Ap
 - `Microsoft.Web/sites/config/write` without a change-management gate
 - `Microsoft.Web/sites/slots/delete` — slot deletion is irreversible and must not be in the swap role
 - Subscription-level `Website Contributor` for routine swap operations
+
+Use exact resource scopes from approved change records; do not paste raw subscription identifiers into chat.

package/skills/azure/azure-live-app-service-slot-swap-guard/references/preflight-commands.md

@@ -1,29 +1,35 @@
 # Preflight Commands: Azure Live App Service Slot Swap Guard
 
+Use shell variables for examples instead of raw identifiers. Populate them from an approved change record or already configured shell context; never paste tenant, subscription, resource, or secret values into chat.
+
+## Evidence-variable convention
+
+Variables such as $AZURE_RESOURCE_GROUP_NAME, $APP_SERVICE_APP_NAME, or $KEY_VAULT_NAME are local operator placeholders. Do not commit real values, and redact them from shared evidence unless the change record explicitly allows disclosure.
+
 Run these before initiating a slot swap. Paste sanitized output as evidence.
 
 ## 1. Confirm identity and App Service target
 
 ```bash
 az account show --query "{subscription:id, name:name, user:user.name}"
-az webapp show -g <RESOURCE_GROUP> -n <APP_NAME> \
+az webapp show -g $AZURE_RESOURCE_GROUP_NAME -n $APP_SERVICE_APP_NAME \
   --query "{name:name, state:properties.state, hostNames:properties.hostNames}"
 ```
 
 ## 2. List all slots and their current traffic weights
 
 ```bash
-az webapp deployment slot list -g <RESOURCE_GROUP> -n <APP_NAME> \
+az webapp deployment slot list -g $AZURE_RESOURCE_GROUP_NAME -n $APP_SERVICE_APP_NAME \
   --query "[].{name:name, state:properties.state}"
-az webapp traffic-routing show -g <RESOURCE_GROUP> -n <APP_NAME>
+az webapp traffic-routing show -g $AZURE_RESOURCE_GROUP_NAME -n $APP_SERVICE_APP_NAME
 ```
 
 ## 3. Compare app settings between slots
 
 ```bash
-az webapp config appsettings list -g <RESOURCE_GROUP> -n <APP_NAME> \
+az webapp config appsettings list -g $AZURE_RESOURCE_GROUP_NAME -n $APP_SERVICE_APP_NAME \
   --slot staging --query "[].{name:name, slotSetting:slotSetting}"
-az webapp config appsettings list -g <RESOURCE_GROUP> -n <APP_NAME> \
+az webapp config appsettings list -g $AZURE_RESOURCE_GROUP_NAME -n $APP_SERVICE_APP_NAME \
   --query "[].{name:name, slotSetting:slotSetting}"
 ```
 
@@ -33,7 +39,7 @@ Settings with `slotSetting: true` are slot-sticky and will NOT be swapped.
 ## 4. Check slot health before swap
 
 ```bash
-az webapp show -g <RESOURCE_GROUP> -n <APP_NAME> --slot staging \
+az webapp show -g $AZURE_RESOURCE_GROUP_NAME -n $APP_SERVICE_APP_NAME --slot staging \
   --query "{state:properties.state, availabilityState:properties.availabilityState}"
 # State must be "Running" and availabilityState must be "Normal" before swap
 ```
@@ -41,6 +47,25 @@ az webapp show -g <RESOURCE_GROUP> -n <APP_NAME> --slot staging \
 ## 5. Review connection strings
 
 ```bash
-az webapp config connection-string list -g <RESOURCE_GROUP> -n <APP_NAME> --slot staging \
+az webapp config connection-string list -g $AZURE_RESOURCE_GROUP_NAME -n $APP_SERVICE_APP_NAME --slot staging \
   --query "[].{name:name, type:type, slotSetting:slotSetting}"
 ```
+
+
+## 6. Start swap with preview, then validate before completion
+
+```bash
+az webapp deployment slot swap \
+  -g $AZURE_RESOURCE_GROUP_NAME -n $APP_SERVICE_APP_NAME \
+  --slot staging --target-slot production --action preview
+
+# Complete only after validation succeeds
+az webapp deployment slot swap \
+  -g $AZURE_RESOURCE_GROUP_NAME -n $APP_SERVICE_APP_NAME \
+  --slot staging --target-slot production --action swap
+
+# Reset if validation fails
+az webapp deployment slot swap \
+  -g $AZURE_RESOURCE_GROUP_NAME -n $APP_SERVICE_APP_NAME \
+  --slot staging --target-slot production --action reset
+```