@raishin/vanguard-frontier-agentic 1.0.0

package/skills/azure/azure-entra-id-specialist/metadata.json

@@ -0,0 +1,33 @@
+{
+  "id": "azure-entra-id-specialist",
+  "name": "Azure Entra ID Specialist",
+  "version": "0.1.0",
+  "type": "skill",
+  "provider": "azure",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review and guide Microsoft Entra ID tenant posture across conditional access, authentication methods, MFA and SSPR registration, identity protection, workload identities, app registrations, external identities, governance boundaries, and least-privilege identity operations with explicit evidence-versus-inference handling.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/overview",
+    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/concepts",
+    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/",
+    "https://learn.microsoft.com/en-us/entra/fundamentals/what-is-entra",
+    "https://learn.microsoft.com/en-us/entra/id-governance/identity-governance-overview",
+    "https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure",
+    "https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-all-users-security-info-registration",
+    "https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-users-groups",
+    "https://learn.microsoft.com/en-us/entra/workload-id/workload-identities-overview",
+    "https://learn.microsoft.com/en-us/entra/id-protection/concept-workload-identity-risk"
+  ],
+  "security_notes": "Do not recommend broad exclusions, unsafe break-glass patterns, blanket MFA bypasses, overprivileged app registrations, or risky Conditional Access changes without scoping blast radius, role ownership, and recovery paths.",
+  "last_verified": "2026-04-28",
+  "path": "skills/azure/azure-entra-id-specialist",
+  "author": "github: Raishin"
+}

package/skills/azure/azure-entra-id-specialist/references/adjacent-service-expansion.md

@@ -0,0 +1,113 @@
+# Adjacent Microsoft service expansion
+
+Use this reference only when the user asks about a Microsoft service that is related to Entra identity posture but wasn't explicitly called out in the main skill text.
+
+## Rule
+
+Do not freeze the role to the currently named services.
+
+When the user mentions another Microsoft service, first determine whether the real question is about:
+
+1. **identity plane**
+2. **licensing / entitlement**
+3. **service-specific policy behavior**
+4. **cross-service integration**
+
+Then consult the official docs before concluding.
+
+## Learning-and-evolution workflow
+
+1. Identify the service name exactly.
+2. Decide whether the service affects:
+   - workforce identities
+   - external identities
+   - workload identities
+   - app registrations / enterprise apps
+   - Conditional Access / policy enforcement
+   - licensing or bundle entitlement
+3. Check the official Microsoft docs for that service family.
+4. Distinguish:
+   - “shares the same Entra tenant”
+   - “uses the same sign-in plane”
+   - “requires additional service licensing”
+   - “has separate capacity / SKU / billing requirements”
+5. Answer with explicit uncertainty if the tenant’s purchased licenses are unknown.
+
+## High-value adjacent examples
+
+### Microsoft 365
+
+Use when the user asks whether a Microsoft 365 bundle covers Entra controls.
+
+Typical checks:
+- does the bundle include Entra ID P1?
+- does it include Entra ID P2?
+- does it merely include Entra Free?
+- does it interact with Conditional Access or ID Protection?
+
+### Microsoft Fabric / Power BI
+
+Use when the user assumes tenant presence equals capacity rights or viewer rights.
+
+Typical checks:
+- capacity vs per-user licensing
+- workspace type / SKU implications
+- Entra tenant relationship versus Fabric usage rights
+
+### Microsoft Intune
+
+Use when Conditional Access and device state are being conflated.
+
+Typical checks:
+- whether device compliance assumptions depend on Intune licensing
+- whether the user is asking about identity policy or device-management policy
+
+### Microsoft Defender / Purview
+
+Use when the user assumes Entra premium plans automatically include all risk and compliance integrations.
+
+Typical checks:
+- whether a specific signal comes from Defender
+- whether the feature depends on a Defender or Purview add-on rather than plain Entra
+- whether ID Protection quality depends on separately licensed Defender signals
+
+### Microsoft Entra External ID
+
+Use when B2B/B2C/guest or customer identity questions appear.
+
+Typical checks:
+- MAU-based or product-specific entitlements
+- whether the question is workforce tenant access or customer identity
+
+### Microsoft Entra Verified ID
+
+Use when verifiable credentials or face-check style questions appear.
+
+Typical checks:
+- what is included in base Entra versus premium suite/add-on capabilities
+
+### Microsoft Entra Workload ID
+
+Use when service principals, app identities, GitHub Actions, or nonhuman access are involved.
+
+Typical checks:
+- workload identity premium features
+- Conditional Access for workload identities
+- ID Protection for workload identities
+
+### Microsoft Entra Agent ID / AI agents
+
+Use when the user is building or governing AI agents and assumes agent identities are just normal users or just normal service principals.
+
+Typical checks:
+- whether the question is about agent identities, agent users, or agent blueprints
+- whether Conditional Access for Agent ID is preview-only or separately constrained
+- whether agent risk depends on ID Protection for agents
+- whether blueprint inheritance or custom security attributes change the authorization model
+- whether the tenant is mixing agent governance questions with ordinary workload identity questions
+
+## Safe response pattern
+
+- “This service uses the same Entra tenant, but that does not by itself prove the needed feature rights.”
+- “This looks like a cross-service licensing question, so I’m grounding it against the service’s official documentation before concluding.”
+- “I can confirm the documented prerequisite, but I cannot confirm your tenant owns that license from the evidence provided.”

