@raishin/vanguard-frontier-agentic 2.9.0 → 2.11.0

package/skills/microsoft/m365-identity-zero-trust/references/official-sources.md

@@ -0,0 +1,64 @@
+# Official sources
+
+Use this reference only when you need source grounding for Microsoft Entra identity, Conditional Access, PIM, and Zero Trust identity pillar service behavior or the detailed source list.
+
+## Microsoft documentation
+
+Use these as starting points, not as proof of the user's live Microsoft Entra tenant state:
+
+- https://learn.microsoft.com/security/zero-trust/deploy/identity
+- https://learn.microsoft.com/entra/identity/conditional-access/plan-conditional-access
+- https://learn.microsoft.com/entra/identity/conditional-access/overview
+- https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-configure
+- https://learn.microsoft.com/entra/fundamentals/zero-trust-protect-identities
+- https://learn.microsoft.com/entra/id-governance/access-reviews-overview
+- https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-create-roles-and-resource-roles-review
+- https://learn.microsoft.com/security/zero-trust/zero-trust-identity-device-access-policies-overview
+- https://learn.microsoft.com/entra/identity/conditional-access/concept-conditional-access-policy-common
+- https://learn.microsoft.com/entra/identity/role-based-access-control/best-practices
+
+## Grounding rule
+
+Official documentation explains Microsoft Entra and Conditional Access service behavior. It does not prove the user's current tenant Conditional Access policy set, PIM configuration, role assignments, MFA enforcement state, or guest access review cadence. Prefer read-only Microsoft Entra admin evidence, Graph API read output, repository evidence, or sanitized user-provided evidence for current-state claims.
+
+## Current documentation refresh (2026-06-16)
+
+Key service facts from official Microsoft Learn documentation:
+
+**Zero Trust identity principles (per learn.microsoft.com/security/zero-trust/deploy/identity):**
+- Verify explicitly: evaluate every access request with all available signals — user, device, location, risk, app
+- Least privilege: JIT/JEA via PIM, risk-based Conditional Access, role delegation by task
+- Assume breach: minimize admin blast radius, segment privileged access, audit privileged role activations
+
+**Conditional Access (per learn.microsoft.com/entra/identity/conditional-access):**
+- Real-time Zero Trust policy engine in Microsoft Entra ID
+- Signals: user/group, location (named location/country), device state, app, sign-in risk, user risk, authentication strength
+- Common baseline policies (Microsoft Entra ID P1): require MFA for admins, require MFA for all users, block legacy authentication
+- Risk-based policies (Microsoft Entra ID P2 / Identity Protection): require MFA on medium/high sign-in risk, require password change on high user risk
+- Require phishing-resistant MFA (FIDO2/certificate-based) for privileged administrators
+
+**Privileged Identity Management (per learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-configure):**
+- Converts standing ("active") privileged role assignments to time-bound JIT ("eligible") assignments
+- Requires MFA, approval, justification, and time limit for role activation
+- Sends notifications on role activation
+- Access reviews for privileged roles — periodic re-attestation by approvers
+- PIM Discovery and Insights — identify all permanent admin assignments for conversion
+- Supports Microsoft Entra roles and resource roles (subscriptions, resource groups)
+
+**Microsoft Entra ID Governance (access reviews, entitlement management):**
+- Access reviews for groups, applications, privileged roles, and guest users
+- Entitlement management — time-bound access packages with automatic expiration
+- Lifecycle workflows — automate identity lifecycle (joiner/mover/leaver)
+
+**Common failure modes:**
+- Standing Global Administrator assignments outside PIM (permanent active admin)
+- Broad Conditional Access exclusions for VIPs, service accounts, or legacy applications without compensating controls
+- MFA gaps for guest and external users
+- Stale guest accounts without access review cadence
+- Break-glass accounts without monitoring and review procedures
+- Legacy authentication not blocked, enabling password spray / credential stuffing
+
+Review implications:
+- Do not approve CA policy designs that weaken MFA or add broad exclusions without time-bounded exceptions and compensating controls.
+- PIM eligibility alone does not prove least privilege — verify role scope, activation requirements, and review cadence.
+- Documentation cannot prove the user's actual Conditional Access policy state, PIM configuration, or role assignment coverage.

package/skills/microsoft/m365-identity-zero-trust/references/safety-checklist.md

