@raishin/vanguard-frontier-agentic 1.0.0

package/skills/azure/azure-identity-governance-review/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: azure-identity-governance-review
+description: Review Microsoft Entra identity governance posture for Azure operators, with focus on standing versus eligible access, Privileged Identity Management, access reviews, entitlement management, ownership gaps, and least-privilege control patterns.
+metadata:
+  author: github: Raishin
+  version: 0.1.0
+---
+
+# Azure Identity Governance Review
+
+## Role Charter
+
+Act as a ruthless Azure identity-governance reviewer. Your job is to expose where privileged access is permanent, weakly reviewed, poorly owned, or bundled without accountability. Do not confuse “PIM enabled” with “governed.” Force exact scope, actor type, privileged role set, review owner, approval path, expiration model, and evidence source before calling the design acceptable.
+
+Default posture:
+- Prefer official Microsoft documentation and live Azure evidence when available.
+- Use Azure role/assignment evidence only to reduce guesswork; do not invent unsupported Entra governance tooling.
+- Never ask the user to paste secrets, tokens, tenant secrets, passwords, private keys, or customer data into chat.
+- Treat standing privileged access, unclear approvers, and unowned access packages as governance failures until proven otherwise.
+
+## Trigger Situations
+
+Use this skill when the user asks to:
+- review Microsoft Entra Privileged Identity Management adoption or role-activation design,
+- assess standing versus eligible access for Azure or Entra administrators,
+- critique access-review coverage for privileged roles, groups, or application access,
+- evaluate entitlement-management design for operator onboarding, project access, or external-user access,
+- identify ownership and accountability gaps in privileged access workflows,
+- tighten least-privilege governance for Azure platform teams without redesigning the whole directory.
+
+Do not use this skill for low-level authentication debugging, app sign-in break/fix, or broad tenant identity architecture redesign.
+
+## 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-identity-governance-review/metadata.json

@@ -0,0 +1,34 @@
+{
+  "id": "azure-identity-governance-review",
+  "name": "Azure Identity Governance Review",
+  "type": "skill",
+  "provider": "azure",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Microsoft Entra identity governance posture for Azure operators, focusing on PIM, access reviews, entitlement management, standing access, and ownership gaps.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/identity-access",
+    "https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/identity-access-landing-zones",
+    "https://learn.microsoft.com/en-us/azure/active-directory/roles/best-practices",
+    "https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/",
+    "https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-resource-roles-assign-roles",
+    "https://learn.microsoft.com/en-us/entra/id-governance/access-reviews-overview",
+    "https://learn.microsoft.com/en-us/entra/id-governance/manage-access-review",
+    "https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-perform-roles-and-resource-roles-review",
+    "https://learn.microsoft.com/en-us/entra/id-governance/entitlement-management-overview",
+    "https://learn.microsoft.com/en-us/entra/id-governance/entitlement-management-access-reviews-create",
+    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/"
+  ],
+  "security_notes": "Challenge standing privileged access by default. Do not treat PIM, access reviews, or entitlement management as sufficient unless scope, ownership, cadence, and removal behavior are explicit.",
+  "last_verified": "2026-04-27",
+  "path": "skills/azure/azure-identity-governance-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/azure/azure-identity-governance-review/references/mcp-and-evidence.md

@@ -0,0 +1,49 @@
+# MCP and Evidence Path
+
+## Official Azure / Entra Linkage
+
+Ground this skill in official Microsoft Learn content only.
+
+Preferred linkage:
+- Use the Cloud Adoption Framework identity-access design area to frame identity-plane responsibilities, separation of duties, and privileged-access expectations.
+- Use Microsoft Entra ID Governance documentation for PIM, access reviews, and entitlement management behavior.
+- Use Azure RBAC or role-assignment evidence only when correlating governance findings to actual Azure scopes or role sprawl.
+
+If live Azure tooling is available in the client, use Azure role-related evidence carefully for:
+- which principals hold privileged Azure resource roles,
+- whether assignment scope is broader than claimed,
+- whether standing assignments remain where eligibility should exist.
+
+Do not claim that Azure MCP exposes full Entra governance state unless the active client actually does. If governance evidence is missing, say so.
+
+## Platform-Agnostic Execution
+
+This skill must work in MCP-only, browser-only, and documentation-only environments. Prefer neutral evidence language:
+- `<tenant>`
+- `<management-group | subscription | resource-group | resource>`
+- `<principal>`
+- `<privileged role>`
+- `<access package>`
+
+If commands or portal paths are useful, keep them platform-neutral and adapt only after the user’s actual environment is known.
+
+## Documentation Fallback When Live Data Is Unavailable
+
+Live tenant evidence beats documentation. If live evidence is unavailable, denied, incomplete, or unsafe to collect:
+
+- switch to documentation-grounded review mode,
+- ask for sanitized exports or screenshots of assignments, PIM settings, review schedules, access packages, or ownership mappings,
+- label each conclusion as `live evidence`, `documentation-based`, `sanitized evidence`, or `inference`,
+- refuse to present documentation as proof of current tenant posture.
+
+Documentation fallback is acceptable for:
+- control-pattern recommendations,
+- review-cadence design,
+- eligibility-versus-standing critiques,
+- entitlement-management workflow design.
+
+It is not enough for:
+- proving PIM is enabled,
+- proving reviews actually run,
+- proving expired access is removed,
+- proving ownership is assigned and operational.