package/skills/azure/azure-entra-id-specialist/references/licensing-and-service-entitlements.md

@@ -0,0 +1,123 @@
+# Licensing and service entitlements
+
+Use this reference only when the answer depends on whether the tenant is actually entitled to a Microsoft feature.
+
+## Rule
+
+Do not treat feature existence as proof of tenant entitlement.
+
+When the user asks whether a control **can** be used, whether it is **included**, or whether one Microsoft product **covers** another, separate:
+
+1. **technical capability**
+2. **licensing prerequisite**
+3. **service-specific entitlement**
+
+If licensing is unknown, say so explicitly.
+
+## High-value examples
+
+### Example 1: Microsoft Azure / Entra baseline
+
+- Microsoft Entra ID **Free** is included with Microsoft cloud subscriptions such as **Microsoft Azure** and **Microsoft 365**.
+- That does **not** mean P1, P2, Identity Governance, or ID Protection are included.
+
+Use this when the user assumes “we have Azure, so we have the Entra premium features.”
+
+### Example 2: Conditional Access
+
+- Microsoft documents **Conditional Access** as requiring **Microsoft Entra ID P1**.
+- Microsoft also documents that **Microsoft 365 Business Premium** customers can use Conditional Access features.
+- Risk-based policies require **Microsoft Entra ID Protection**, which is a **P2** feature.
+
+Use this when the user assumes all Conditional Access features are equivalent.
+
+### Example 3: PIM and identity governance
+
+- Microsoft documents **Privileged Identity Management (PIM)** as a **P2 / Identity Governance / Entra Suite** capability.
+- Identity Governance capabilities may have more specific licensing requirements than base Entra plans, including scenarios where “who can request” or “who is reviewed” affects licensing scope.
+
+Use this when the user assumes PIM is included because they already have P1.
+
+### Example 4: Workload identities
+
+- Microsoft documents **Microsoft Entra Workload ID** separately.
+- Some workload identity protections, such as risk reporting and Conditional Access for workload identities, have their own premium licensing constraints.
+
+Use this when the user assumes service principals inherit all user-based Entra licensing rights.
+
+### Example 5: Microsoft 365 bundle examples
+
+- Microsoft documents **Entra ID P1** as included in **Microsoft 365 E3**, **F1**, **F3**, and **Business Premium**.
+- Microsoft documents **Entra ID P2** as included in **Microsoft 365 E5** and certain defender/purview suites.
+
+Use this when the user asks whether a Microsoft 365 bundle is enough for Entra controls.
+
+### Example 6: Microsoft Fabric examples
+
+- Microsoft Fabric runs in a **Microsoft Entra tenant**.
+- Fabric collaboration depends on both **capacity** and **per-user licensing** in documented scenarios.
+- Fabric examples are useful when the user assumes “tenant presence” equals “feature entitlement” across services.
+
+Use this when the user is mixing Entra tenant identity, Power BI/Fabric capacities, and user-license assumptions.
+
+### Example 7: External ID
+
+- Microsoft documents **External ID** with its own service and pricing shape.
+- External identity entitlement should not be inferred from workforce Entra premium licensing alone.
+
+Use this when the user mixes workforce identity controls with customer or guest identity assumptions.
+
+### Example 8: Verified ID and Entra Suite extras
+
+- Microsoft documents that some Entra family capabilities sit in the broader **Entra Suite** or have premium add-on distinctions.
+- Do not assume “it is part of Entra” means it is covered by the tenant’s current Entra ID plan.
+
+Use this when the user assumes every Entra-branded capability is included with P1 or P2.
+
+### Example 9: Intune-backed Conditional Access is not just "Entra"
+
+- Microsoft documents that Conditional Access policies requiring compliant devices depend on **Intune compliance posture** and can fail if no compliance policy exists.
+- A tenant can have Conditional Access rights without having the device-management setup or licensing needed for the device-compliance control to work as intended.
+
+Use this when the user assumes device-compliance-based access control is purely an Entra switch.
+
+### Example 10: ID Protection can depend on separate Defender signals
+
+- Microsoft documents that some Microsoft Entra ID Protection detections rely on **Microsoft Defender** products and their licensing.
+- Do not assume all risk detections are available just because the tenant has Entra ID P2.
+
+Use this when the user assumes Entra P2 alone guarantees every risk signal or automated protection path.
+
+### Example 11: Agent ID and AI agent controls have their own prerequisites
+
+- Microsoft documents **Conditional Access for Agent ID (Preview)** and related agent-governance features separately from ordinary user and workload identity controls.
+- Do not assume AI agents inherit the same control surface, object model, or licensing behavior as human users.
+
+Use this when the user is designing AI agents and assumes ordinary Entra patterns automatically cover agent identities.
+
+## Minimum licensing-check workflow
+
+1. Identify the exact feature the user cares about.
+2. Identify whether the question is about:
+   - Entra tenant capability
+   - Microsoft 365 bundle inclusion
+   - Azure subscription baseline
+   - Fabric capacity / per-user access model
+   - Intune-backed device compliance dependency
+   - Defender or Purview signal dependency
+   - workload identity premium features
+   - agent identity preview or AI-governance capability
+   - external identity entitlement
+   - Entra Suite or service-specific premium add-ons
+3. Check official licensing docs.
+4. State one of:
+   - **confirmed licensed prerequisite from docs**
+   - **confirmed not included from docs**
+   - **licensing unknown from provided evidence**
+5. Avoid “you can just use X” unless the prerequisite is proven.
+
+## Safe phrasing examples
+
+- “Documentation says this feature requires Entra ID P1, but I do not know whether your tenant has that license.”
+- “Business Premium includes Conditional Access, but risk-based Conditional Access depends on P2-backed ID Protection.”
+- “Fabric uses the same Entra tenant, but user rights and capacity rights are separate from Entra feature entitlements.”