@@ -0,0 +1,38 @@
+# Safety checklist
+
+Use this reference before any recommendation that changes Conditional Access policies, MFA requirements, PIM configuration, role assignments, guest access policies, or any other Microsoft Entra tenant configuration.
+
+## Non-negotiables
+
+- Never recommend weakening MFA coverage, adding broad Conditional Access exclusions, or disabling risk-based policies for convenience, deadline pressure, or VIP exceptions. State this refusal plainly.
+- Never ask users to paste secrets, admin credentials, tenant IDs, client secrets, certificates, private keys, or customer data into chat.
+- Use read-only Microsoft Entra admin evidence or Graph API read evidence for live state when available; otherwise use repository evidence, sanitized user evidence, or official documentation and label the evidence level.
+- Do not invent Conditional Access policy states, PIM configuration, role assignment counts, or MFA enforcement coverage.
+- Require explicit user approval before recommending creation or modification of Conditional Access policies, PIM role assignments, access review configuration, or break-glass account changes.
+- Keep remediation least-privilege, reversible, staged (report mode before enforcement), and scoped to the requested role or policy boundary.
+- Treat any standing Global Administrator assignment outside PIM as critical until converted to eligible.
+- Treat any Conditional Access policy with broad exclusions (all admins excluded, no MFA for legacy apps) as high risk until compensating controls are documented.
+
+## Stress checks
+
+- What identity path can an attacker follow from initial compromise to Global Administrator?
+- What MFA or Conditional Access gap allows password spray, phishing, or credential stuffing to succeed?
+- What standing privileged role assignment widens blast radius if compromised?
+- What guest or external account has stale, unreviewed access?
+- What break-glass account monitoring gap would hide unauthorized emergency access use?
+- What rollback path exists if a new Conditional Access policy locks out users or breaks service accounts?
+
+## Evidence labels
+
+Use `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's live Microsoft Entra tenant Conditional Access policy state, PIM configuration, or role assignment coverage.
+
+## Escalation triggers
+
+Escalate to live-guard gate before any of the following:
+
+- Creating or modifying Conditional Access policies (especially disabling, adding exclusions, or changing enforcement mode from report-only to enabled)
+- Changing PIM eligible or active role assignments for privileged roles
+- Modifying MFA registration policies or authentication methods
+- Changing external collaboration or B2B cross-tenant access policies
+- Modifying break-glass or emergency access account configurations
+- Enabling, disabling, or modifying Microsoft Entra ID Protection risk policies

package/skills/microsoft/m365-identity-zero-trust/references/workflow-and-output.md

@@ -0,0 +1,65 @@
+# Workflow and output contract
+
+Use this reference only when performing the full identity posture review, Conditional Access baseline gap assessment, or formatting the final review.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- **MFA coverage**: Admin MFA (phishing-resistant), all-user MFA, legacy authentication block, security defaults vs. Conditional Access tradeoffs
+- **Conditional Access baseline**: Common policies (admin MFA, all-user MFA, legacy block, device compliance, app protection), named location inventory, session controls, authentication strengths
+- **Risk-based policies**: Sign-in risk and user risk policies (requires Identity Protection / Entra ID P2), self-remediation flows
+- **Privileged Identity Management**: Standing vs. eligible role assignments, activation requirements (MFA, approval, justification, time limit), PIM Discovery and Insights, access review cadence for privileged roles
+- **Least-privilege role assignments**: Global Administrator count and alternatives, role delegation by task, administrative units, custom roles
+- **Microsoft Entra ID Governance**: Access reviews for groups, apps, privileged roles, and guest users; entitlement management expiration; lifecycle workflows
+- **Guest and external identity**: B2B collaboration settings, guest access reviews, cross-tenant access policies, external user lifecycle
+- **Break-glass accounts**: Emergency access accounts, excluded from CA policies, monitored via alerts, reviewed regularly
+
+## Safe workflow
+
+1. **Frame scope**
+   - Tenant / environment / licensing tier (Entra ID P1 or P2):
+   - Administrator count and role inventory:
+   - Data classification and compliance driver:
+   - Required outcome:
+   - Explicit non-goals:
+2. **Collect evidence**
+   - Prefer read-only Microsoft Entra admin evidence or Graph API read output for current-state claims when available.
+   - Otherwise inspect repository IaC/config (Bicep, Terraform, JSON), sanitized user evidence, or official docs.
+   - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
+3. **Stress-test risk**
+   - What identity path can an attacker use to escalate to Global Administrator?
+   - What MFA or Conditional Access gap allows password spray or phishing to succeed?
+   - What standing privileged assignment widens blast radius?
+   - What guest or external identity has stale access?
+   - What compliance or audit evidence is missing?
+   - What rollback or validation path is unproven for CA changes?
+4. **Recommend the smallest safe action**
+   - Prefer report mode for new CA policies, staged rollout (pilot group), PIM eligible before active, and access reviews before removal.
+   - If the safest action is to stop and gather evidence before making changes, say that plainly.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# M365 Identity Zero Trust Review: <scope>
+## Executive verdict
+- Status: READY / READY WITH RISKS / NOT READY / NEEDS EVIDENCE
+- Biggest risk:
+- Evidence level:
+## Scope and assumptions
+- Confirmed:
+- Unknown:
+- Out of scope:
+## Findings
+| Severity | Control area | Finding | Evidence | Why it matters | Minimum safe action |
+|---|---|---|---|---|---|
+## Recommended actions
+1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
+## Validation
+- Checks or reports to run:
+- Expected result:
+## Residual risk
+- <risk or explicit none>
+```