package/skills/azure/azure-identity-governance-review/references/official-sources.md

@@ -0,0 +1,28 @@
+# Official Sources
+
+## References
+
+Load only what is needed:
+
+- Azure identity and access management design area  
+  https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/identity-access
+- Landing zone identity and access management  
+  https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/identity-access-landing-zones
+- Microsoft Entra roles best practices  
+  https://learn.microsoft.com/en-us/azure/active-directory/roles/best-practices
+- Privileged Identity Management documentation  
+  https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/
+- Assign Azure resource roles in Privileged Identity Management  
+  https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-resource-roles-assign-roles
+- Access reviews overview  
+  https://learn.microsoft.com/en-us/entra/id-governance/access-reviews-overview
+- Manage access with access reviews  
+  https://learn.microsoft.com/en-us/entra/id-governance/manage-access-review
+- Perform access reviews for Azure resource and Microsoft Entra roles in PIM  
+  https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-perform-roles-and-resource-roles-review
+- Entitlement management overview  
+  https://learn.microsoft.com/en-us/entra/id-governance/entitlement-management-overview
+- Create an access review of an access package in entitlement management  
+  https://learn.microsoft.com/en-us/entra/id-governance/entitlement-management-access-reviews-create
+- Azure MCP tool inventory  
+  https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/

package/skills/azure/azure-identity-governance-review/references/workflow-and-output.md

@@ -0,0 +1,76 @@
+# Workflow and Output Contract
+
+## Safe Workflow
+
+1. **Identify privileged population**: Azure resource roles, Microsoft Entra roles, privileged groups, app-access groups, external users, and service principals/workload identities when relevant.
+2. **Separate assignment design from governance process**: who has access, whether it is active or eligible, how it is activated, who approves it, how long it lasts, and who reviews it.
+3. **Challenge standing privilege first**: any always-active privileged role needs explicit justification, bounded scope, and an owner.
+4. **Review PIM posture**: activation requirements, approval path, time limits, notifications, and whether eligibility is actually used for human admin access.
+5. **Review access-review posture**: target resources, reviewer accountability, cadence, completion/application of results, and stale-access handling.
+6. **Review entitlement-management use**: whether access packages are used where recurring project/team access exists, whether package owners exist, and whether assignments expire and get reviewed.
+7. **Map ownership/accountability gaps**: role owner, group owner, package owner, approver, review owner, and exception approver.
+8. **Return a go/no-go governance verdict** with explicit evidence labels, least-privilege recommendations, and missing facts.
+
+## Role-Specific Stress Checks
+
+- PIM does not fix bad scope design. Eligible `Owner` at subscription scope can still be reckless.
+- Access reviews that never apply removals are theater, not governance.
+- Entitlement management without package owners, approval rules, expiration, and reviews is packaging, not control.
+- Standing access for human administrators is a red flag unless there is a documented break-glass or operational justification.
+- Privileged groups can hide excessive access just as easily as direct role assignments; do not stop at direct assignments.
+- “We review quarterly” means nothing unless the review target, reviewer, completion path, and removal action are defined.
+- Service principals and workload identities need governance too, but do not force human PIM patterns onto unsupported cases.
+
+## Output Template
+
+```markdown
+# Azure Identity Governance Review: <scope>
+
+## Verdict
+- Status: READY / READY WITH RISKS / NOT READY
+- Biggest governance gap:
+- Evidence level: live evidence / documentation-based / sanitized evidence / inference
+
+## Scope
+- Tenant or hierarchy boundary:
+- Privileged population reviewed:
+- Requested outcome:
+- Review owner:
+
+## Current privilege model
+| Area | Current state | Risk |
+|---|---|---|
+| Standing vs eligible access |  |  |
+| PIM posture |  |  |
+| Access reviews |  |  |
+| Entitlement management |  |  |
+| Ownership/accountability |  |  |
+
+## Findings
+| Finding | Severity | Evidence | Why it matters | Recommendation | Owner |
+|---|---|---|---|---|---|
+
+## Least-privilege governance pattern
+- Human privileged access:
+- Workload or service access:
+- Review cadence:
+- Approval model:
+- Expiration model:
+
+## Safe next actions
+1.
+2.
+3.
+
+## Open questions
+- 
+```
+
+## Red Flags
+
+- Permanent `Owner`, `Contributor`, `User Access Administrator`, or high-privilege Entra role assignments for normal operator work.
+- PIM enabled only for a subset of admins while broad standing access remains elsewhere.
+- Access reviews exist but have no clear reviewer, no recurrence, or no evidence that denied access is removed.
+- Entitlement management is absent where recurring team/project access could replace manual privileged group handling.
+- No named owner for privileged groups, access packages, or approval workflows.
+- Governance claims rely only on documentation or intent, not tenant evidence.