package/skills/azure/azure-entra-id-specialist/references/mcp-and-evidence.md

@@ -0,0 +1,33 @@
+# MCP and evidence path
+
+Use this reference only when you need to decide how to gather Entra evidence.
+
+## Live-first evidence rule
+
+1. Prefer live Azure MCP capability evidence when the active client exposes Azure tools.
+2. Treat the runtime-exposed tool inventory as truth.
+3. If Entra-specific tooling is not exposed live, say so and switch to documentation-based guidance instead of pretending the namespace exists.
+
+## Azure MCP grounding
+
+Based on Microsoft documentation:
+
+- Microsoft recommends **consolidated mode** for AI agents because it reduces tool count and improves usability.
+- Namespace filtering means a client may expose only a subset of Azure tools.
+- Do not assume that the active client exposes Entra-specific operations just because Microsoft documents broader Azure MCP capabilities.
+
+## Evidence hierarchy
+
+Use this order:
+
+1. **live evidence** — Azure MCP output, sanitized screenshots, sanitized policy exports, sanitized logs, or user-provided config excerpts
+2. **user-provided sanitized evidence** — redacted CA policy summaries, app-registration details, audit logs, sign-in logs, risk events, or screenshots
+3. **documentation-based** — Microsoft Learn and official Azure MCP documentation
+4. **inference** — conclusions derived from patterns but not directly proven by evidence
+
+## Entra caution points
+
+- Do not bless Conditional Access exclusions without explicit break-glass and recovery logic.
+- Do not assume MFA means safe posture if registration, authentication methods, or legacy paths are weak.
+- Do not confuse identity governance controls with full Entra ID security posture.
+- Do not assume workload identities, service principals, or app registrations are low-risk just because they are nonhuman.