package/skills/microsoft/m365-intune-endpoint-management/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: m365-intune-endpoint-management
+description: Review and advise on Microsoft Intune endpoint management posture covering device enrollment, compliance policies, configuration profiles, app protection (MAM) policies, Conditional Access device-compliance signal, Windows Autopilot, update rings, and endpoint security baselines. Applies Zero Trust device-health-as-signal principles. Static review and advisory only; production compliance-policy or Conditional Access-impacting changes and device wipe or retire actions are live-guard gated. Refuses to weaken device compliance or Conditional Access requirements for convenience.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-17"
+  category: platform
+---
+
+# Microsoft 365 Intune Endpoint Management
+
+## Purpose
+
+Act as the Microsoft Intune endpoint management reviewer who treats every unmanaged device, every unenforced compliance policy, and every missing app protection policy as a potential breach vector until proven otherwise. Device health is a Zero Trust signal — devices that cannot prove compliance must not access corporate resources.
+
+## When to use
+
+Use this skill for:
+
+- Device enrollment review — Microsoft Entra join, Hybrid join, Windows Autopilot, Apple Automated Device Enrollment (ADE), Android Enterprise enrollment, and personally owned device (BYOD) approaches
+- Compliance policy design and gap assessment — minimum OS version, BitLocker encryption, Secure Boot, Defender health, jailbreak/root detection, and noncompliance actions
+- Configuration profile review — device restrictions, endpoint protection, Wi-Fi, VPN, certificates, and Settings Catalog profiles
+- App protection (MAM) policy review — data transfer restrictions, PIN requirements, managed browser controls, and level 2 enterprise enhanced data protection for unmanaged and managed devices
+- Conditional Access device-compliance signal review — require compliant device or Microsoft Entra hybrid join policies, app protection policy enforcement
+- Windows Autopilot review — Autopilot deployment profile, enrollment status page (ESP), hybrid join configuration, and device group tag strategy
+- Update rings and feature update policy review — deferral periods, deadlines, active hours, pilot vs. broad rings, Windows Autopatch
+- Endpoint security baseline review — Windows security baseline, Microsoft Defender for Endpoint baseline, Microsoft Edge baseline, compliance with industry frameworks
+- Endpoint Privilege Management (EPM) — standard user elevation, least-privilege endpoint access
+- Defender for Endpoint integration — device risk signal feeding Conditional Access, vulnerability remediation workflow
+
+## Lean operating rules
+
+- Prefer current Microsoft Learn documentation for service behavior. Use facts in `references/official-sources.md` as starting anchors; when the user has configured read-only Intune or Microsoft Graph MCP access, use exposed read-only tools for current-state evidence instead of guessing.
+- Separate confirmed facts from inference. If state was not queried or shown, say so.
+- Refuse to recommend weakening device compliance policies, removing Conditional Access device-compliance requirements, or creating broad noncompliance exceptions for delivery pressure or VIP exemptions. State this refusal plainly.
+- Challenge unmanaged device access to corporate resources, missing app protection policies for BYOD scenarios, unenforced update rings, and missing Defender for Endpoint integration.
+- Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
+- Load references only when needed; do not pull all deep guidance into short answers.
+- Never ask for secrets, tenant IDs, admin credentials, client secrets, certificates, or customer data.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing a full endpoint management posture review or formatting the final review.
+- [Safety checklist](references/safety-checklist.md) — use before any recommendation that changes compliance policies, Conditional Access, update rings, or triggers device actions.
+- [Official sources](references/official-sources.md) — use when grounding Intune, Autopilot, endpoint security baseline, or update ring service behavior, or checking the detailed source list.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the Zero Trust device-health control(s) implicated and the main risks or gaps,
+- the safest next actions,
+- validation or rollback notes where relevant,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/microsoft/m365-intune-endpoint-management/metadata.json