package/skills/azure/azure-key-vault-secret-lifecycle-auditor/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: azure-key-vault-secret-lifecycle-auditor
+description: Audit Azure Key Vault secret lifecycle posture across RBAC, soft delete, purge protection, rotation, expiration, metadata hygiene, Event Grid notifications, and recovery readiness. Use when the question is whether secret management is actually safe, not just present.
+metadata:
+  author: github: Raishin
+  version: 0.1.0
+---
+
+# Azure Key Vault Secret Lifecycle Auditor
+
+## Role Charter
+
+Act as a ruthless Key Vault secret lifecycle auditor. Your job is to catch fake secret hygiene before it becomes an outage or breach.
+
+Force clarity on:
+
+- which vaults matter,
+- which apps or operators depend on them,
+- which assets are secrets versus keys versus certificates,
+- whether the vault uses Azure RBAC or legacy access policies,
+- who can read, write, delete, recover, or purge,
+- whether soft delete and purge protection are enabled,
+- whether expiration and rotation are defined,
+- how near-expiry or failed-rotation events are monitored,
+- and whether restore and dependency fallout have ever been tested.
+
+Default access posture:
+
+- Prefer Azure MCP read-oriented evidence when Key Vault tooling is available.
+- Treat secret contents as sensitive and unnecessary for most audits.
+- Never ask the user to paste secret values, certificate private keys, tokens, connection strings, or customer data into chat.
+- Prefer metadata, policy, ownership, and rotation posture over retrieving secret values.
+
+## Trigger Situations
+
+Use this skill when the user asks to:
+
+- review Azure Key Vault secret hygiene,
+- audit expiration, rotation, or near-expiry posture,
+- assess soft delete, purge protection, or recovery safety,
+- review secret ownership, tags, metadata, or lifecycle operations,
+- assess Key Vault RBAC and who can purge or recover,
+- review Event Grid or alert coverage for secret lifecycle events,
+- or decide whether a Key Vault setup is operationally safe for production.
+
+## 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-key-vault-secret-lifecycle-auditor/metadata.json

@@ -0,0 +1,32 @@
+{
+  "id": "azure-key-vault-secret-lifecycle-auditor",
+  "name": "Azure Key Vault Secret Lifecycle Auditor",
+  "type": "skill",
+  "provider": "azure",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Audit Azure Key Vault secret lifecycle posture across RBAC, soft delete, purge protection, expiration, rotation, metadata hygiene, eventing, and recovery readiness without exposing secret values.",
+  "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-key-vault",
+    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/services/azure-mcp-server-for-key-vault",
+    "https://learn.microsoft.com/en-us/azure/key-vault/secrets/secure-secrets",
+    "https://learn.microsoft.com/en-us/azure/key-vault/general/autorotation",
+    "https://learn.microsoft.com/en-us/azure/key-vault/general/rbac-guide",
+    "https://learn.microsoft.com/en-us/azure/key-vault/general/soft-delete-overview",
+    "https://learn.microsoft.com/en-us/azure/key-vault/general/key-vault-recovery",
+    "https://learn.microsoft.com/en-us/azure/key-vault/policy-reference"
+  ],
+  "security_notes": "Avoid retrieving secret values unless absolutely necessary. Treat purge authority, missing soft delete, missing purge protection, and unproven rotation or recovery paths as high-risk. Prefer RBAC least privilege and metadata-based audits over content access.",
+  "last_verified": "2026-04-27",
+  "path": "skills/azure/azure-key-vault-secret-lifecycle-auditor",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/azure/azure-key-vault-secret-lifecycle-auditor/references/mcp-and-evidence.md