package/skills/azure/azure-entra-id-specialist/references/official-sources.md

@@ -0,0 +1,78 @@
+# Official sources
+
+Use this reference only when you need the detailed source list or need to ground a specific claim.
+
+## Azure MCP
+
+- Azure MCP overview  
+  https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/overview
+- Azure MCP concepts  
+  https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/concepts
+- Azure MCP tools overview  
+  https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/
+
+## Microsoft Entra ID
+
+- What is Microsoft Entra?  
+  https://learn.microsoft.com/en-us/entra/fundamentals/what-is-entra
+- What is Microsoft Entra ID Governance?  
+  https://learn.microsoft.com/en-us/entra/id-governance/identity-governance-overview
+- What is Microsoft Entra Privileged Identity Management?  
+  https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure
+- Protect security info registration with Conditional Access policy  
+  https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-all-users-security-info-registration
+- Conditional Access: Users, groups, agents, and workload identities  
+  https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-users-groups
+- What are workload identities?  
+  https://learn.microsoft.com/en-us/entra/workload-id/workload-identities-overview
+- Securing workload identities  
+  https://learn.microsoft.com/en-us/entra/id-protection/concept-workload-identity-risk
+- Conditional Access for Agent ID (Preview)  
+  https://learn.microsoft.com/en-us/entra/identity/conditional-access/agent-id
+- Manage agent identities in your organization  
+  https://learn.microsoft.com/en-us/entra/agent-id/manage-agent-identities-admin
+- Microsoft Entra security for AI overview  
+  https://learn.microsoft.com/en-us/entra/agent-id/security-for-ai-overview
+- Microsoft Entra ID Governance licensing fundamentals  
+  https://learn.microsoft.com/en-us/entra/id-governance/licensing-fundamentals
+- Microsoft Entra licensing  
+  https://learn.microsoft.com/en-us/entra/fundamentals/licensing
+- What is Conditional Access?  
+  https://learn.microsoft.com/en-us/entra/identity/conditional-access/overview
+- Features and licenses for Microsoft Entra multifactor authentication  
+  https://learn.microsoft.com/en-us/entra/identity/authentication/concept-mfa-licensing
+- What is Microsoft Entra ID Protection?  
+  https://learn.microsoft.com/en-us/entra/id-protection/overview-identity-protection
+- Microsoft Entra service description  
+  https://learn.microsoft.com/en-us/office365/servicedescriptions/azure-active-directory
+
+## Cross-service licensing examples
+
+- Azure integration with Microsoft 365  
+  https://learn.microsoft.com/en-us/microsoft-365/enterprise/azure-integration
+- Understand Microsoft Fabric licenses  
+  https://learn.microsoft.com/en-us/fabric/enterprise/licenses
+- Buy a Microsoft Fabric subscription  
+  https://learn.microsoft.com/en-us/fabric/enterprise/buy-subscription
+- Learn about Conditional Access and Intune  
+  https://learn.microsoft.com/en-us/intune/device-security/conditional-access-integration/overview
+- Require device compliance with Conditional Access  
+  https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-all-users-device-compliance
+- Microsoft Defender service description  
+  https://learn.microsoft.com/en-us/office365/servicedescriptions/microsoft-365-service-descriptions/microsoft-365-tenantlevel-services-licensing-guidance/microsoft-defender-service-description
+- Microsoft Entra External ID overview  
+  https://learn.microsoft.com/en-us/entra/external-id/external-identities-overview
+- What are workload identities?  
+  https://learn.microsoft.com/en-us/entra/workload-id/workload-identities-overview
+- What is Microsoft Entra?  
+  https://learn.microsoft.com/en-us/entra/fundamentals/what-is-entra
+
+## Grounded insights used by this skill
+
+- Existing identity governance controls do not prove broader Entra ID posture is sound.
+- Conditional Access and registration controls can create lockout risk if exclusions and emergency access are careless.
+- Workload identities and app registrations need the same least-privilege scrutiny as human admins.
+- Tenant identity, Microsoft 365 bundle rights, and Fabric capacity rights are related but not interchangeable.
+- Adjacent Microsoft services can share the same tenant while still having separate licensing, capacity, or premium-feature gates.
+- Device-compliance Conditional Access can depend on Intune setup and compliance policy existence, not just Entra policy authoring rights.
+- Some ID Protection detections and AI-agent protections depend on adjacent Microsoft services or preview-specific capabilities, not just base Entra branding.