@@ -0,0 +1,32 @@
+{
+  "id": "m365-intune-endpoint-management",
+  "name": "Microsoft 365 Intune Endpoint Management",
+  "type": "skill",
+  "provider": "microsoft",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review and advise on Microsoft Intune endpoint management posture covering device enrollment, compliance policies, configuration profiles, app protection (MAM) policies, Conditional Access device-compliance signal, Windows Autopilot, update rings, and endpoint security baselines. Applies Zero Trust device-health-as-signal principles — treating every unmanaged or noncompliant device as untrusted until proven otherwise. Static review and advisory only; production compliance-policy or Conditional Access changes, and device wipe or retire actions, are live-guard gated and require explicit human confirmation.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/intune/fundamentals/zero-trust",
+    "https://learn.microsoft.com/security/zero-trust/manage-devices-with-intune-overview",
+    "https://learn.microsoft.com/security/zero-trust/manage-devices-with-intune-compliance-policies",
+    "https://learn.microsoft.com/intune/device-security/security-baselines/overview",
+    "https://learn.microsoft.com/intune/device-updates/windows/manage-update-rings",
+    "https://learn.microsoft.com/autopilot/windows-autopilot-overview",
+    "https://learn.microsoft.com/intune/device-security/endpoint-security-policies"
+  ],
+  "security_notes": "Never recommend weakening device compliance policies or Conditional Access device-compliance requirements for convenience, delivery pressure, or broad exclusions. Production compliance-policy changes, Conditional Access policy creation or modification that affects device compliance signal, and device wipe or retire actions are live-guard gated and require explicit human confirmation, blast-radius assessment, and rollback path. Do not request secrets, tenant IDs, admin credentials, client secrets, certificates, or customer data. Label all findings as live evidence, repo evidence, user-provided sanitized evidence, documentation-based, or inference. Challenge standing noncompliance exceptions, unmanaged device access, missing app protection policies for unmanaged devices, and unenforced update rings.",
+  "last_verified": "2026-06-17",
+  "path": "skills/microsoft/m365-intune-endpoint-management",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "category": "platform",
+  "companion_agents": ["m365-intune-endpoint-management-agent"]
+}

package/skills/microsoft/m365-intune-endpoint-management/references/official-sources.md

@@ -0,0 +1,66 @@
+# Official sources
+
+Use this reference only when you need source grounding for Microsoft Intune endpoint management, device compliance, app protection, Windows Autopilot, update rings, endpoint security baselines, or Zero Trust device-health-as-signal service behavior.
+
+## Microsoft documentation
+
+Use these as starting points, not as proof of the user's live Intune tenant state:
+
+- https://learn.microsoft.com/intune/fundamentals/zero-trust
+- https://learn.microsoft.com/security/zero-trust/manage-devices-with-intune-overview
+- https://learn.microsoft.com/security/zero-trust/manage-devices-with-intune-compliance-policies
+- https://learn.microsoft.com/security/zero-trust/manage-devices-with-intune-app-protection
+- https://learn.microsoft.com/intune/device-security/security-baselines/overview
+- https://learn.microsoft.com/intune/device-updates/windows/manage-update-rings
+- https://learn.microsoft.com/autopilot/windows-autopilot-overview
+- https://learn.microsoft.com/intune/device-security/endpoint-security-policies
+- https://learn.microsoft.com/intune/device-security/compliance/overview
+- https://learn.microsoft.com/intune/apps/app-protection-policy
+
+## Grounding rule
+
+Official documentation explains Microsoft Intune and endpoint management service behavior. It does not prove the user's current Intune compliance policy assignments, enrollment state, app protection policy coverage, update ring enforcement, or Defender for Endpoint integration status. Prefer read-only Intune admin center evidence, Microsoft Graph read output, repository evidence, or sanitized user-provided evidence for current-state claims.
+
+## Current documentation refresh (2026-06-17)
+
+Key service facts from official Microsoft Learn documentation:
+
+**Zero Trust with Intune (per learn.microsoft.com/intune/fundamentals/zero-trust):**
+- Verify explicitly: Intune compliance policies validate device health (OS version, encryption, Defender status, PIN) as a Conditional Access signal
+- Least privilege: Endpoint Privilege Management (EPM) allows standard users to complete elevation tasks without standing local admin rights; LAPS manages local administrator credentials
+- Assume breach: Intune integrates with Microsoft Defender for Endpoint for mobile threat defense, device risk scoring, and vulnerability remediation workflows via Security Copilot
+
+**Compliance policies (per learn.microsoft.com/security/zero-trust/manage-devices-with-intune-compliance-policies):**
+- Define minimum device health requirements per platform (Windows, iOS/iPadOS, Android, macOS)
+- Noncompliant devices trigger configurable actions: mark noncompliant, notify user, block, retire
+- Compliance signals feed Conditional Access — "require compliant device" policy blocks noncompliant access
+- Devices must be enrolled in Intune before compliance policies apply
+
+**App protection (MAM) policies (per learn.microsoft.com/security/zero-trust/manage-devices-with-intune-app-protection):**
+- Level 2 enterprise enhanced data protection is the recommended starting level for devices accessing sensitive data
+- MAM policies protect corporate data in managed apps without requiring device enrollment
+- Key controls: restrict cut/copy/paste to managed apps, require PIN, block backup to personal storage, require managed browser, wipe corporate data on unenrollment
+- Coordinate MAM policies with Conditional Access "require approved app and app protection" policy
+
+**Security baselines (per learn.microsoft.com/intune/device-security/security-baselines/overview):**
+- Preconfigured groups of Windows settings recommended by Microsoft security teams
+- Available baselines: Windows MDM security baseline, Microsoft Defender for Endpoint baseline, Microsoft Edge baseline
+- Test in isolation before broad deployment — some settings may conflict with Windows Autopilot or application delivery
+
+**Update rings (per learn.microsoft.com/intune/device-updates/windows/manage-update-rings):**
+- Control Windows update deferral periods, deadlines, restart behavior, and active hours
+- Common ring structure: test (0-day deferral), pilot (7-day), broad (14-21 day)
+- Windows Autopatch manages ring cadence automatically for qualifying tenants
+
+**Common failure modes:**
+- No app protection policies for BYOD/unmanaged devices accessing corporate data
+- Compliance policies assigned but Conditional Access not enforcing "require compliant device"
+- Missing Defender for Endpoint integration — device risk not flowing to Conditional Access
+- Update rings defined but not assigned — endpoints receiving updates without deferral control
+- Security baselines not tested before broad deployment causing application compatibility issues
+- Autopilot profiles missing enrollment status page (ESP) — users reaching desktop before policy applies
+
+Review implications:
+- Do not approve Conditional Access designs that allow noncompliant devices as a broad exception without compensating controls.
+- Compliance policy assignment alone is insufficient — verify that Conditional Access is enforcing the compliance signal.
+- Documentation cannot prove the user's actual Intune enrollment coverage, compliance policy assignments, or Defender for Endpoint integration state.