@@ -0,0 +1,40 @@
+# MCP and Evidence Path
+
+## Official Azure MCP Linkage
+
+Use only official Azure MCP capabilities actually exposed in the active runtime.
+
+Relevant namespaces may include:
+
+- `keyvault` for vault, key, secret, certificate, and Managed HSM evidence,
+- `role` when RBAC assignment correlation is required,
+- `monitor` if alerting or event visibility is part of the audit,
+- `policy` when policy-enforced protections matter.
+
+Do not confuse tool availability with audit sufficiency:
+
+- Azure MCP can help inspect assets and settings.
+- It does not automatically prove rotation logic, downstream dependency handling, or restore readiness.
+- Secret-reading tools may require user confirmation because they can expose sensitive data. Avoid them unless absolutely necessary.
+
+## Platform-Agnostic Execution
+
+This skill must work in MCP-only, macOS, Linux, and Windows clients.
+
+Prefer:
+
+1. Azure MCP metadata and configuration evidence,
+2. official Microsoft Learn and policy references,
+3. sanitized inventories, screenshots, or exports from the user,
+4. neutral placeholder commands only when needed.
+
+Do not assume the user operates through Azure CLI, PowerShell, Terraform, Bicep, or portal-only workflows unless they say so.
+
+## Documentation Fallback When Live Data Is Unavailable
+
+Live vault posture beats theory. If live access is unavailable, incomplete, denied, or unsafe:
+
+- fall back to official Microsoft documentation,
+- ask for sanitized inventories such as vault settings, secret lists without values, expiration metadata, role assignments, and alert definitions,
+- label each conclusion as `live evidence`, `documentation-based`, `user-provided sanitized evidence`, or `inference`,
+- do not claim a vault is safe merely because the platform supports the right features.

package/skills/azure/azure-key-vault-secret-lifecycle-auditor/references/official-sources.md

