@raishin/vanguard-frontier-agentic 2.8.0 → 2.9.0

package/skills/azure/azure-aks-platform-operator/references/aks-platform-operations.md

@@ -0,0 +1,62 @@
+# AKS platform operations
+
+## What people get wrong
+
+- They call AKS production-ready because the cluster exists and nodes are healthy. That ignores ingress, egress, identity, policy, upgrades, subnet capacity, workload health, and recovery.
+- They treat Kubernetes manifests as proof of live posture. Desired state is not current state.
+- They run production upgrades without proving surge capacity, IP availability, PDB behavior, add-on compatibility, or workload drain behavior.
+- They use static credentials in pods instead of workload identity.
+- They enable network policy without a default-deny model, DNS/log exceptions, or engine-specific caveats.
+
+## Officially grounded service shape
+
+Microsoft's AKS baseline architecture frames AKS as a multi-team platform with hub-spoke networking, private endpoints for dependencies, separate system and user node pools, Entra integration, private API options, GitOps-friendly operations, monitoring, and explicit upgrade practices. Microsoft Learn also stresses that Kubernetes evolves quickly and that production updates need testing, maintenance windows, quota, subnet capacity, and rollback strategy.
+
+## Non-negotiable design rules
+
+1. Separate system and user node pools; isolate workload pools when risk, OS, tenancy, or scaling differs.
+2. Plan subnet and pod IP space for scale-out and upgrade surge, not just today's nodes.
+3. Use workload identity or managed identity patterns for Azure access; do not normalize static secrets.
+4. Use network policy intentionally: default deny, specific allows, DNS/logging exceptions, and engine-aware implementation.
+5. Keep image supply chain private and authorized where production reliability or compliance matters.
+6. Test cluster and node upgrades in preproduction before production.
+7. Require telemetry for cluster, nodes, pods, ingress, workloads, and dependencies.
+
+## Minimal safe implementation flow
+
+1. Classify cluster topology and criticality.
+2. Confirm version, node pools, zones, SKU capacity, OS mix, add-ons, and upgrade channel.
+3. Review network: API exposure, ingress, egress, CNI, policy engine, private endpoints, DNS, firewall, and IP capacity.
+4. Review identity: Entra integration for humans; workload identity for pods; least-privilege Azure permissions.
+5. Review workload resilience: replicas, PDBs, probes, requests/limits, autoscaling, affinity, and disruption behavior.
+6. Review operations: GitOps/pipeline flow, monitoring, alerts, backup, incident runbooks, and ownership.
+7. Produce a go/no-go with blockers and reversible remediations.
+
+## High-risk assumptions to kill
+
+- Healthy nodes do not prove workload readiness; probes, PDBs, ingress, egress, dependency access, and rollback behavior still need evidence.
+- An AKS version that is deployable today is not automatically inside the supported window for the intended lifecycle.
+- Cluster autoscaler, upgrade surge, and max-pods settings are unsafe if subnet, pod CIDR, and regional quota headroom are not proven.
+- Network policy is not real isolation without default-deny intent, DNS and telemetry exceptions, and engine-aware validation.
+- GitOps or IaC desired state is not proof of live cluster state unless sampled read-only evidence matches it.
+
+## Safe command/code verification targets
+
+- Inspect IaC for node-pool separation, `maxSurge`, zones, taints, labels, max pods, private API settings, authorized IPs, and maintenance windows.
+- Review manifests for probes, resource requests and limits, PDBs, topology spread, service accounts, and workload identity annotations.
+- Check network policy manifests for explicit namespace/workload selectors, default-deny baselines, DNS allowances, and telemetry egress.
+- Verify pipeline or GitOps configuration includes preproduction promotion, rollback path, and no routine direct `kubectl` production mutation path.
+- Confirm monitoring definitions cover cluster, node, pod, ingress, workload, dependency, 429/throttle-style symptoms, and actionable alerts.
+
+## Safe verification targets
+
+- Kubernetes and node image versions, supported version window, and release notes.
+- Node-pool mode, zones, min/max, surge, max pods, taints, labels, and quotas.
+- Network plugin, policy engine, public/private API, authorized IPs, ingress controller, and egress firewall.
+- Workload identities and federated credentials for Azure resource access.
+- Azure Monitor, Container Insights or managed Prometheus, diagnostic settings, alerts, and SLO dashboards.
+- Backup/recovery or redeploy strategy for cluster state and persistent application data.
+
+## When to push back
+
+Push back on direct production changes, untested automatic upgrades, shared cluster-admin access, public API exposure with no justification, no default-deny policy, subnet plans that ignore surge, or observability claims without metrics and alerts.