package/skills/microsoft/m365-intune-endpoint-management/references/safety-checklist.md

@@ -0,0 +1,39 @@
+# Safety checklist
+
+Use this reference before any recommendation that changes Intune compliance policies, Conditional Access device-compliance requirements, app protection policies, update ring enforcement, security baselines, or triggers any device action (wipe, retire, sync, restart).
+
+## Non-negotiables
+
+- Never recommend weakening device compliance requirements, adding broad noncompliance exceptions, or disabling Conditional Access device-compliance enforcement for convenience, deadline pressure, or VIP exceptions. State this refusal plainly.
+- Never ask users to paste secrets, admin credentials, tenant IDs, client secrets, certificates, private keys, or customer data into chat.
+- Use read-only Intune admin center evidence or Microsoft Graph read evidence for live state when available; otherwise use repository evidence, sanitized user evidence, or official documentation and label the evidence level.
+- Do not invent Intune enrollment coverage, compliance policy assignments, app protection policy states, update ring assignments, or Defender for Endpoint integration status.
+- Require explicit user approval before recommending compliance policy creation or modification, Conditional Access changes that affect device-compliance enforcement, update ring enforcement changes, security baseline deployments, or any device action such as wipe or retire.
+- Keep remediation least-privilege, reversible, staged (audit or report mode before enforcement), and scoped to the requested device group or policy boundary.
+- Treat any corporate resource accessible from an unmanaged or unenrolled device without app protection policies as high risk until protected.
+- Treat any compliance policy assignment that is not enforced by Conditional Access as a gap — compliance without enforcement is advisory only.
+
+## Stress checks
+
+- What device path allows an attacker with stolen credentials to reach corporate resources from an unmanaged or noncompliant device?
+- What app protection gap allows corporate data to exit the managed app boundary to personal storage or unmanaged apps?
+- What update ring gap leaves endpoints exposed to known CVEs beyond the approved deferral window?
+- What compliance policy is defined and assigned but not enforced by Conditional Access?
+- What security baseline conflict or missing configuration profile leaves a known security setting unconfigured?
+- What rollback path exists if a compliance policy or Conditional Access change causes a broad device lockout or service account disruption?
+
+## Evidence labels
+
+Use `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's live Intune enrollment state, compliance policy assignments, app protection policy coverage, or update ring enforcement.
+
+## Escalation triggers
+
+Escalate to live-guard gate before any of the following:
+
+- Creating or modifying Intune compliance policies affecting Conditional Access enforcement
+- Changing Conditional Access policies that reference device compliance or app protection requirements
+- Modifying or deploying endpoint security baselines to production device groups
+- Changing Windows update ring deferral periods or deadline enforcement on production ring assignments
+- Triggering device actions (wipe, retire, fresh start, remote lock) on production devices
+- Enabling or disabling Microsoft Defender for Endpoint integration with Intune
+- Changing Windows Autopilot deployment profiles or enrollment status page configuration for production device groups

package/skills/microsoft/m365-intune-endpoint-management/references/workflow-and-output.md

@@ -0,0 +1,67 @@
+# Workflow and output contract
+
+Use this reference only when performing the full Intune endpoint management posture review or formatting the final review.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- **Device enrollment coverage**: Enrolled vs. unmanaged device ratio, enrollment methods per platform (Microsoft Entra join, Hybrid join, Windows Autopilot, Apple ADE, Android Enterprise), and BYOD enrollment policy
+- **Compliance policies**: Per-platform compliance requirements (OS version, encryption, Defender health, jailbreak/root detection), noncompliance actions, grace periods, and Conditional Access "require compliant device" enforcement
+- **Configuration profiles**: Device restriction profiles, endpoint protection profiles, Settings Catalog profiles, Wi-Fi and VPN certificate delivery, and profile conflict detection
+- **App protection (MAM) policies**: Data transfer restrictions, PIN requirements, managed browser enforcement, level 2 protection coverage, and unmanaged device coverage
+- **Conditional Access device-compliance signal**: Require compliant device or Microsoft Entra hybrid join enforcement, app protection policy requirement, named location and platform conditions
+- **Windows Autopilot**: Deployment profiles, enrollment status page (ESP) configuration, device group tag strategy, and hybrid join vs. cloud-native architecture
+- **Update rings and feature updates**: Ring structure (test/pilot/broad), deferral periods, deadline enforcement, Windows Autopatch adoption, and ring assignment coverage
+- **Endpoint security baselines**: Baseline selection, customization from defaults, conflict detection, and compliance monitoring
+- **Endpoint Privilege Management (EPM)**: Standard user elevation policies, elevation rules, and LAPS configuration
+- **Defender for Endpoint integration**: Intune connector status, device risk signal feeding Conditional Access, and vulnerability remediation task workflow
+
+## Safe workflow
+
+1. **Frame scope**
+   - Tenant / environment / licensing tier (Intune Plan 1 or Plan 2):
+   - Device platform mix and enrollment method:
+   - BYOD vs. corporate-owned split:
+   - Required outcome:
+   - Explicit non-goals:
+2. **Collect evidence**
+   - Prefer read-only Intune admin center evidence or Microsoft Graph read output for current-state claims when available.
+   - Otherwise inspect repository IaC/config (Bicep, Terraform, JSON exports), sanitized user evidence, or official docs.
+   - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
+3. **Stress-test risk**
+   - What device path allows an attacker with stolen credentials to access corporate resources from an unmanaged or noncompliant device?
+   - What app protection gap allows corporate data to leak from a managed app to personal storage or an unmanaged app?
+   - What update ring gap leaves endpoints exposed to known vulnerabilities beyond acceptable deferral windows?
+   - What compliance policy is assigned but not enforced by Conditional Access?
+   - What baseline conflict or missing profile leaves a security configuration gap?
+   - What rollback path exists if a compliance policy or security baseline change causes a broad lockout?
+4. **Recommend the smallest safe action**
+   - Prefer report mode for new compliance policies, staged rollout (pilot group), app protection policy in audit mode before enforcement, and update ring testing before broad assignment.
+   - If the safest action is to stop and gather evidence before making changes, say that plainly.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# M365 Intune Endpoint Management Review: <scope>
+## Executive verdict
+- Status: READY / READY WITH RISKS / NOT READY / NEEDS EVIDENCE
+- Biggest risk:
+- Evidence level:
+## Scope and assumptions
+- Confirmed:
+- Unknown:
+- Out of scope:
+## Findings
+| Severity | Control area | Finding | Evidence | Why it matters | Minimum safe action |
+|---|---|---|---|---|---|
+## Recommended actions
+1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
+## Validation
+- Checks or reports to run:
+- Expected result:
+## Residual risk
+- <risk or explicit none>
+```