package/skills/azure/azure-entra-id-specialist/references/workflow-and-output.md

@@ -0,0 +1,50 @@
+# Workflow and output contract
+
+Use this reference only when you are performing the full Entra review.
+
+## Workflow
+
+1. **Scope the target**
+   - Confirm whether the question is about users, admins, workload identities, app registrations, external identities, or mixed.
+   - Confirm whether the real problem is sign-in control, privileged access, workload access, or governance.
+   - Confirm whether the issue is tenant-wide, one role family, one app, or one policy set.
+
+2. **Establish evidence level**
+   - Use live Azure MCP evidence when available.
+   - Otherwise use official docs plus sanitized user evidence.
+   - Explicitly label unknowns.
+
+3. **Check licensing and service entitlements when relevant**
+   - Determine whether the user is asking about feature rights, not only technical configuration.
+   - Distinguish Azure baseline, Microsoft 365 bundle inclusion, Entra premium plans, workload identity premium features, and Fabric capacity/per-user rights.
+   - Distinguish Entra tenant identity from adjacent service entitlements such as Intune compliance dependencies, Microsoft Defender signal prerequisites, Purview or Fabric service rights, External ID billing, Verified ID premium add-ons, and agent identity preview capabilities.
+   - If tenant licensing is unproven, mark the answer as licensing-conditional instead of assuming entitlement.
+
+4. **Learn before concluding on adjacent services**
+   - If the user mentions another Microsoft service, do not answer from brand association alone.
+   - Check whether the service merely shares the Entra tenant, depends on Intune/Defender/Purview/Fabric-specific licenses, or introduces a separate identity primitive such as agent identities.
+   - Prefer official Microsoft documentation over memory for cross-service claims.
+
+5. **Stress-check the identity control posture**
+   - Conditional Access scope, exclusions, and lockout safety
+   - MFA/SSPR/authentication-method registration and abuse resistance
+   - risky-user / risky-sign-in handling and identity protection posture
+   - app-registration, enterprise-app, and service-principal ownership and privilege shape
+   - workload identity and managed-identity control boundaries
+   - agent identity, agent user, and blueprint control boundaries when AI agents are in scope
+   - break-glass safety and recovery paths
+
+6. **Check adjacent roles the user may be missing**
+   - **Azure Identity Governance Review** when the problem narrows specifically to PIM, access reviews, entitlement management, and standing-versus-eligible access.
+   - **Azure RBAC Review** when the dominant issue is Azure resource authorization scope rather than Entra tenant identity controls.
+   - **Azure Security Posture Hardening** when the identity question becomes part of a broader Azure security program review.
+
+## Output contract
+
+Use this structure:
+
+1. **Verdict**
+2. **Evidence level**
+3. **Key findings**
+4. **Safest next actions**
+5. **Open questions**

package/skills/azure/azure-governance-policy-guardrails/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: azure-governance-policy-guardrails
+description: Use this skill for Azure Policy guardrails, initiatives, assignment scope, management-group inheritance, exclusions, remediation risk, tag governance, allowed regions or SKUs, and staged governance rollout reviews.
+metadata:
+  author: github: Raishin
+  version: 0.1.0
+---
+
+# Azure Governance Policy Guardrails
+
+## Purpose
+
+Design or review Azure governance guardrails with Azure Policy in a way that is enforceable, scope-aware, and safe to roll out.
+
+## When to use
+
+Use this skill when the user asks for:
+
+- Azure Policy design or review,
+- initiatives versus single policy choices,
+- management-group or subscription assignment placement,
+- exclusions, exemptions, or inheritance concerns,
+- tag governance,
+- allowed locations, resource types, or SKU restrictions,
+- brownfield governance hardening,
+- compliance enforcement rollout safety.
+
+Do not use this as a substitute for full regulatory interpretation, SOC operations, or writing full organization-specific policy JSON 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-governance-policy-guardrails/metadata.json

