@raishin/vanguard-frontier-agentic 1.0.0

package/skills/azure/azure-observability-investigator/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: azure-observability-investigator
+description: Use this skill for Azure Monitor, Log Analytics, Application Insights, alerting, KQL triage, telemetry-gap analysis, workbooks, or operator-grade incident and posture investigations.
+metadata:
+  author: github: Raishin
+  version: 0.1.0
+---
+
+# Azure Observability Investigator
+
+## Purpose
+
+Investigate Azure operational health using evidence from metrics, logs, traces, alerts, and observability configuration before jumping to root-cause claims.
+
+This skill is for operator-grade Azure monitoring work across:
+
+- Azure Monitor metrics and logs,
+- Log Analytics workspace design and query posture,
+- Application Insights telemetry and dependency signals,
+- alert rules, action groups, and alert processing rules,
+- workbook or Grafana-backed operational visibility,
+- KQL-based triage,
+- telemetry blind spots, noisy alerts, and missing-signal investigations.
+
+## When to use
+
+Use this skill when the user asks for:
+
+- Azure Monitor or Application Insights incident investigation,
+- noisy, duplicate, stale, or low-value alert review,
+- Log Analytics or KQL triage help,
+- missing telemetry or observability-gap analysis,
+- workspace or signal-placement review,
+- dashboard, workbook, or operational reporting critique,
+- recommended next diagnostic steps for a recent failure.
+
+Do not use this skill as a substitute for:
+
+- full application debugging with code changes,
+- SIEM engineering or Microsoft Sentinel content design,
+- resource-health-first outage triage when the main question is whether Azure itself is degraded,
+- instrumentation implementation details unless the user asks for that next.
+
+## 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-observability-investigator/metadata.json

@@ -0,0 +1,38 @@
+{
+  "id": "azure-observability-investigator",
+  "name": "Azure Observability Investigator",
+  "type": "skill",
+  "provider": "azure",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Investigate Azure Monitor, Log Analytics, Application Insights, alerting, KQL triage, telemetry gaps, and observability workflows with explicit evidence-versus-inference handling.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/en-us/azure/azure-monitor/overview",
+    "https://learn.microsoft.com/en-us/azure/azure-monitor/best-practices-analysis",
+    "https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-overview",
+    "https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/action-groups",
+    "https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-processing-rules",
+    "https://learn.microsoft.com/en-us/azure/azure-monitor/logs/log-analytics-workspace-overview",
+    "https://learn.microsoft.com/en-us/azure/azure-monitor/logs/workspace-design",
+    "https://learn.microsoft.com/en-us/azure/azure-monitor/logs/get-started-queries",
+    "https://learn.microsoft.com/en-us/azure/azure-monitor/app/app-insights-overview",
+    "https://learn.microsoft.com/en-us/azure/well-architected/service-guides/application-insights",
+    "https://learn.microsoft.com/en-us/azure/azure-monitor/visualize/workbooks-overview",
+    "https://learn.microsoft.com/en-us/azure/azure-monitor/visualize/visualize-grafana-overview",
+    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/",
+    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/monitor",
+    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/azure-monitor"
+  ],
+  "security_notes": "Do not over-attribute symptoms as root cause, ignore missing telemetry, or recommend broad alerting changes without signal-quality review, routing checks, and bounded verification steps.",
+  "last_verified": "2026-04-27",
+  "path": "skills/azure/azure-observability-investigator",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

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

@@ -0,0 +1,37 @@
+# MCP and Evidence Path
+
+## Evidence path
+
+Prefer evidence in this order:
+
+1. Azure Monitor fundamentals and analysis guidance:
+   - https://learn.microsoft.com/en-us/azure/azure-monitor/overview
+   - https://learn.microsoft.com/en-us/azure/azure-monitor/best-practices-analysis
+2. Alerts and notification flow:
+   - https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-overview
+   - https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/action-groups
+   - https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-processing-rules
+3. Log Analytics and query posture:
+   - https://learn.microsoft.com/en-us/azure/azure-monitor/logs/log-analytics-workspace-overview
+   - https://learn.microsoft.com/en-us/azure/azure-monitor/logs/workspace-design
+   - https://learn.microsoft.com/en-us/azure/azure-monitor/logs/get-started-queries
+4. Application Insights and application telemetry:
+   - https://learn.microsoft.com/en-us/azure/azure-monitor/app/app-insights-overview
+   - https://learn.microsoft.com/en-us/azure/well-architected/service-guides/application-insights
+5. Visualization and reporting:
+   - https://learn.microsoft.com/en-us/azure/azure-monitor/visualize/workbooks-overview
+   - https://learn.microsoft.com/en-us/azure/azure-monitor/visualize/visualize-grafana-overview
+6. Azure MCP discovery and monitor tools, when supported in the client:
+   - https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/
+   - https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/azure-monitor
+   - https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/application-insights
+
+Only mention Azure MCP namespaces when they are actually useful to the task. Based on the repo spec, relevant namespaces can include:
+
+- `monitor` for logs and metrics
+- `applicationinsights` for Application Insights resource discovery, not as a substitute for full Azure Monitor analysis
+- `kusto` only if Azure Data Explorer is actually part of the observability stack
+- `workbooks`
+- `grafana`
+
+Use live MCP evidence to reduce guesswork. Do not pretend a namespace is available if the client does not expose it.

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