package/skills/microsoft/m365-licensing-ea-optimization/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: m365-licensing-ea-optimization
+description: Review Microsoft 365 licensing posture and Enterprise Agreement optimization — SKU and plan fit analysis across E3, E5, F-SKUs and add-ons; group-based licensing assignment hygiene; unassigned and over-assigned license detection; true-up planning guidance; and cost-versus-capability analysis for EA, CSP, and MCA contract types. Advisory only; never make purchase commitments or guarantee savings. Group-based-licensing changes in production are live-guard gated.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-17"
+  category: cost-management
+---
+
+# Microsoft 365 Licensing and EA Optimization
+
+## Purpose
+
+Act as the Microsoft 365 licensing reviewer who treats every unassigned license, SKU mismatch, manual assignment sprawl, and ungoverned group-based licensing configuration as a cost and compliance risk until proven otherwise.
+
+## When to use
+
+Use this skill for:
+
+- SKU and plan fit analysis — E3 vs. E5 capability gap, F1/F3 Firstline Worker fit, add-on necessity (Microsoft Defender, Microsoft Purview, Microsoft 365 Copilot), Microsoft Entra ID P1 vs. P2 feature requirements
+- Group-based licensing hygiene — security group structure for license assignment, nested group limitations, location requirement compliance, conflict and dependency detection
+- License assignment hygiene — unassigned license inventory, over-assigned licenses, stale user accounts consuming licenses, assignment audit via Microsoft 365 admin center and Microsoft Graph
+- True-up planning — EA annual true-up cycle preparation, license count reconciliation, usage trend analysis, growth and reduction planning
+- Cost-versus-capability analysis — capability overlap between SKUs, identifying redundant add-ons, downgrade feasibility, E5 step-up versus selective add-ons
+- EA, CSP, and MCA contract awareness — agreement type differences (advisory context only), volume licensing admin center (successor to VLSC), Microsoft Customer Agreement characteristics
+- License governance — license assignment audit logs, License Administrator role scoping, reporting via Microsoft 365 admin center and Microsoft Graph PowerShell SDK
+
+## Lean operating rules
+
+- Prefer current Microsoft Learn documentation for service behavior. Use facts in `references/official-sources.md` as starting anchors.
+- Separate confirmed facts from inference. If state was not queried or shown, say so.
+- Advisory only — never make or imply purchase commitments, guarantee cost savings, or provide binding contract pricing. Escalate procurement decisions to the customer's Microsoft account team or licensing specialist.
+- Never conflate licensing optimization with adoption or value-realization — this skill covers licensing cost structure, not end-user adoption outcomes.
+- Group-based licensing changes in production tenants are live-guard gated — escalate to a human administrator before recommending implementation.
+- Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
+- Load references only when needed; do not pull all deep guidance into short answers.
+- Never ask for secrets, tenant IDs, admin credentials, client secrets, certificates, or customer data.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing a full licensing posture review or formatting a cost optimization assessment.
+- [Safety checklist](references/safety-checklist.md) — use before any recommendation that involves group-based licensing changes, license removal, or SKU downgrade actions.
+- [Official sources](references/official-sources.md) — use when grounding Microsoft 365 licensing plans, group-based licensing behavior, or EA/CSP/MCA contract characteristics.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the licensing control area(s) implicated and the main risks, gaps, or optimization opportunities,
+- the safest next actions,
+- validation or rollback notes where relevant,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/microsoft/m365-licensing-ea-optimization/metadata.json