package/skills/azure/azure-aks-platform-operator/references/mcp-and-evidence.md

@@ -1,37 +1,27 @@
-# MCP and Evidence Path
+# MCP and evidence path for AKS platform operations
 
-## Official Azure MCP Linkage
+Use Microsoft Learn documentation through the user's configured documentation MCP as the first grounding path for Azure service behavior. This file defines evidence boundaries; it must not imply that documentation proves the user's tenant, subscription, RBAC, quotas, deployed resources, or production readiness.
 
-Use official Azure MCP capabilities as configured in the active runtime. Do not assume the server name.
+## Evidence ladder
 
-Relevant namespaces may include:
+1. `docs_only`: Microsoft Learn documentation and official architecture guidance. Use for documented behavior, caveats, and safe review criteria.
+2. `sampled_read_only`: configured-environment evidence from read-only tools, if available and explicitly scoped. Use only for the sampled resource/time window.
+3. `user_supplied`: sanitized outputs, IaC, diagrams, or metrics provided by the user. Treat as unverified unless independently checked.
+4. `mutation_ready`: documentation plus current-state evidence plus explicit approval, blast-radius statement, and rollback path.
 
-- `aks` for cluster discovery and cluster configuration evidence,
-- `monitor` for metrics/log signals when available,
-- `applicationinsights` for Application Insights resource discovery only; use `monitor` for most telemetry analysis,
-- `resourcehealth` when platform-health ambiguity exists,
-- `advisor`, `role`, or `policy` only when the question crosses into posture or governance.
+## Rules
 
-Do not invent unsupported AKS mutation flows. Based on current Azure MCP docs, AKS support is clearly cluster-oriented and should be treated primarily as evidence gathering unless the client exposes more.
+- Do not expose environment-specific implementation details in committed docs or user-facing guidance.
+- Do not ask for credentials, tokens, tenant identifiers, subscription identifiers, connection strings, private keys, customer data, or raw secrets.
+- If current-state evidence was not sampled, say `not sampled`; do not imply it.
+- If evidence is representative or partial, say so. A sample does not prove broad regional availability or production readiness.
+- Prefer read-only evidence before mutation planning. Stop for approval before write operations.
 
-## Platform-Agnostic Execution
+## Final-answer evidence language
 
-This skill must work in MCP-only, macOS, Linux, and Windows clients.
+Use phrases like:
 
-Prefer:
-
-1. Azure MCP evidence,
-2. official Microsoft Learn and Architecture Center documentation,
-3. sanitized user-provided exports or screenshots,
-4. neutral command or query shapes with `<placeholders>` only when needed.
-
-Do not assume the user runs `kubectl`, Azure CLI, Terraform, Helm, Flux, Argo CD, or GitHub Actions unless they say so.
-
-## Documentation Fallback When Live Data Is Unavailable
-
-Live Azure evidence beats theory. If live Azure MCP access is unavailable, incomplete, denied, or too risky:
-
-- switch to Microsoft Learn and Azure Architecture Center guidance,
-- ask for sanitized cluster configuration, architecture diagrams, upgrade runbooks, or redacted outputs,
-- label each conclusion as `live evidence`, `documentation-based`, `user-provided sanitized evidence`, or `inference`,
-- do not pretend documentation proves the user’s current cluster state.
+- "Based on Microsoft Learn documentation..."
+- "Configured-environment evidence was not sampled in this review."
+- "The following is an inference from the provided configuration, not proven live state."
+- "This recommendation is mutation-ready only after explicit approval and rollback review."

package/skills/azure/azure-aks-platform-operator/references/official-sources.md

@@ -1,13 +1,29 @@
-# Official Sources
+# Official sources for Azure AKS Platform Operator
 
-## References
+Use Microsoft Learn documentation through the user's configured documentation MCP before making AKS platform claims. Documentation proves documented AKS behavior; it does not prove this user's cluster version, node state, RBAC, quotas, add-ons, policies, or workload readiness.
 
-Load these only when needed:
+## Primary Microsoft Learn sources
 
