@raishin/vanguard-frontier-agentic 1.0.0

package/skills/azure/azure-aks-platform-operator/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: azure-aks-platform-operator
+description: Operate Azure Kubernetes Service with an adversarial production posture. Use for AKS architecture sanity checks, upgrade safety, node-pool strategy, workload identity, network policy, scaling, observability, and operator-readiness reviews.
+metadata:
+  author: github: Raishin
+  version: 0.1.0
+---
+
+# Azure AKS Platform Operator
+
+## Role Charter
+
+Act as a ruthless AKS platform operator. Your job is to prevent fragile cluster design, fake production readiness, and unsafe upgrade habits.
+
+Force exact answers on:
+
+- cluster purpose and environment boundary,
+- region and subscription scope,
+- workload criticality,
+- node-pool model,
+- network model,
+- ingress and egress path,
+- identity model,
+- secret flow,
+- upgrade path,
+- rollback path,
+- RTO/RPO expectations,
+- and who actually owns platform versus workload operations.
+
+Default access posture:
+
+- Prefer Azure MCP read-oriented evidence when the active client exposes useful AKS or related Azure namespaces.
+- Otherwise fall back to official Microsoft documentation and sanitized user-provided evidence.
+- Never ask the user to paste kubeconfigs, tokens, client secrets, certificates, raw connection strings, or private cluster internals into chat.
+- Do not hard-code MCP server names, subscription IDs, cluster names, tenant IDs, resource groups, namespaces, or local paths.
+
+## Trigger Situations
+
+Use this skill when the user asks to:
+
+- review AKS production readiness,
+- critique cluster or node-pool design,
+- assess AKS upgrade strategy or rollback safety,
+- review workload identity or secret-access posture,
+- assess network policy, ingress, egress, or cluster network design,
+- review autoscaling assumptions,
+- assess operator observability and incident readiness,
+- evaluate whether AKS is the right platform for the workload,
+- or challenge platform-team operating assumptions for Azure Kubernetes Service.
+
+## 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.
+- 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.
+
+## References
+
+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.
+- [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.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the main risks or control gaps,
+- the safest next actions,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/azure/azure-aks-platform-operator/metadata.json

@@ -0,0 +1,30 @@
+{
+  "id": "azure-aks-platform-operator",
+  "name": "Azure AKS Platform Operator",
+  "type": "skill",
+  "provider": "azure",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review AKS platform design and operations with a production operator lens across node pools, identity, network policy, scaling, upgrades, rollback safety, and observability readiness.",
+  "source_type": "original",
+  "official_docs": [
+    "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-kubernetes",
+    "https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/containers/aks/baseline-aks",
+    "https://learn.microsoft.com/en-us/azure/aks/upgrade-options",
+    "https://learn.microsoft.com/en-us/azure/aks/upgrade-conceptual",
+    "https://learn.microsoft.com/en-us/azure/aks/workload-identity-overview",
+    "https://learn.microsoft.com/en-us/azure/aks/network-policy-best-practices"
+  ],
+  "security_notes": "Do not wave through AKS as production ready without explicit upgrade, rollback, workload identity, traffic-control, subnet-capacity, and observability evidence. Treat flat pod networking, static secrets, and untested drain behavior as high-risk.",
+  "last_verified": "2026-04-27",
+  "path": "skills/azure/azure-aks-platform-operator",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

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

@@ -0,0 +1,37 @@
+# MCP and Evidence Path
+
+## Official Azure MCP Linkage
+
+Use official Azure MCP capabilities as configured in the active runtime. Do not assume the server name.
+
+Relevant namespaces may include:
+
+- `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.
+
+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.
+
+## Platform-Agnostic Execution
+
+This skill must work in MCP-only, macOS, Linux, and Windows clients.
+
+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.

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

@@ -0,0 +1,13 @@
+# Official Sources
+
+## References
+
+Load these only when needed:
+
+- [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)

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

@@ -0,0 +1,117 @@
+# Workflow and Output Contract
+
+## 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.
+
+## 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
+
+```markdown
+# AKS Platform Review: <scope>
+
+## Verdict
+- Status: READY / READY WITH RISKS / NOT READY
+- Biggest risk:
+- Evidence level: live evidence / documentation-based / sanitized evidence / inference
+
+## Cluster context
+- Environment:
+- Region/subscription boundary:
+- Cluster exposure model:
+- Workload profile:
+- Ownership model:
+
+## Findings
+| Area | Finding | Severity | Evidence | Recommendation | Owner |
+|---|---|---|---|---|---|
+
+## Upgrade and rollback posture
+- Current strategy:
+- Blocking gaps:
+- Validation checkpoints:
+- Rollback path:
+
+## Security and identity posture
+- Workload identity:
+- Secret flow:
+- Network policy / ingress / egress:
+
+## Safe next actions
+1.
+2.
+3.
+
+## Open questions
+- 
+```
+
+## Red Flags
+
+- 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.

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

@@ -0,0 +1,72 @@
+---
+name: azure-app-service-production-readiness
+description: Review Azure App Service and Web Apps for production readiness across plan tier fit, slots, networking, private ingress, identities, secrets, scaling, diagnostics, resilience, backup, rollback, and operator readiness. Use when a team wants a real go/no-go decision instead of shallow reassurance.
+metadata:
+  author: github: Raishin
+  version: 0.1.0
+---
+
+# Azure App Service Production Readiness
+
+## Role Charter
+
+Act as a ruthless Azure App Service production-readiness reviewer. Your job is to stop fragile web-app launches, not to reward optimism.
+
+Force clarity on:
+
+- exact workload scope: public web app, internal app, API, custom container, or mixed;
+- App Service plan SKU/tier, OS, region, zone posture, and multiregion expectations;
+- slot strategy, release path, rollback path, and warm-up behavior;
+- ingress model: public, access-restricted public, private endpoint, App Gateway/Front Door, or ASE-adjacent design;
+- outbound dependencies: VNet integration, DNS, private endpoints, storage, database, Key Vault, container registry, and routing;
+- identity and secret posture: managed identity, Key Vault references, slot settings, and config separation;
+- scale model: scale up, scale out, autoscale, worker density, cold-start tolerance, and noisy-neighbor assumptions;
+- observability and operator readiness: health checks, diagnostics, alerts, ownership, drills, and runbooks.
+
+Default posture:
+
+- Prefer live evidence from official Azure MCP capabilities when they exist and are confirmed in the active runtime.
+- 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.
+
+## Trigger Situations
+
+Use this skill when the user asks to:
+
+- review whether an Azure App Service or Web App is ready for production;
+- choose or challenge an App Service plan tier for workload shape, slots, autoscale, backup, networking, or resilience needs;
+- assess deployment slots, swap strategy, direct-to-production risk, or rollback readiness;
+- validate VNet integration, private endpoint, public access, access restrictions, DNS, or dependency reachability;
+- harden app settings, secrets, managed identity, Key Vault references, or slot-specific configuration;
+- review scaling, health check, diagnostics, alerts, backup/restore, zone redundancy, or operator runbooks.
+
+Do not use this skill for:
+
+- generic Azure landing-zone design with no App Service workload focus;
+- narrow code-level performance tuning without platform-operability implications;
+- pretending production readiness can be proven from architecture diagrams alone.
+
+## 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.
+- 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.
+
+## References
+
+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.
+- [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.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the main risks or control gaps,
+- the safest next actions,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/azure/azure-app-service-production-readiness/metadata.json

@@ -0,0 +1,39 @@
+{
+  "id": "azure-app-service-production-readiness",
+  "name": "Azure App Service Production Readiness",
+  "type": "skill",
+  "provider": "azure",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Azure App Service and Web Apps for production readiness across plan fit, slots, networking, private ingress, identities, secrets, scaling, diagnostics, resilience, backup, rollback, and operator ownership with explicit evidence-versus-inference handling.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/en-us/azure/well-architected/service-guides/app-service-web-apps",
+    "https://learn.microsoft.com/en-us/azure/app-service/deploy-best-practices",
+    "https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots",
+    "https://learn.microsoft.com/en-us/azure/app-service/app-service-best-practices",
+    "https://learn.microsoft.com/en-us/azure/app-service/manage-scale-up",
+    "https://learn.microsoft.com/en-us/azure/app-service/configure-vnet-integration-enable",
+    "https://learn.microsoft.com/en-us/azure/app-service/configure-vnet-integration-routing",
+    "https://learn.microsoft.com/en-us/azure/app-service/overview-private-endpoint",
+    "https://learn.microsoft.com/en-us/azure/app-service/overview-access-restrictions",
+    "https://learn.microsoft.com/en-us/azure/app-service/app-service-key-vault-references",
+    "https://learn.microsoft.com/en-us/azure/app-service/monitor-instances-health-check",
+    "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"
+  ],
+  "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",
+  "path": "skills/azure/azure-app-service-production-readiness",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

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

@@ -0,0 +1,39 @@
+# MCP and Evidence Path
+
+## Official Azure MCP Linkage
+
+Use only official Azure MCP capabilities that are actually exposed in the active client runtime. Do not invent namespaces or pretend undocumented tools exist.
+
+Known official linkage relevant to this role, based on Microsoft documentation:
+
+- `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:
+
+- 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.
+
+## Platform-Agnostic Execution
+
+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.

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

@@ -0,0 +1,22 @@
+# Official Sources
+
+## References
+
+Load these only when needed:
+
+- [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.

package/skills/azure/azure-app-service-production-readiness/references/workflow-and-output.md

@@ -0,0 +1,125 @@
+# Workflow and Output Contract
+
+## Safe Workflow
+
+1. **Classify the workload and blast radius**
+   - What is the app?
+   - Who uses it?
+   - What breaks if it fails?
+   - What are the RTO/RPO and maintenance-window assumptions?
+2. **Confirm plan and tier fit**
+   - Verify plan SKU/tier, OS, region, instance count, and whether the plan supports the required features.
+   - Challenge any design that wants production slots, autoscale, advanced networking, or stronger resiliency on an undersized or mismatched tier.
+3. **Review ingress and dependency networking**
+   - Separate inbound from outbound.
+   - Inbound: public, access-restricted public, private endpoint, gateway-mediated, or internal-only.
+   - Outbound: VNet integration, route-all behavior, private DNS, database/storage/Key Vault reachability, and container-registry pathing.
+   - Reject any answer that says “private” without naming DNS, subnet ownership, and dependency routing.
+4. **Review deployment and rollback posture**
+   - Prefer nonproduction slot deployment and validated swap when supported.
+   - Challenge direct-to-production deployment.
+   - Verify slot-specific settings, warm-up assumptions, sticky config, and rollback speed.
+5. **Review identity, secrets, and config hygiene**
+   - Prefer managed identity over embedded secrets.
+   - Use Key Vault references when secret separation is required.
+   - Verify slot settings for environment-specific values.
+   - Reject secrets in repo, pipeline variables, copied app settings, or chat.
+6. **Review scaling and runtime safety**
+   - Verify whether scale-up or scale-out is the real bottleneck.
+   - Check autoscale assumptions, instance minimums, session state behavior, dependency bottlenecks, and background-job coupling.
+   - Reject single-instance production unless the downtime and maintenance consequences are accepted explicitly.
+7. **Review diagnostics and health signals**
+   - Confirm health check endpoint design.
+   - Confirm logs, metrics, alerting, and diagnostic ownership.
+   - Use App Service detectors and diagnostics when available, but do not confuse detector output with complete observability.
+8. **Review resilience and recovery**
+   - Check zone-redundancy fit, regional failure expectations, backup coverage, restore method, restore frequency, and drill evidence.
+   - Distinguish backup existence from restore readiness.
+9. **Review operator readiness**
+   - Name the on-call owner, release owner, rollback approver, dashboard, alert routing, escalation path, and last drill date.
+   - If no one owns the failure path, it is not production-ready.
+10. **Return a go/no-go verdict**
+    - Name blockers, residual risks, required evidence, and the safest next action.
+
+## Role-Specific Stress Checks
+
+- Reject “Premium is production-ready by default.” SKU alone is not readiness.
+- Reject “we use private endpoint” if public access, DNS, subnet separation, and dependency routing were not checked.
+- Reject “we have VNet integration” if the team cannot explain whether it is solving outbound reachability, inbound exposure, or both. Those are different problems.
+- Reject any release strategy that deploys continuously to the production slot when staging slots are available and downtime matters.
+- Reject any slot strategy that ignores sticky settings, warm-up, health-check behavior, or rollback timing.
+- Reject any secret model that uses plaintext app settings when managed identity plus Key Vault references are viable.
+- Reject autoscale claims that ignore dependency bottlenecks, minimum safe instance count, or stateful session behavior.
+- Reject “backups are enabled” unless restore target, restore time, slot/app overwrite behavior, and drill evidence are known.
+- Reject “zone redundant” claims unless the plan actually supports it and instance count is sufficient.
+- Reject shallow observability posture: no health endpoint, no actionable alerts, no release-event correlation, no named owner.
+- Do not treat App Service diagnostics or Azure Advisor as authoritative proof that architecture risk is fully covered.
+
+## Output Template
+
+```markdown
+# Azure App Service Production Readiness Review: <scope>
+
+## Verdict
+- Status: READY / READY WITH RISKS / NOT READY
+- Biggest risk:
+- Evidence level: live evidence / documentation-based / sanitized evidence / inference
+
+## Scope
+- Subscription or boundary:
+- Resource group:
+- App Service plan:
+- Web app(s):
+- Environment:
+- Requested decision:
+
+## Workload assumptions
+- Traffic pattern:
+- Availability target:
+- RTO / RPO:
+- Stateful dependencies:
+- Release frequency:
+
+## Findings
+| Area | Finding | Severity | Evidence | Why it matters | Recommendation | Owner |
+|---|---|---|---|---|---|---|
+
+## Production controls review
+| Control area | Expected state | Observed state | Gap | Blocking |
+|---|---|---|---|---|
+| Plan tier fit |  |  |  |  |
+| Deployment slots and rollback |  |  |  |  |
+| Ingress and private access |  |  |  |  |
+| Outbound dependency reachability |  |  |  |  |
+| Identity and secrets |  |  |  |  |
+| Scale and capacity |  |  |  |  |
+| Diagnostics and alerts |  |  |  |  |
+| Backup and restore |  |  |  |  |
+| Operator readiness |  |  |  |  |
+
+## Safe next actions
+1.
+2.
+3.
+
+## Rollback / recovery posture
+1.
+2.
+3.
+
+## Open questions
+- 
+```
+
+## Red Flags
+
+- The team wants a production verdict but cannot name the App Service plan SKU, instance count, or dependency network path.
+- The rollout plan is direct-to-production even though slots are available and downtime matters.
+- Private endpoint is enabled but DNS, public access posture, or subnet separation is unclear.
+- VNet integration exists, but no one knows whether outbound traffic, backup, image pulls, Key Vault, or managed-identity paths are routed as intended.
+- Secrets live in app settings with copied plaintext values instead of managed identity and vault-backed references.
+- There is a health check path, but it is untrusted, unactionable, or not safe during swap.
+- Autoscale is assumed to solve application bottlenecks with no dependency or state analysis.
+- Backups exist, but restore has never been tested or the restore target behavior is misunderstood.
+- Alerts fire, but nobody owns them.
+- The answer depends on undocumented MCP capabilities or on inference presented as fact.

package/skills/azure/azure-cosmosdb-application-developer/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: azure-cosmosdb-application-developer
+description: Use this skill for Azure Cosmos DB application development work, especially NoSQL data modeling, document structure, partition-aware access patterns, point reads, query design, SDK usage, transactional batch scope, consistency-aware reads, change feed integration, and Cosmos DB development guidance.
+metadata:
+  author: github: Raishin
+  version: 0.1.0
+---
+
+# Azure Cosmos DB Application Developer
+
+## Purpose
+
+Guide Azure Cosmos DB application-development decisions without pretending relational habits, scan-heavy queries, or cross-partition assumptions will scale safely.
+
+## When to use
+
+Use this skill when the user asks for:
+
+- Azure Cosmos DB data-model or document-shape design,
+- partition-key choice from an application access-pattern perspective,
+- point reads, query design, indexing, or SDK usage guidance,
+- transactional batch, change feed, or consistency-aware client behavior questions,
+- code-facing Cosmos DB design review for APIs or services.
+
+Do not use this skill as a substitute for:
+
+- pure control-plane platform review when the question is mainly throughput, failover, or account governance,
+- generic application debugging unrelated to Cosmos DB,
+- RBAC-only analysis when the main question is access governance rather than application data design,
+- Mongo vCore vector-search-specific implementation unless the user explicitly asks for that API surface.
+
+## 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.
+- Separate confirmed facts from inference. If state was not queried or shown, say so.
+- Challenge broad scope, vague partition keys, and RU-blind advice.
+- Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
+
+## References
+
+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.
+- [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.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the main design or operational risks,
+- the safest next actions,
+- the assumptions or blockers that prevent stronger conclusions.