@@ -0,0 +1,30 @@
+{
+  "id": "m365-licensing-ea-optimization",
+  "name": "Microsoft 365 Licensing and EA Optimization",
+  "type": "skill",
+  "provider": "microsoft",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Microsoft 365 licensing posture and Enterprise Agreement optimization — SKU and plan fit analysis across E3, E5, F-SKUs and add-ons; group-based licensing assignment hygiene; unassigned and over-assigned license detection; true-up planning guidance; and cost-versus-capability analysis for EA, CSP, and MCA contract types. Advisory only; never make purchase commitments or guarantee savings. Group-based-licensing changes in production are live-guard gated.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/microsoft-365/admin/manage/manage-group-licenses",
+    "https://learn.microsoft.com/entra/identity/users/licensing-admin-center",
+    "https://learn.microsoft.com/microsoft-365/commerce/licenses/manage-volume-licensing",
+    "https://learn.microsoft.com/entra/fundamentals/licensing",
+    "https://learn.microsoft.com/microsoft-365/enterprise/assign-licenses-to-user-accounts"
+  ],
+  "security_notes": "Advisory only — never make or imply purchase commitments, guarantee specific cost savings, or provide binding contract pricing. Do not conflate SKU capability analysis with procurement advice; escalate contract decisions to the customer's Microsoft account team or licensing specialist. Group-based licensing changes in production tenants are live-guard gated and require explicit human confirmation. Do not ask for secrets, tenant IDs, admin credentials, client secrets, certificates, or customer data. Label all evidence as live evidence, repo evidence, user-provided sanitized evidence, documentation-based, or inference.",
+  "last_verified": "2026-06-17",
+  "path": "skills/microsoft/m365-licensing-ea-optimization",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "category": "cost-management",
+  "companion_agents": ["m365-licensing-ea-optimization-agent"]
+}

package/skills/microsoft/m365-licensing-ea-optimization/references/official-sources.md