-- [Azure MCP tools inventory](https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/)
-- [Azure Kubernetes Service tools for Azure MCP](https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/azure-kubernetes)
-- [Baseline architecture for an AKS cluster](https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/containers/aks/baseline-aks)
-- [AKS upgrade options and recommendations](https://learn.microsoft.com/en-us/azure/aks/upgrade-options)
-- [How AKS cluster upgrades work](https://learn.microsoft.com/en-us/azure/aks/upgrade-conceptual)
-- [Microsoft Entra Workload ID for AKS](https://learn.microsoft.com/en-us/azure/aks/workload-identity-overview)
-- [AKS network policy best practices](https://learn.microsoft.com/en-us/azure/aks/network-policy-best-practices)
+| Source | Review implication |
+| --- | --- |
+| [Baseline architecture for AKS](https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/containers/aks/baseline-aks) | Use as the minimum production reference for networking, private API, node pools, image supply chain, identity, GitOps, operations, and upgrade thinking. |
+| [AKS start-here architecture guide](https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/containers/aks-start-here) | Use to classify baseline, regulated, microservice, and BCDR variants. |
+| [Architecture best practices for AKS](https://learn.microsoft.com/en-us/azure/well-architected/service-guides/azure-kubernetes-service) | Ground reliability, security, operational excellence, cost, and performance recommendations. |
+| [AKS upgrade options](https://learn.microsoft.com/en-us/azure/aks/upgrade-options) | Use for upgrade method selection, version skew, node-pool upgrade paths, and maintenance windows. |
+| [AKS upgrade practices](https://learn.microsoft.com/en-us/azure/architecture/operator-guides/aks/aks-upgrade-practices) | Use for day-2 upgrade sequencing, preproduction validation, surge, PDB, and rollback expectations. |
+| [Workload identity overview](https://learn.microsoft.com/en-us/azure/aks/workload-identity-overview) | Prefer federated workload identity over static secrets for Azure resource access from pods. |
+| [Network policy best practices](https://learn.microsoft.com/en-us/azure/aks/network-policy-best-practices) | Use for default deny, application policies, Cilium preference for Linux, and Windows/Calico caveats. |
+| [Best practices for AKS cluster reliability](https://learn.microsoft.com/en-us/azure/aks/best-practices-app-cluster-reliability) | Ground pod scheduling, health, scaling, and recovery checks. |
+
+## Source-grounding rules
+
+- For architecture: cite Microsoft Learn and label anything cluster-specific as inference unless sampled.
+- For current state: require read-only configured-environment evidence for cluster version, upgrade channels, node-pool state, add-ons, policies, and diagnostics.
+- For Kubernetes manifests: treat local YAML as desired state, not proof of live state.
+- For kubectl output: accept only sanitized output and never ask for tokens, kubeconfigs, certificates, or private cluster endpoints.
+
+## Current review emphasis
+
+- AKS is a day-2 operations commitment, not just a managed control plane.
+- Production clusters need separate system and user node pools, planned upgrades, enough surge capacity, pod disruption planning, observability, policy, and a rollback pattern.
+- Network policy engines and Windows node behavior differ; do not write one-size-fits-all policy guidance.

package/skills/azure/azure-aks-platform-operator/references/safety-checklist.md

@@ -0,0 +1,32 @@
+# Safety checklist for Azure AKS Platform Operator
+
+## Non-negotiable gates
+
+- Never ask for kubeconfig, bearer tokens, client certificates, private endpoint hostnames, cluster-admin credentials, or secret manifests.
+- Do not approve production readiness without evidence for upgrade path, rollback path, node-pool separation, identity, network policy, ingress/egress, diagnostics, and ownership.
+- Treat kubectl-admin access as break-glass, not normal operations. Prefer GitOps or audited pipeline changes for steady-state configuration.
+- Require explicit approval before any write, drain, scale, upgrade, policy, identity, network, or workload mutation.
+- Do not assume AKS Automatic, baseline self-managed AKS, private clusters, Windows node pools, and service-mesh clusters have the same risk profile.
+
+## High-risk assumptions to kill
+
+- "Managed Kubernetes means Microsoft owns day-2 operations." The platform abstracts parts of the control plane, but cluster design and workload operations remain user responsibilities.
+- "The cluster is HA because it has multiple nodes." Node zones, system/user separation, PDBs, replicas, ingress, dependencies, and control-plane SLA matter.
+- "Network policy exists, so east-west traffic is safe." Confirm default deny, DNS/log exceptions, namespace coverage, engine, and Windows behavior.
+- "Autoscaler will save us." Requests/limits, pod disruption, quota, subnet capacity, and initialization time still determine safe scaling.
+- "We can auto-upgrade production." Push back unless preproduction compatibility, maintenance windows, PDBs, quota, and rollback are proven.
+
+## Evidence labels
+
+- `docs_only`: Microsoft Learn-based AKS guidance only.
+- `sampled_read_only`: live or configured-environment evidence was sampled safely. State scope and time.
+- `manifest_review`: repo or user-supplied manifests were reviewed but live state was not proven.
+- `mutation_ready`: current-state evidence, approval, blast radius, and rollback are documented.
+
+## Minimum safe evidence
+
+- Cluster purpose, environment, Kubernetes version, node pools, and operating system mix.
+- Network plugin, policy engine, ingress, egress, private API exposure, and subnet capacity.
+- Identity model for users and workloads.
+- Upgrade channel or manual upgrade process, maintenance window, surge, PDBs, and preproduction validation.
+- Metrics, logs, alerts, backup/recovery, runbooks, and ownership.

package/skills/azure/azure-aks-platform-operator/references/workflow-and-output.md

@@ -1,117 +1,39 @@
-# Workflow and Output Contract
+# Workflow and output contract for Azure AKS Platform Operator
 
-## Safe Workflow
+## Minimal safe workflow
 
-1. **Classify the cluster**
-   - production, preproduction, dev/test, or shared platform,
-   - single-region or multi-region,
-   - public API server or private cluster,
-   - stateless-heavy, stateful, latency-sensitive, regulated, or mixed workload.
-2. **Map ownership**
-   - who owns cluster lifecycle,
-   - who owns workloads,
-   - who owns networking, identity, secrets, and observability,
-   - whether responsibilities are explicit or dangerously fuzzy.
-3. **Check baseline platform shape**
-   - node-pool separation for system versus user workloads,
-   - cluster/network model,
-   - ingress pattern,
-   - IP capacity assumptions,
-   - availability-zone and region posture where relevant.
-4. **Challenge identity and secret assumptions**
-   - workload identity versus legacy credential patterns,
-   - cluster identity and kubelet identity boundaries,
-   - Key Vault or external secret flow,
-   - least-privilege posture and scope.
-5. **Check traffic controls**
-   - network policy presence and intent,
-   - east-west restrictions,
-   - ingress exposure,
-   - egress control assumptions,
-   - private dependency access and DNS implications.
-6. **Check scaling realism**
-   - node autoscaling,
-   - workload HPA/VPA assumptions,
-   - headroom policy,
-   - IP exhaustion risk,
-   - pod density and node sizing assumptions.
-7. **Check upgrade safety**
-   - supported version posture,
-   - in-place versus blue-green strategy,
-   - max surge / max unavailable assumptions,
-   - PDB behavior,
-   - undrainable-node risk,
-   - rollback and validation checkpoints.
-8. **Check observability and operations**
-   - cluster and workload telemetry,
-   - upgrade and failure visibility,
-   - alert quality,
-   - runbooks,
-   - on-call handoff clarity,
-   - recovery drill evidence.
-9. **Return a go / no-go style verdict**
-   - what is credible,
-   - what is fragile,
-   - what is missing,
-   - and what must be validated before any change.
+1. Classify the request: architecture review, upgrade review, network review, identity review, scaling review, production-readiness review, or incident triage.
+2. Ground the baseline in Microsoft Learn via the user's configured documentation MCP.
+3. Identify cluster topology: baseline, AKS Automatic, regulated, private, multiregion, Windows/Linux, service mesh, or mixed.
+4. Gather safe evidence: desired-state manifests, read-only configured-environment observations if available, and sanitized user context.
+5. Stress test: node-pool design, subnet/IP capacity, network policy, ingress/egress, workload identity, secret flow, image supply chain, upgrade path, rollback, observability, and BCDR.
+6. Return a verdict with blockers and safe next actions.
+7. For mutations, stop for explicit approval after summarizing blast radius and rollback.
 
-## Role-Specific Stress Checks
-
-- Reject “AKS is managed so upgrades are easy” as shallow thinking. Managed control plane does not remove node-pool, PDB, IP, or workload-compatibility risk.
-- Reject “we use Kubernetes so we are cloud-native” as meaningless unless operator discipline, upgrade cadence, and observability are proven.
-- If production has no tested rollback path for upgrades, call it out as not operationally ready.
-- If workloads still rely on long-lived secrets where workload identity should be used, flag it.
-- If pod-to-pod traffic is effectively flat and unrestricted, flag the lateral-movement risk.
-- If the cluster subnet is tight and surge or pod density assumptions are hand-wavy, flag IP exhaustion risk.
-- If the platform team cannot explain system versus user node-pool separation, treat that as an operational maturity gap.
-- If the cluster is treated as immutable infrastructure, require a credible replacement-cluster strategy; otherwise require an in-place upgrade strategy.
-
-## Output Template
+## Output contract
 
 ```markdown
-# AKS Platform Review: <scope>
-
 ## Verdict
-- Status: READY / READY WITH RISKS / NOT READY
-- Biggest risk:
-- Evidence level: live evidence / documentation-based / sanitized evidence / inference
+<go | conditional-go | no-go | docs-only advisory>
 
-## Cluster context
-- Environment:
-- Region/subscription boundary:
-- Cluster exposure model:
-- Workload profile:
-- Ownership model:
+## Evidence level
+- Documentation: <sources used>
+- Cluster evidence: <sampled_read_only | manifest_review | not sampled>
 
 ## Findings
-| Area | Finding | Severity | Evidence | Recommendation | Owner |
-|---|---|---|---|---|---|
+1. <finding> — Evidence: <docs_only|sampled_read_only|manifest_review|inference>
 
-## Upgrade and rollback posture
-- Current strategy:
-- Blocking gaps:
-- Validation checkpoints:
-- Rollback path:
+## Upgrade / rollback posture
+- Current proof: <what is known>
+- Gaps: <what is missing>
 
-## Security and identity posture
-- Workload identity:
-- Secret flow:
-- Network policy / ingress / egress:
+## Blockers
+- <production blocker>
 
 ## Safe next actions
-1.
-2.
-3.
-
-## Open questions
--
+- <least-risk action>
 ```
 
-## Red Flags
+## Pushback triggers
 
-- The team wants production AKS guidance but cannot state cluster version, node-pool layout, or upgrade ownership.
-- The design depends on surge upgrades but there is no subnet headroom calculation.
-- The plan assumes Pod Disruption Budgets help, but nobody tested whether they block drains.
-- The platform still depends on static secrets even though Microsoft Entra Workload ID is the safer target model.
-- The answer claims high availability without distinguishing zone resilience, regional failure, and workload replication behavior.
-- The answer recommends AKS by default without testing whether the workload actually needs Kubernetes complexity.
+Reject or downgrade the verdict when the plan skips preproduction upgrades, lacks rollback, uses cluster-admin as normal access, exposes the API publicly without justification, has no network policy/default-deny story, lacks workload identity, or has no health/alert/runbook ownership.

package/skills/azure/azure-app-service-production-readiness/SKILL.md

@@ -4,8 +4,8 @@ description: Review Azure App Service and Web Apps for production readiness acro
 allowed-tools: Read Grep Glob
 metadata:
   author: github: Raishin
-  version: 0.1.0
-  updated: "2026-05-05"
+  version: 0.1.3
+  updated: "2026-06-05"
   category: platform
 ---
 
@@ -28,7 +28,7 @@ Force clarity on:
 
 Default posture:
 
-- Prefer live evidence from official Azure MCP capabilities when they exist and are confirmed in the active runtime.
+- Prefer Microsoft Learn documentation through the user's configured documentation MCP; use sampled read-only Azure evidence when it is safely available.
 - Prefer official Microsoft Learn and Well-Architected guidance over memory or blog folklore.
 - Never ask the user to paste secrets, connection strings, publish profiles, certificates, tenant secrets, or customer data into chat.
 - Refuse “looks good” verdicts when rollback, monitoring, networking, or operational ownership is vague.
@@ -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 the active client exposes it, 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.
+- [Operations guide](references/app-service-production-operations.md) — use for service-specific pitfalls, design rules, verification targets, and pushback criteria.
+- [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing documentation-based evidence, sampled read-only Azure evidence, or sanitized user evidence.
+- [Safety checklist](references/safety-checklist.md) — use for evidence labels, risk gates, mutation boundaries, approval rules, and credential boundaries.
 - [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-app-service-production-readiness/metadata.json

@@ -28,12 +28,11 @@
     "https://learn.microsoft.com/en-us/azure/app-service/manage-backup",
     "https://learn.microsoft.com/en-us/azure/app-service/configure-zone-redundancy",
     "https://learn.microsoft.com/en-us/azure/reliability/reliability-app-service",
-    "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-app-service"
+    "https://learn.microsoft.com/en-us/azure/architecture/web-apps/app-service/architectures/baseline-zone-redundant"
   ],
-  "security_notes": "Do not confuse plan SKU with readiness, public access restrictions with true private ingress, or backup configuration with recovery readiness. Prefer managed identity and Key Vault references over embedded secrets, treat app settings as sensitive, and do not invent unsupported Azure MCP namespaces or operations.",
-  "last_verified": "2026-04-27",
+  "security_notes": "Do not confuse plan SKU with readiness, public access restrictions with true private ingress, or backup configuration with recovery readiness. Prefer managed identity and Key Vault references over embedded secrets, treat app settings as sensitive, and do not invent unsupported configured Azure evidence namespaces or operations.",
+  "last_verified": "2026-06-05",
   "path": "skills/azure/azure-app-service-production-readiness",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.3"
 }

package/skills/azure/azure-app-service-production-readiness/references/app-service-production-operations.md

@@ -0,0 +1,61 @@
+# App Service production operations
+
+## What people get wrong
+
+- They treat App Service as production-ready because it is PaaS. The workload still needs health, scaling, network, identity, release, and recovery design.
+- They trust slots without checking warm-up, sticky settings, dependency compatibility, and rollback drills.
+- They confuse VNet integration with private ingress. VNet integration controls outbound access; private endpoint and access restrictions control inbound exposure.
+- They put secrets in app settings instead of using managed identity and Key Vault references.
+- They configure backup but never prove restore, especially for state stores outside the app.
+
+## Officially grounded service shape
+
+Microsoft Learn frames App Service readiness around Well-Architected pillars. Production web apps need appropriate plan tier and instance count, health checks, diagnostics, HTTPS/TLS, managed identity, private networking where needed, deployment slots for release safety, autoscale, zone or regional resilience where required, and clear backup/restore ownership.
+
+## Non-negotiable design rules
+
+1. Use multiple instances for production workloads unless the business explicitly accepts single-instance risk.
+2. Enable health check with a path that proves critical dependency readiness without leaking sensitive data.
+3. Use managed identity and Key Vault references for secrets; never normalize pasted secrets.
+4. Validate inbound and outbound networking separately.
+5. Use staging slots for risky deployments and prove swap/rollback behavior.
+6. Use native database backup/restore for linked state stores; do not rely on App Service backup as a database recovery strategy.
+7. Enable diagnostics, metrics, alerts, and operator runbooks before go-live.
+
+## Minimal safe implementation flow
+
+1. Inventory app, plan, OS, region, tier, instances, deployment model, and dependencies.
+2. Verify ingress: public endpoint, access restrictions, private endpoint, DNS, Front Door/Application Gateway, WAF, and SCM exposure.
+3. Verify outbound: VNet integration, route-all, DNS, private endpoints, Key Vault, database, storage, registry, and firewall paths.
+4. Verify identity and secrets: system/user-assigned identity, Key Vault role or access policy, slot-specific references, and no embedded secret values.
+5. Verify release: staging slot, warm-up path, swap with preview if needed, sticky settings, rollback, and smoke tests.
+6. Verify resilience: health check, auto-heal, autoscale, zone/multiregion posture, backup, restore test, and dependency retry/circuit breakers.
+7. Deliver go/no-go with blockers.
+
+## High-risk assumptions to kill
+
+- App Service being managed PaaS does not prove production readiness; plan sizing, instance count, health checks, release safety, and dependency recovery still matter.
+- A staging slot is not a rollback plan unless sticky settings, warm-up path, smoke tests, and swap reversal are rehearsed.
+- VNet integration is outbound connectivity only; it does not provide private inbound access to the app.
+- App Service backup does not restore every surrounding dependency, network feature, identity, alert, or deployment slot.
+- A green health endpoint is weak evidence if it does not represent critical dependency readiness or if it leaks sensitive internals.
+
+## Safe command/code verification targets
+
+- Inspect IaC for plan SKU, worker count, zone redundancy, Always On, health check path, autoscale rules, diagnostics, and backup configuration.
+- Review deployment automation for staging-slot deployment, smoke testing, swap operation, rollback operation, and tagged container/image provenance.
+- Check app configuration for Key Vault references, managed identity use, slot-specific settings, no embedded secrets, and SCM access restrictions.
+- Validate templates distinguish private endpoint inbound access from VNet integration outbound access and include private DNS where required.
+- Review restore/runbook evidence for app content, configuration, custom domains, TLS, identities, networking, databases, and alerts instead of assuming one backup covers all.
+
+## Safe verification targets
+
+- Plan SKU/tier, worker count, autoscale rules, Always On, health check, and auto-heal.
+- Slot list, slot settings, traffic routing, swap behavior, and rollback evidence.
+- Public network setting, access restrictions, private endpoints, DNS, reverse proxy, and SCM restrictions.
+- Managed identity, Key Vault reference resolution, network-restricted vault access, and config separation.
+- Diagnostic settings, App Insights, alerts, log retention, backup schedule, and restore test results.
+
+## When to push back
+
+Push back on production launch if rollback is manual guesswork, health check is absent, public access is unexplained, secrets are embedded, linked database backup is assumed, or no one owns alerts and restore drills.

package/skills/azure/azure-app-service-production-readiness/references/mcp-and-evidence.md

@@ -1,39 +1,27 @@
-# MCP and Evidence Path
+# MCP and evidence path for App Service production operations
 
-## Official Azure MCP Linkage
+Use Microsoft Learn documentation through the user's configured documentation MCP as the first grounding path for Azure service behavior. This file defines evidence boundaries; it must not imply that documentation proves the user's tenant, subscription, RBAC, quotas, deployed resources, or production readiness.
 
-Use only official Azure MCP capabilities that are actually exposed in the active client runtime. Do not invent namespaces or pretend undocumented tools exist.
+## Evidence ladder
 
-Known official linkage relevant to this role, based on Microsoft documentation:
+1. `docs_only`: Microsoft Learn documentation and official architecture guidance. Use for documented behavior, caveats, and safe review criteria.
+2. `sampled_read_only`: configured-environment evidence from read-only tools, if available and explicitly scoped. Use only for the sampled resource/time window.
+3. `user_supplied`: sanitized outputs, IaC, diagrams, or metrics provided by the user. Treat as unverified unless independently checked.
+4. `mutation_ready`: documentation plus current-state evidence plus explicit approval, blast-radius statement, and rollback path.
 
-- `appservice` for web app details, app settings, deployment details, detectors, and App Service diagnostics actions.
-- `monitor` for logs and metrics if the runtime exposes Azure Monitor tools.
-- `resourcehealth` for current health events if the runtime exposes Azure Resource Health tools.
-- `advisor` for recommendation discovery if the runtime exposes Azure Advisor tools.
-- `pricing`, `quota`, `group`, and `subscription` can help with supporting evidence when exposed.
+## Rules
 
-Rules:
+- Do not expose environment-specific implementation details in committed docs or user-facing guidance.
+- Do not ask for credentials, tokens, tenant identifiers, subscription identifiers, connection strings, private keys, customer data, or raw secrets.
+- If current-state evidence was not sampled, say `not sampled`; do not imply it.
+- If evidence is representative or partial, say so. A sample does not prove broad regional availability or production readiness.
+- Prefer read-only evidence before mutation planning. Stop for approval before write operations.
 
-- Treat `appservice` as useful but incomplete. Official documentation shows App Service MCP support for app details, settings, deployments, detectors, diagnostics, and database connection operations; it does not prove first-class slot, VNet, private endpoint, or plan-capacity mutation tooling in MCP.
-- If a needed capability is generic or ambiguous, say so explicitly and switch to documentation-grounded review instead of hallucinating a tool path.
-- Treat secret-bearing outputs, especially app settings, as sensitive even when a tool can retrieve them.
-- Distinguish read-only evidence gathering from mutating operations such as updating app settings.
+## Final-answer evidence language
 
-## Platform-Agnostic Execution
+Use phrases like:
 
-This skill must work on macOS, Windows, Linux, and MCP-only clients.
-
-- Prefer evidence categories, architecture decisions, and operator checks over shell-specific commands.
-- When examples are useful, use placeholders such as `<subscription>`, `<resource-group>`, `<web-app>`, `<plan>`, `<slot>`, and `<vnet-subnet>`.
-- Adapt Azure CLI, PowerShell, IaC, or portal-specific steps only after the user’s actual toolchain is known.
-- Keep recommendations portable across code apps and custom-container apps unless the runtime model is already fixed.
-
-## Documentation Fallback When Live Data Is Unavailable
-
-Live Azure evidence beats static guidance for current-state validation. If live inspection is unavailable, incomplete, unsafe, or denied:
-
-- fall back to the Microsoft Learn and Well-Architected references listed above;
-- ask for sanitized architecture diagrams, slot configuration summaries, dependency maps, redacted app settings keys, alert inventories, or runbook excerpts when current-state proof is required;
-- label each conclusion as `live evidence`, `documentation-based`, `user-provided sanitized evidence`, or `inference`;
-- do not claim the app is production-ready merely because the target SKU supports a feature;
-- do not claim a feature is enabled in the user’s environment unless it was confirmed live.
+- "Based on Microsoft Learn documentation..."
+- "Configured-environment evidence was not sampled in this review."
+- "The following is an inference from the provided configuration, not proven live state."
+- "This recommendation is mutation-ready only after explicit approval and rollback review."

package/skills/azure/azure-app-service-production-readiness/references/official-sources.md

@@ -1,22 +1,23 @@
-# Official Sources
+# Official sources for Azure App Service Production Readiness
 
-## References
+Use Microsoft Learn documentation through the user's configured documentation MCP to ground App Service reviews. Documentation proves service guidance; it does not prove the user's app settings, plan SKU, network routes, diagnostics, backup success, or production readiness.
 
-Load these only when needed:
+## Primary Microsoft Learn sources
 
-- [Architecture best practices for Azure App Service (Web Apps)](https://learn.microsoft.com/en-us/azure/well-architected/service-guides/app-service-web-apps) — use for pillar-based production design tradeoffs and shared-responsibility framing.
-- [Deployment best practices](https://learn.microsoft.com/en-us/azure/app-service/deploy-best-practices) — use for source/build/deploy separation, slot-first rollout, and anti-pattern detection.
-- [Set up staging environments in Azure App Service](https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots) — use for slot behavior, swap boundaries, and rollback realism.
-- [Best practices for Azure App Service](https://learn.microsoft.com/en-us/azure/app-service/app-service-best-practices) — use for runtime, scaling, cert, and diagnostics guidance.
-- [Scale up an app in Azure App Service](https://learn.microsoft.com/en-us/azure/app-service/manage-scale-up) — use for plan-tier capability questions and scale-up tradeoffs.
-- [Enable virtual network integration](https://learn.microsoft.com/en-us/azure/app-service/configure-vnet-integration-enable) — use for outbound private reachability requirements and subnet constraints.
-- [Manage App Service virtual network integration routing](https://learn.microsoft.com/en-us/azure/app-service/configure-vnet-integration-routing) — use when outbound routing, image pulls, backup, content share, or managed-identity pathing matters.
-- [Use private endpoints for Azure App Service apps](https://learn.microsoft.com/en-us/azure/app-service/overview-private-endpoint) — use for inbound private access, subnet separation, and public exposure reduction.
-- [App Service access restrictions](https://learn.microsoft.com/en-us/azure/app-service/overview-access-restrictions) — use for public-endpoint filtering and to avoid confusing it with private-endpoint controls.
-- [Use Key Vault references as app settings](https://learn.microsoft.com/en-us/azure/app-service/app-service-key-vault-references) — use for managed-identity-based secret retrieval, slot-setting guidance, and rotation caveats.
-- [Monitor App Service instances by using Health check](https://learn.microsoft.com/en-us/azure/app-service/monitor-instances-health-check) — use for health endpoint expectations, unhealthy-instance behavior, and swap implications.
-- [Back up and restore your app in Azure App Service](https://learn.microsoft.com/en-us/azure/app-service/manage-backup) — use for tier-dependent backup and restore constraints.
-- [Configure App Service plans for zone redundancy](https://learn.microsoft.com/en-us/azure/app-service/configure-zone-redundancy) — use for zone support checks and minimum-instance expectations.
-- [Reliability in Azure App Service](https://learn.microsoft.com/en-us/azure/reliability/reliability-app-service) — use for SLA/reliability framing, shared responsibility, and recovery expectations.
-- [Azure MCP Server tools inventory](https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/) — use to verify official Azure MCP namespaces before naming them.
-- [Azure MCP Server tools for Azure App Service](https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/azure-app-service) — use to confirm the actual App Service MCP operations and their limits.
+| Source | Review implication |
+| --- | --- |
+| [Architecture best practices for Azure App Service Web Apps](https://learn.microsoft.com/en-us/azure/well-architected/service-guides/app-service-web-apps) | Ground reliability, security, cost, operational excellence, scaling, health check, slots, managed identity, diagnostics, and tradeoff guidance. |
+| [Reliability in Azure App Service](https://learn.microsoft.com/en-us/azure/reliability/reliability-app-service) | Use for shared responsibility, zone/region outage posture, backup, transient faults, maintenance, and SLA framing. |
+| [Deploy to deployment slots](https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots) | Use for slot strategy, swap behavior, warm-up, sticky settings, and rollback checks. |
+| [Key Vault references for App Service](https://learn.microsoft.com/en-us/azure/app-service/app-service-key-vault-references) | Use for managed identity, secret reference, and network-restricted vault behavior. |
+| [Monitor App Service instances with health check](https://learn.microsoft.com/en-us/azure/app-service/monitor-instances-health-check) | Use for health path, unhealthy instance removal, and readiness checks. |
+| [App Service networking features](https://learn.microsoft.com/en-us/azure/app-service/networking-features) | Use for VNet integration, private endpoints, access restrictions, and outbound routing semantics. |
+| [Manage backup and restore in App Service](https://learn.microsoft.com/en-us/azure/app-service/manage-backup) | Use for backup support and linked-database backup deprecation caveats. |
+| [Baseline highly available zone-redundant web application](https://learn.microsoft.com/en-us/azure/architecture/web-apps/app-service/architectures/baseline-zone-redundant) | Use for production architecture, slots, package deployment, Key Vault references, private endpoints, and zone redundancy pattern. |
+
+## Source-grounding rules
+
+- A plan SKU recommendation from docs is not proof the current app is correctly scaled.
+- A configured slot in code is not proof of safe swap. Validate sticky settings, warm-up, health, and rollback evidence.
+- A private endpoint is not proof of private-only app posture. Check public access/access restrictions, DNS, reverse proxy path, and outbound dependencies.
+- Backup configured is not recovery proven. Require restore test evidence.