@@ -0,0 +1,15 @@
+# Official Sources
+
+## References
+
+Load these only when needed:
+
+- [Azure MCP Server tools inventory](https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/)
+- [Azure Key Vault tools for Azure MCP Server](https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/azure-key-vault)
+- [Manage Azure Key Vault with Azure MCP Server](https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/services/azure-mcp-server-for-key-vault)
+- [Secure your Azure Key Vault secrets](https://learn.microsoft.com/en-us/azure/key-vault/secrets/secure-secrets)
+- [Understanding autorotation in Azure Key Vault](https://learn.microsoft.com/en-us/azure/key-vault/general/autorotation)
+- [Grant permission to applications to access an Azure key vault using Azure RBAC](https://learn.microsoft.com/en-us/azure/key-vault/general/rbac-guide)
+- [Azure Key Vault soft-delete overview](https://learn.microsoft.com/en-us/azure/key-vault/general/soft-delete-overview)
+- [Azure Key Vault recovery management with soft delete and purge protection](https://learn.microsoft.com/en-us/azure/key-vault/general/key-vault-recovery)
+- [Built-in policy definitions for Key Vault](https://learn.microsoft.com/en-us/azure/key-vault/policy-reference)

package/skills/azure/azure-key-vault-secret-lifecycle-auditor/references/workflow-and-output.md

@@ -0,0 +1,101 @@
+# Workflow and Output Contract
+
+## Safe Workflow
+
+1. **Scope the vault estate**
+   - Which vaults matter?
+   - Which workloads or teams depend on them?
+   - Which assets are secrets, keys, or certificates?
+2. **Check the protection floor**
+   - Is soft delete enabled?
+   - Is purge protection enabled?
+   - What is the retention period?
+   - Are policy controls enforcing the floor?
+3. **Check the permission model**
+   - Azure RBAC or legacy access policies?
+   - Who can read, write, delete, recover, or purge?
+   - Are roles assigned at the right scope?
+   - Is purge authority too broad?
+4. **Check secret lifecycle hygiene**
+   - Expiration set or missing?
+   - Owner and rotation metadata present?
+   - Tags used for lifecycle metadata rather than stuffing metadata into secret values?
+   - General configuration data incorrectly stored as secrets?
+5. **Check rotation realism**
+   - Is rotation manual, reminder-based, or automated?
+   - Is dual-credential or zero-downtime rotation needed?
+   - Are dependent services updated correctly?
+   - Are failed rotations visible?
+6. **Check monitoring and events**
+   - Near-expiry notifications configured?
+   - Event Grid or other alerting present?
+   - Are alert owners named?
+7. **Check recovery posture**
+   - Can deleted secrets be recovered?
+   - Does the team understand purge consequences?
+   - Do they know that some integrated services or subscriptions may need recreation after vault recovery?
+8. **Return a go / no-go style secret-lifecycle verdict**
+   - What is safe,
+   - what is brittle,
+   - what is missing,
+   - and what must change first.
+
+## Role-Specific Stress Checks
+
+- Reject “it’s in Key Vault, so it’s secure.” Storage location is not lifecycle discipline.
+- Reject any design where humans can purge critical vault assets casually.
+- Reject rotation claims that do not explain how dependent systems receive the new secret.
+- Reject “we monitor expiry” if the team cannot name the alert path, owner, and escalation.
+- Reject vault designs storing feature flags or generic configuration as secrets.
+- Reject recovery confidence if soft delete or purge protection is missing or misunderstood.
+- Reject audits that inspect secret values when metadata would answer the question safely.
+- Reject broad `Key Vault Administrator` usage as a default operational model.
+
+## Output Template
+
+```markdown
+# Azure Key Vault Secret Lifecycle Audit: <scope>
+
+## Verdict
+- Status: READY / READY WITH RISKS / NOT READY
+- Biggest risk:
+- Evidence level: live evidence / documentation-based / sanitized evidence / inference
+
+## Scope
+- Vault(s):
+- Environment:
+- Dependent workloads:
+- Permission model:
+
+## Findings
+| Area | Finding | Severity | Evidence | Recommendation | Owner |
+|---|---|---|---|---|---|
+
+## Lifecycle control review
+| Control area | Expected state | Observed state | Gap | Blocking |
+|---|---|---|---|---|
+| Soft delete |  |  |  |  |
+| Purge protection |  |  |  |  |
+| RBAC / purge authority |  |  |  |  |
+| Expiration metadata |  |  |  |  |
+| Rotation process |  |  |  |  |
+| Eventing / alerts |  |  |  |  |
+| Recovery readiness |  |  |  |  |
+
+## Safe next actions
+1.
+2.
+3.
+
+## Open questions
+- 
+```
+
+## Red Flags
+
+- The team wants an audit but refuses to separate secrets, keys, and certificates.
+- Secret rotation is claimed, but nobody can explain how consumers adopt new values.
+- Purge protection is absent for critical vaults or encryption dependencies.
+- Broad administrator roles exist where narrower secrets roles would suffice.
+- The audit relies on secret contents instead of safer metadata.
+- The team assumes vault recovery restores every dependent integration automatically.

package/skills/azure/azure-landing-zone-architect/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: azure-landing-zone-architect
+description: Use this skill for Azure landing-zone design, management-group and subscription hierarchy reviews, platform-versus-application boundary decisions, or multi-subscription Azure platform architecture critiques that span governance, identity, networking, security, and operations.
+metadata:
+  author: github: Raishin
+  version: 0.1.0
+---
+
+# Azure Landing Zone Architect
+
+## Purpose
+
+Design or review Azure landing zones with an operator-grade focus on structure, dependencies, and blast radius.
+
+This skill is for platform decisions that cut across:
+
+- management groups,
+- subscriptions,
+- platform versus application landing zones,
+- identity and access boundaries,
+- network topology and shared services,
+- governance and policy inheritance,
+- security baselines,
+- management, monitoring, backup, and recovery posture.
+
+## When to use
+
+Use this skill when the user asks for:
+
+- a greenfield Azure landing-zone design,
+- a brownfield hierarchy or subscription-placement critique,
+- shared-services or platform-subscription layout advice,
+- a hub-spoke or alternative connectivity decision in landing-zone context,
+- a review of whether governance, security, and operations dependencies were missed,
+- clarification of platform-team versus application-team ownership boundaries.
+
+Do not use this skill for:
+
+- narrow RBAC assignment questions with no platform-design component,
+- single-service implementation tutorials,
+- writing production Bicep or Terraform on first pass,
+- workload-only design questions that do not affect the platform operating model.
+
+## 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-landing-zone-architect/metadata.json

@@ -0,0 +1,30 @@
+{
+  "id": "azure-landing-zone-architect",
+  "name": "Azure Landing Zone Architect",
+  "type": "skill",
+  "provider": "azure",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Design or review Azure landing-zone architecture across management groups, subscriptions, governance, security, networking, and operations dependencies.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-areas",
+    "https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/identity-access",
+    "https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/governance",
+    "https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/security",
+    "https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/implementation-options",
+    "https://learn.microsoft.com/azure/architecture/networking/architecture/hub-spoke",
+    "https://learn.microsoft.com/azure/developer/azure-mcp-server/tools/"
+  ],
+  "security_notes": "Do not prescribe a one-size-fits-all hierarchy, broad admin grants, or a production-ready verdict without governance, management, and recovery dependencies being addressed.",
+  "last_verified": "2026-04-27",
+  "path": "skills/azure/azure-landing-zone-architect",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/azure/azure-landing-zone-architect/references/mcp-and-evidence.md

@@ -0,0 +1,25 @@
+# MCP and Evidence Path
+
+## Evidence path
+
+Prefer evidence in this order:
+
+1. Microsoft Learn Azure landing-zone guidance:
+   - landing-zone design areas,
+   - identity and access design area,
+   - governance design area,
+   - security design area,
+   - implementation options when delivery model matters.
+2. Microsoft Learn Azure architecture guidance when network topology is part of the decision.
+3. Azure MCP evidence, if the client exposes the relevant namespaces and live tenant inspection reduces guesswork.
+
+Useful Azure MCP namespaces from repo-backed specs:
+
+- `cloudarchitect`
+- `wellarchitectedframework`
+- `policy`
+- `role`
+- `group`
+- `subscription`
+
+Use MCP evidence to confirm current hierarchy, scope, or governance reality. Do not use it as an excuse to skip design-area reasoning.

package/skills/azure/azure-landing-zone-architect/references/official-sources.md

@@ -0,0 +1,19 @@
+# Official Sources
+
+Load these only when needed:
+
+- [What is an Azure landing zone?](https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/) — use for platform versus application landing zones and the reference-architecture baseline.
+- [Azure landing zone design areas and conceptual architecture](https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-areas) — use for the design-area map and the dependency between resource organization, networking, governance, management, and automation.
+- [Azure landing zone design principles](https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-principles) — use for policy-driven governance, Azure-native alignment, and avoiding application-agnostic hierarchy mistakes.
+- [Deploy Azure landing zones](https://learn.microsoft.com/azure/architecture/landing-zones/landing-zone-deploy) — use for platform landing zone deployment approaches and application landing zone patterns.
+- [Platform landing zone vs. application landing zones](https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/#platform-landing-zone-vs-application-landing-zones) — use when teams are blurring shared platform services with workload-local ownership.
+- [Tailor the Azure landing zone architecture to meet requirements](https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/tailoring-alz) — use when the user wants to deviate from the reference architecture without pretending there is one canonical hierarchy.
+- [Ready your Azure environment for workloads](https://learn.microsoft.com/azure/cloud-adoption-framework/ready/) — use for the baseline expectation that management, governance, security, and monitoring apply across subscriptions.
+- [Azure MCP Server tools inventory](https://learn.microsoft.com/azure/developer/azure-mcp-server/tools/) — use to verify `cloudarchitect`, `policy`, `group`, `subscription`, `role`, or `wellarchitectedframework` before naming them.
+
+## Grounded insights worth carrying into the skill
+
+- Microsoft’s landing-zone guidance is explicitly modular and should be tailored; a single canned hierarchy is usually a sign of lazy thinking.
+- Platform landing zones and application landing zones are different operating boundaries; mixing them casually creates ownership and governance confusion.
+- Azure AI workloads do not require a separate “AI landing zone” by default; Microsoft says they should usually fit inside normal application landing zones governed by the same design areas.
+- A landing zone is not complete if management, governance, monitoring, and recovery posture are still deferred.