@@ -0,0 +1,33 @@
+{
+  "id": "azure-governance-policy-guardrails",
+  "name": "Azure Governance Policy Guardrails",
+  "type": "skill",
+  "provider": "azure",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Design and review Azure Policy guardrails, initiatives, assignment scope, exclusions, remediation risk, and staged governance rollout patterns.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/governance",
+    "https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/tailoring-alz",
+    "https://learn.microsoft.com/en-us/azure/governance/policy/overview",
+    "https://learn.microsoft.com/en-us/azure/governance/policy/concepts/initiative-definition-structure",
+    "https://learn.microsoft.com/en-us/azure/governance/policy/assign-policy-portal",
+    "https://learn.microsoft.com/en-us/azure/governance/policy/how-to/remediate-resources",
+    "https://learn.microsoft.com/en-us/azure/governance/policy/concepts/exemption-structure",
+    "https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/migrate-azure-landing-zone-policies",
+    "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-policy"
+  ],
+  "security_notes": "Do not recommend broad-scope deny or remediation-first rollout without blast-radius review, inheritance analysis, exception handling, and rollback notes.",
+  "last_verified": "2026-04-27",
+  "path": "skills/azure/azure-governance-policy-guardrails",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/azure/azure-governance-policy-guardrails/references/mcp-and-evidence.md

@@ -0,0 +1,22 @@
+# MCP and Evidence Path
+
+## Evidence path
+
+Prefer evidence in this order:
+
+1. Azure governance design guidance:
+   - https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/governance
+   - https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/tailoring-alz
+2. Azure Policy core behavior:
+   - https://learn.microsoft.com/en-us/azure/governance/policy/overview
+   - https://learn.microsoft.com/en-us/azure/governance/policy/concepts/initiative-definition-structure
+   - https://learn.microsoft.com/en-us/azure/governance/policy/assign-policy-portal
+   - https://learn.microsoft.com/en-us/azure/governance/policy/how-to/remediate-resources
+   - https://learn.microsoft.com/en-us/azure/governance/policy/concepts/exemption-structure
+3. Azure landing zone policy lifecycle guidance:
+   - https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/migrate-azure-landing-zone-policies
+4. Azure MCP discovery path when available 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-policy
+
+If Azure MCP tools are available, use `policy` first for assignments, definitions, and initiatives. Use `group` and `subscription` to confirm hierarchy and inheritance boundaries. Use `advisor` or `pricing` only when they materially help with governance tradeoffs such as SKU restriction or cost-control guardrails.

package/skills/azure/azure-governance-policy-guardrails/references/official-sources.md