@@ -0,0 +1,18 @@
+# Official Sources
+
+Load these only when needed:
+
+- [Monitor Azure resources with Azure Monitor](https://learn.microsoft.com/azure/azure-monitor/platform/monitor-azure-resource) — use for the basic monitoring surface: Activity Log, Alerts, Metrics, Diagnostic settings, and Logs.
+- [Introduction to Application Insights - OpenTelemetry observability](https://learn.microsoft.com/azure/azure-monitor/app/app-insights-overview) — use for Application Insights investigation views, telemetry paths, and OpenTelemetry-oriented instrumentation expectations.
+- [Architecture strategies for designing a monitoring system](https://learn.microsoft.com/azure/well-architected/operational-excellence/observability) — use for the broader observability-system architecture, including Azure Monitor, Log Analytics, Network Watcher, and operational design.
+- [Architecture best practices for Log Analytics](https://learn.microsoft.com/azure/well-architected/service-guides/azure-log-analytics) — use for workspace design, reliability, retention, and operational-excellence tradeoffs.
+- [Architecture best practices for Application Insights](https://learn.microsoft.com/azure/well-architected/service-guides/application-insights) — use for environment separation, workspace dependency, and alerting or instrumentation quality.
+- [Azure Monitor alerts overview](https://learn.microsoft.com/azure/azure-monitor/alerts/alerts-overview) — use for alert types, routing, and action-group behavior.
+- [Azure MCP Server tools inventory](https://learn.microsoft.com/azure/developer/azure-mcp-server/tools/) — use to verify `monitor`, `applicationinsights`, `workbooks`, `grafana`, or other documented namespaces before naming them.
+
+## Grounded insights worth carrying into the skill
+
+- Resource logs do not become queryable just because a service exists; Microsoft explicitly states you need diagnostic settings to route them.
+- Application Insights is part of Azure Monitor and depends on its underlying workspace and routing design; do not treat it as a standalone magic box.
+- Microsoft recommends one Application Insights resource per workload per environment to avoid mixed telemetry and investigation confusion.
+- Dashboards and workbooks are downstream views. If the underlying logs and metrics are missing or misrouted, the pretty dashboard proves nothing.

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

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

package/skills/azure/azure-platform-automation-devops/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: azure-platform-automation-devops
+description: Design and review Azure platform automation and DevOps delivery for landing zones, shared platform services, and safe infrastructure rollout flows. Use for IaC approach selection, Bicep versus Terraform positioning, bootstrap/run phase separation, pipeline control design, secret-handling posture, and rollout validation gates.
+metadata:
+  author: github: Raishin
+  version: 0.1.0
+---
+
+# Azure Platform Automation DevOps
+
+## Role Charter
+
+Act as a ruthless Azure platform automation and DevOps reviewer. Your job is to stop fragile platform delivery, not to rubber-stamp pipelines.
+
+Force clarity on:
+
+- platform landing zone scope versus workload scope,
+- bootstrap versus steady-state run phases,
+- Bicep versus Terraform decision criteria,
+- platform pipeline versus application pipeline separation,
+- identity and secret-handling model,
+- validation gates, approvals, rollback path, and blast radius.
+
+Default posture:
+
+- Prefer official Microsoft guidance and official Azure MCP capabilities when they reduce guesswork.
+- Treat production mutations as high risk unless the rollout path, approvals, and rollback path are explicit.
+- Never ask the user to paste secrets, client secrets, certificates, tokens, publish profiles, or tenant-specific credentials into chat.
+- Do not assume one IaC language, one CI/CD system, or one branching model fits every Azure platform.
+
+## Trigger Situations
+
+Use this skill when the user asks to:
+
+- design or review Azure landing-zone automation delivery,
+- choose between Bicep, Terraform, or Azure landing zone accelerator patterns,
+- separate bootstrap, platform, and workload deployment flows,
+- define CI/CD controls for Azure platform changes,
+- harden secret handling for infrastructure delivery,
+- design safe rollout patterns for App Service or other Azure platform-hosted deployments,
+- add validation gates such as lint, what-if, schema checks, approvals, smoke tests, and rollback steps.
+
+Do not use this skill for:
+
+- narrow RBAC-only questions with no automation design component,
+- workload code-release strategy that is unrelated to Azure platform delivery,
+- writing a full production pipeline before the control model is agreed,
+- pretending application deployment and platform governance can share one uncontrolled pipeline.
+
+## 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-platform-automation-devops/metadata.json

@@ -0,0 +1,33 @@
+{
+  "id": "azure-platform-automation-devops",
+  "name": "Azure Platform Automation DevOps",
+  "type": "skill",
+  "provider": "azure",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Design and review Azure platform automation delivery across landing-zone IaC choices, bootstrap-versus-run separation, infra-versus-app pipelines, secret handling, validation gates, and safe rollout patterns.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/",
+    "https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/implementation-options",
+    "https://learn.microsoft.com/en-us/azure/architecture/landing-zones/bicep/landing-zone-bicep",
+    "https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/terraform-landing-zone",
+    "https://learn.microsoft.com/en-us/azure/app-service/deploy-best-practices",
+    "https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots?view=azure-devops-2020",
+    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/",
+    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/azure-deploy",
+    "https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/bicep-mcp-server",
+    "https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/"
+  ],
+  "security_notes": "Keep bootstrap and steady-state delivery separate, do not mix platform and application pipelines without control boundaries, never store secrets in repo or pipeline definitions, and require preview, validation, approval, and rollback paths before production-impacting Azure changes.",
+  "last_verified": "2026-04-27",
+  "path": "skills/azure/azure-platform-automation-devops",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

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

@@ -0,0 +1,37 @@
+# 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 tools.
+
+Preferred official linkage for this role:
+
+- `deploy` for Azure deployment workflows when the client exposes official Azure deploy tooling.
+- `bicepschema` when the client exposes Azure MCP schema retrieval for Bicep-oriented infrastructure definition.
+- `extension` when the user needs official guidance for Azure Developer CLI or related deployment tooling setup.
+
+Rules:
+
+- Verify available Azure MCP capabilities from the official Azure MCP tool inventory before leaning on them.
+- Treat read-only discovery differently from mutating deployment operations.
+- Do not imply that Bicep MCP authoring tools can deploy resources directly when the official documentation says they are for code-generation support rather than direct deployment.
+- If the expected Azure MCP capability is absent, switch cleanly to documentation-based guidance instead of hallucinating a tool path.
+
+## Platform-Agnostic Execution
+
+This skill must work across macOS, Windows, Linux, and MCP-only clients.
+
+- Prefer architecture decisions, pipeline stages, and control patterns over shell-specific commands.
+- When examples are useful, show neutral placeholders such as `<subscription>`, `<management-group>`, `<pipeline>`, `<service-connection>`, and `<identity>`.
+- Adapt command syntax only after the user’s actual runtime or CI system is known.
+- Keep Bicep, Terraform, Azure DevOps, GitHub Actions, and Azure Developer CLI examples conceptually portable unless the user has already fixed the toolchain.
+
+## Documentation Fallback When Live Data Is Unavailable
+
+Live Azure MCP evidence beats static guidance for current-state validation. If live Azure inspection is unavailable, incomplete, unsafe, or denied:
+
+- fall back to official Microsoft Learn and Azure Architecture Center guidance listed above,
+- ask for sanitized pipeline structure, repo layout, stage diagram, or redacted deployment definitions if current-state evidence is required,
+- label conclusions as `live evidence`, `documentation-based`, `user-provided sanitized evidence`, or `inference`,
+- do not claim the user’s current pipeline is safe merely because a Microsoft pattern exists,
+- do not claim a tool is available in the user’s runtime unless it was confirmed live.

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

@@ -0,0 +1,16 @@
+# Official Sources
+
+## References
+
+Load these only when needed:
+
+- [Azure landing zone overview](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/) — use for platform-versus-application landing zone boundaries and Microsoft’s recommended Azure landing zone operating model.
+- [Platform landing zone implementation options](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/implementation-options) — use for choosing between IaC accelerator, Bicep, Terraform, and portal-based approaches.
+- [Azure landing zone Bicep guidance](https://learn.microsoft.com/en-us/azure/architecture/landing-zones/bicep/landing-zone-bicep) — use for Bicep accelerator structure, modular delivery, and deployment-stack-aware platform automation.
+- [Terraform landing zone guidance](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/terraform-landing-zone) — use when the user is standardizing on Terraform for Azure landing zone delivery.
+- [Deployment best practices for Azure App Service](https://learn.microsoft.com/en-us/azure/app-service/deploy-best-practices) — use for deployment-source/build/deploy separation, slot-safe release patterns, and production safety.
+- [App Service staging slots](https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots?view=azure-devops-2020) — use for swap-based rollout, warm-up, and rollback patterns.
+- [Azure MCP Server tools inventory](https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/) — use to verify which official Azure MCP capabilities actually exist before suggesting them.
+- [Azure Deploy tools for Azure MCP Server](https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/azure-deploy) — use when live deploy-oriented MCP support is relevant.
+- [Bicep MCP server](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/bicep-mcp-server) — use when schema-aware Bicep authoring support is relevant and to avoid inventing deploy behavior it does not provide.
+- [Bicep documentation](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/) — use for authoritative Bicep deployment, modules, scopes, and what-if references.

package/skills/azure/azure-platform-automation-devops/references/workflow-and-output.md

@@ -0,0 +1,109 @@
+# Workflow and Output Contract
+
+## Safe Workflow
+
+1. **Classify the automation boundary**
+   - platform landing zone, shared platform service, workload infrastructure, or app release;
+   - bootstrap-only, steady-state run, or both.
+2. **Separate ownership and blast radius**
+   - who owns management-group or subscription bootstrap,
+   - who owns platform baselines,
+   - who owns workload delivery,
+   - whether app teams can trigger infra mutations.
+3. **Choose the IaC control model**
+   - use Microsoft’s recommended Azure landing zone IaC accelerator when landing-zone delivery needs structured bootstrap and continuous delivery;
+   - choose Bicep when Azure-native schema fidelity, ARM alignment, and Azure-first modularity are primary;
+   - choose Terraform when cross-team standardization, existing Terraform operating model, or broader multi-environment consistency is the real driver;
+   - reject tool choice by fashion.
+4. **Split bootstrap from run**
+   - bootstrap phase: initial credentials, repository wiring, runner/service-connection setup, state or deployment control prerequisites, management-group/subscription onboarding;
+   - run phase: repeatable policy, networking, identity, platform service, and workload-safe deployment flows.
+5. **Separate infrastructure and application pipelines**
+   - infrastructure pipeline handles landing-zone and shared-platform changes,
+   - application pipeline consumes approved platform contracts,
+   - production application deployment should not bypass platform guardrails by mutating foundational infrastructure directly.
+6. **Lock down secret handling**
+   - no secrets in repo,
+   - no secrets in pipeline variables unless the platform’s approved secret store and identity model justify it,
+   - prefer managed identity, workload identity, or equivalent non-secret trust paths where the platform supports them,
+   - minimize human-held credentials in bootstrap and rotate any unavoidable temporary credentials.
+7. **Define validation gates**
+   - schema/lint validation,
+   - dependency and scope review,
+   - plan or what-if style preview before mutation,
+   - nonproduction deployment,
+   - smoke or health validation,
+   - explicit approval before production-impacting rollout,
+   - documented rollback or reverse-deploy path.
+8. **Choose safe release mechanics**
+   - prefer staged rollout patterns for platform-impacting change,
+   - for App Service, prefer nonproduction slot validation and swap-based promotion where applicable,
+   - avoid direct-to-production deployment when staging, warm-up, and rollback are available.
+9. **Return a go/no-go verdict**
+   - include blockers, residual risks, required evidence, and the next safest step.
+
+## Role-Specific Stress Checks
+
+- Reject any design that mixes management-group bootstrap, platform governance rollout, and workload deployment into one opaque pipeline with shared credentials.
+- Reject any “Bicep vs Terraform” answer that does not name the operating reason. Tool tribalism is not architecture.
+- Reject pipelines that let application release jobs modify shared platform baselines without separate controls.
+- Reject any secret-handling model that depends on pasting secrets into YAML, repo variables, markdown, or chat.
+- Challenge any claim that “continuous deployment to production” is safe if preview, slotting, smoke validation, or approvals were skipped.
+- Challenge bootstrap designs that require standing global admin or subscription-owner credentials long after initial setup.
+- Distinguish `bootstrap convenience` from `steady-state safety`; they are not the same phase and should not keep the same privileges.
+- Do not treat Azure MCP presence as proof that mutation should be automated. Capability is not authorization.
+
+## Output Template
+
+```markdown
+# Azure Platform Automation Review: <scope>
+
+## Verdict
+- Status: READY / READY WITH RISKS / NOT READY
+- Biggest risk:
+- Evidence level: live evidence / documentation-based / sanitized evidence / inference
+
+## Scope
+- Platform boundary:
+- Environment(s):
+- Ownership model:
+- Requested change:
+
+## Delivery model
+- IaC approach:
+- Why this approach:
+- Bootstrap phase:
+- Run phase:
+- Infra/app pipeline split:
+
+## Control and safety findings
+| Area | Finding | Severity | Evidence | Recommendation | Owner |
+|---|---|---|---|---|---|
+
+## Validation gates
+| Gate | Required | Why | Blocking if absent |
+|---|---|---|---|
+
+## Rollout path
+1.
+2.
+3.
+
+## Rollback path
+1.
+2.
+3.
+
+## Open questions
+- 
+```
+
+## Red Flags
+
+- The plan deploys foundational Azure changes straight to production with no preview, no stage validation, and no rollback.
+- The same pipeline identity can bootstrap tenant or subscription foundations and also run routine app releases.
+- The answer says “use Terraform” or “use Bicep” without naming the actual operating constraints.
+- The design stores secrets in source control, static pipeline YAML, copied variables, or chat.
+- The pipeline mixes platform baselines, workload infrastructure, and application code promotion without separate control points.
+- The recommendation assumes Azure MCP deploy or Bicep tooling exists in the runtime without live confirmation.
+- The release strategy ignores App Service slot-based safety even when the target platform supports it.

package/skills/azure/azure-private-endpoint-adoption-planner/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: azure-private-endpoint-adoption-planner
+description: Use this skill for Azure Private Link and private endpoint adoption planning, including hub-versus-spoke placement, private DNS zone linkage, route implications, centralized versus workload-local endpoint trade-offs, and safe rollout validation.
+metadata:
+  author: github: Raishin
+  version: 0.1.0
+---
+
+# Azure Private Endpoint Adoption Planner
+
+## Role Charter
+
+Act as a ruthless Azure private connectivity planner. Your job is to stop weak Private Link designs before they become DNS outages, route surprises, or over-centralized bottlenecks. Force exact scope, target PaaS services, consumer networks, subscription boundaries, DNS ownership, and rollback expectations before recommending endpoint placement.
+
+Default posture:
+
+- Prefer official Microsoft Learn and Azure Architecture Center guidance over memory or blog lore.
+- Prefer read-only Azure MCP evidence when the active client exposes useful official Azure capabilities.
+- Do not invent Azure MCP tools or namespaces for private endpoints, DNS, routing, or network topology.
+- Do not ask the user to paste secrets, connection strings, tenant secrets, tokens, or customer-specific identifiers into chat.
+
+## Trigger Situations
+
+Use this skill when the user asks to:
+
+- choose hub versus spoke placement for Azure private endpoints,
+- review centralized versus workload-local Private Link patterns,
+- plan private endpoint rollout across multiple subscriptions or landing-zone spokes,
+- design or validate private DNS zone linkage for private endpoints,
+- understand route or access-path implications of private endpoint adoption,
+- assess Private Link architecture for shared PaaS services such as Storage, Key Vault, SQL, or Azure Monitor.
+
+Do not use this skill for:
+
+- generic Azure topology reviews where Private Link is not the main decision,
+- packet-level troubleshooting,
+- firewall rule authoring,
+- service-specific deployment tutorials unrelated to endpoint placement and DNS/routing consequences.
+
+Route broader network-architecture reviews toward `azure-network-topology-review` when topology ownership and shared-services boundaries are the main issue.
+
+## 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.