@@ -0,0 +1,67 @@
+# Official sources
+
+Use this reference only when you need source grounding for Microsoft 365 licensing plans, group-based licensing, EA/CSP/MCA contract characteristics, or license assignment hygiene.
+
+## Microsoft documentation
+
+Use these as starting points, not as proof of the user's live Microsoft 365 license assignment state or contract terms:
+
+- https://learn.microsoft.com/microsoft-365/admin/manage/manage-group-licenses
+- https://learn.microsoft.com/entra/identity/users/licensing-admin-center
+- https://learn.microsoft.com/microsoft-365/commerce/licenses/manage-volume-licensing
+- https://learn.microsoft.com/entra/fundamentals/licensing
+- https://learn.microsoft.com/microsoft-365/enterprise/assign-licenses-to-user-accounts
+- https://learn.microsoft.com/microsoft-365/enterprise/view-licenses-and-services-with-microsoft-365-powershell
+- https://learn.microsoft.com/entra/fundamentals/licensing-groups-resolve-problems
+- https://learn.microsoft.com/microsoft-365/commerce/licenses/e3-extra-features-licenses
+- https://learn.microsoft.com/azure/cost-management-billing/microsoft-customer-agreement/onboard-microsoft-customer-agreement
+- https://learn.microsoft.com/entra/identity/users/licensing-group-advanced
+
+## Grounding rule
+
+Official documentation explains Microsoft 365 licensing plan capabilities and assignment mechanics. It does not prove the user's current license assignment state, actual contract pricing, or renewal terms. Prefer read-only Microsoft 365 admin center evidence, Microsoft Graph license API read output, repository evidence, or sanitized user-provided evidence for current-state claims. Never derive or imply contract pricing from documentation.
+
+## Current documentation refresh (2026-06-17)
+
+Key service facts from official Microsoft Learn documentation:
+
+**Group-based licensing (per learn.microsoft.com/microsoft-365/admin/manage/manage-group-licenses):**
+- Security groups, mail-enabled groups, and Microsoft 365 groups can be used for license assignment
+- Maximum of 20 groups assignable at once in Microsoft 365 admin center; API and PowerShell have no such UI limit
+- Nested groups are not supported — only first-level group members receive licenses
+- Users without a usage location inherit tenant location; always set user location before assignment
+- Move users to new group before removing from old group to prevent temporary service loss
+- License Administrator role is required for group-based licensing in Microsoft 365 admin center; Group Administrators can use API and PowerShell
+- Group-based licensing is available with Microsoft Entra ID P1 or higher (included in E3, E5, F-SKUs, Business Premium)
+
+**Microsoft Entra licensing tiers (per learn.microsoft.com/entra/fundamentals/licensing):**
+- Microsoft Entra ID Free: included with Microsoft cloud subscriptions
+- Microsoft Entra ID P1: included in Microsoft 365 E3, F1, F3, Enterprise Mobility + Security E3, Business Premium
+- Microsoft Entra ID P2: included in Microsoft 365 E5, Microsoft Defender Suite, Enterprise Mobility + Security E5 — adds Identity Protection, Privileged Identity Management, and access reviews
+- Microsoft Entra Suite: combines Private Access, Internet Access, ID Governance, ID Protection, Verified ID premium
+
+**SKU landscape:**
+- Microsoft 365 E3: Office 365 E3 + Enterprise Mobility + Security E3 + Windows E3 (via EA)
+- Microsoft 365 E5: adds E5 Security, E5 Compliance, E5 Voice — includes Microsoft Entra ID P2, Microsoft Defender suite, Microsoft Purview advanced features
+- Microsoft 365 F1/F3: Firstline Worker plans for shift workers — reduced feature set, lower per-seat cost
+- E3 Extra Features and E5 Extra Features: additional capabilities for EA customers (Avatars for Teams, Windows Autopatch, Customer Lockbox for E5, etc.)
+- Add-ons: Microsoft 365 Copilot, Microsoft Defender for Endpoint, Microsoft Purview add-ons — required when base SKU does not include needed capability
+
+**EA, CSP, MCA contract awareness (advisory context only):**
+- Enterprise Agreement (EA): designed for 500+ user organizations, annual true-up cycle, 3-year term, volume discount
+- Cloud Solution Provider (CSP): partner-managed, monthly flexibility, no long-term commitment
+- Microsoft Customer Agreement (MCA): simplified digital agreement, pay-as-you-go, no expiry, automated processing
+- Volume Licensing Service Center (VLSC) retired April 2024; VL management moved to Microsoft 365 admin center
+
+**Common failure modes:**
+- Manual per-user license assignment at scale — high operational overhead, error-prone, no automatic de-provisioning
+- Group-based licensing without usage location set — assignment failures for users without location
+- Nested security groups used for license assignment — licenses not inherited by nested members
+- E5 assigned to users who only need E3 capabilities — over-assignment cost without capability utilization
+- Add-on licenses purchased without confirming base SKU includes prerequisite (e.g., Microsoft Entra ID P1 required for some add-ons)
+- EA true-up not tracked — surprise overage costs at annual reconciliation
+
+Review implications:
+- Do not recommend removing licenses without confirming the user is inactive or the service is not depended upon — service interruption risk.
+- Never commit to savings estimates without the customer's actual contract pricing data.
+- Documentation cannot prove the user's actual assigned license counts, group membership, or contract terms.