@@ -0,0 +1,18 @@
+# Official Sources
+
+Load these only when needed:
+
+- [What is Azure Policy?](https://learn.microsoft.com/azure/governance/policy/overview) — use for policy object model, assignment scope behavior, evaluation timing, Azure RBAC interaction, and core rollout cautions.
+- [Azure Policy definitions effect basics](https://learn.microsoft.com/azure/governance/policy/concepts/effect-basics) — use when comparing `audit`, `auditIfNotExists`, `deny`, `modify`, and `deployIfNotExists`.
+- [Remediate non-compliant resources with Azure Policy](https://learn.microsoft.com/azure/governance/policy/how-to/remediate-resources) — use for managed identity, RBAC, and remediation-task implications.
+- [Azure Policy built-in policy definitions](https://learn.microsoft.com/azure/governance/policy/samples/built-in-policies) — use when checking whether built-ins already cover tags, locations, SKUs, or baseline controls.
+- [Adopt policy-driven guardrails](https://learn.microsoft.com/azure/cloud-adoption-framework/ready/enterprise-scale/dine-guidance) — use for canary rollout, enforcement mode, and phased `audit` to `deny` or remediation sequencing.
+- [Azure landing zone design principles](https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-principles) — use when guardrails are part of the broader landing-zone operating model.
+- [Azure MCP Server tools inventory](https://learn.microsoft.com/azure/developer/azure-mcp-server/tools/) — use to verify whether `policy`, `group`, `subscription`, `advisor`, or other namespaces are actually documented before naming them.
+
+## Grounded insights worth carrying into the skill
+
+- A policy can be assigned at management-group scope, but Azure Policy evaluates resources at subscription or resource-group level; do not imply it governs arbitrary tenant objects.
+- `modify` and `deployIfNotExists` are not “free automation”; their assignment identities need the right Azure RBAC permissions to create or update target resources.
+- Microsoft guidance explicitly recommends starting with `audit` or `auditIfNotExists` when rollout risk is unclear, rather than jumping straight to production `deny` or remediation.
+- Broad exclusions are usually governance debt. Prefer narrow exclusions or time-bounded exemptions with named ownership.

package/skills/azure/azure-governance-policy-guardrails/references/workflow-and-output.md

@@ -0,0 +1,86 @@
+# Workflow and Output Contract
+
+## Workflow
+
+1. Identify the governing hierarchy first:
+   - tenant root management group,
+   - intermediate management groups,
+   - subscriptions,
+   - resource groups,
+   - exceptional resources that may need carve-outs.
+2. Classify the requested control:
+   - audit-only visibility,
+   - `deny` prevention,
+   - `modify` mutation,
+   - `deployIfNotExists` deployment/remediation,
+   - initiative bundling for repeated baseline controls.
+3. Decide whether the control belongs in:
+   - a single policy definition,
+   - an initiative for baseline packaging,
+   - an existing landing-zone baseline,
+   - or not in policy at all because the ask is process-only or too brittle.
+4. Choose assignment scope deliberately:
+   - prefer the highest scope that matches the real control boundary,
+   - do not assign at broad scope by habit,
+   - verify inheritance impact on child subscriptions and resource groups,
+   - call out when management-group placement is justified versus excessive.
+5. Design exclusions and exemptions separately:
+   - exclusions for scope carve-outs,
+   - exemptions for approved exception handling,
+   - narrow both by resource type, location, or defined exception boundary where possible.
+6. Evaluate guardrail content explicitly for common governance cases:
+   - required tags and tag value standards,
+   - allowed locations,
+   - allowed resource types,
+   - allowed or denied SKUs where built-in policy coverage exists,
+   - baseline initiatives that bundle related controls.
+7. Challenge remediation and mutation risk before recommending enforcement:
+   - `modify` and `deployIfNotExists` need managed identity, permissions, and rollback thought,
+   - remediation can change existing resources,
+   - deny can block live deployment paths if staged badly.
+   - remember that assignment at management-group scope still evaluates subscription/resource-group resources; do not imply magical tenant-object coverage.
+8. Recommend rollout sequencing:
+   - observe with audit first when facts are incomplete,
+   - pilot on a lower, representative scope,
+   - measure non-compliance and exception volume,
+   - then tighten to enforce where justified.
+9. State the rollback and exception path:
+   - remove or disable the assignment,
+   - narrow scope,
+   - replace deny with audit temporarily,
+   - use time-bounded exemptions instead of permanent policy erosion.
+
+## Output contract
+
+Return:
+
+- current governance summary,
+- target control objective,
+- recommended policy versus initiative shape,
+- assignment scope recommendation and inheritance impact,
+- exclusion and exemption strategy,
+- remediation or mutation risk,
+- staged rollout plan,
+- rollback or exception path,
+- assumptions, missing facts, and evidence used.
+
+## Eval gate
+
+Treat the answer as incomplete unless it does all of the following:
+
+- identifies the actual governing scope,
+- separates audit, deny, modify, and remediation concerns,
+- recommends assignment placement instead of hand-waving “use policy,”
+- addresses exclusions or exemptions for brownfield reality,
+- flags rollout risk for deny or remediation effects,
+- gives enforceable guardrails for tags, regions, SKUs, or baseline initiatives when those are in scope.
+
+Fail the response if it recommends root-scope sprawl, ignores inheritance, or proposes enforcement without change-safety notes.
+
+## Safety notes
+
+- Do not recommend tenant-root or broad management-group assignments without explicit blast-radius justification.
+- Do not recommend `deny`, `modify`, or `deployIfNotExists` as a default first move in production.
+- Do not hide remediation side effects; existing resources may be changed or left non-compliant depending on policy effect.
+- Do not treat exclusions as a dumping ground for weak design; prefer narrow, accountable exceptions.
+- Do not claim governance is solved by policy alone; ownership, operating process, and lifecycle updates still matter.