@raishin/vanguard-frontier-agentic 1.0.0

package/skills/azure/azure-resource-health-incident-triage/references/mcp-and-evidence.md

@@ -0,0 +1,34 @@
+# MCP and Evidence Path
+
+## Official Azure MCP Linkage
+
+Use official Azure MCP capabilities as exposed in the active client. Do not invent a namespace, tool, or server label.
+
+Based on the repo spec and Microsoft Azure MCP documentation, relevant capability families can include:
+
+- `resourcehealth` for resource availability status and service-impacting health events,
+- `monitor` for activity-log retrieval and related Azure Monitor evidence,
+- `group` and `subscription` when scope discovery is required before health checks.
+
+Rules:
+
+- Prefer read-only health and activity evidence first.
+- If the expected Azure health tooling is absent, switch to documentation mode instead of pretending live checks happened.
+- Ask for the configured Azure MCP server name only if the client exposes multiple ambiguous Azure servers and the correct one is unclear.
+- Never ask for secrets, credential exports, tenant dumps, or subscription-wide privileged changes just to triage health.
+
+## Platform-Agnostic Execution
+
+This skill must work on macOS, Windows, Linux, and MCP-only clients. Prefer Azure MCP evidence. When portal, CLI, PowerShell, REST, or ARM examples are useful, keep them neutral with `<placeholders>` until the user confirms the active platform and access path.
+
+## Documentation Fallback When Live Data Is Unavailable
+
+Live Azure evidence beats documentation, but documentation is safer than guessing.
+
+If live Azure MCP access is unavailable, incomplete, denied, or clearly out of scope:
+
+- use Microsoft Learn documentation to define what Resource Health, Service Health, Activity Log, and health alerts can and cannot prove,
+- ask for sanitized screenshots, exported alert payloads, event timestamps, activity-log entries, or redacted incident notes,
+- label each conclusion as `live evidence`, `documentation-based`, `user-provided sanitized evidence`, or `inference`,
+- explicitly say when current tenant state is unverified,
+- do not claim a real Azure incident exists unless current evidence shows it.

package/skills/azure/azure-resource-health-incident-triage/references/official-sources.md

@@ -0,0 +1,15 @@
+# Official Sources
+
+## References
+
+Load these only when needed:
+
+- [Azure Resource Health overview](https://learn.microsoft.com/en-us/azure/service-health/resource-health-overview)
+- [Azure Service Health documentation](https://learn.microsoft.com/en-us/azure/service-health/)
+- [Azure Monitor activity log](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/activity-log)
+- [Create or edit an activity log, service health, or resource health alert rule](https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-create-activity-log-alert-rule)
+- [Service Health alerts overview](https://learn.microsoft.com/en-us/azure/service-health/service-health-alert-overview)
+- [Create Service Health alerts for Azure service notifications](https://learn.microsoft.com/en-us/azure/service-health/alerts-activity-log-service-notifications-portal)
+- [Azure MCP Server tools inventory](https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/)
+- [Azure MCP Server tools for Azure Resource Health](https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/azure-resource-health)
+- [Azure MCP Server tools for Azure Monitor and Workbooks](https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/azure-monitor)

package/skills/azure/azure-resource-health-incident-triage/references/workflow-and-output.md

@@ -0,0 +1,79 @@
+# Workflow and Output Contract
+
+## Safe Workflow
+
+1. **Frame the incident**  
+   Confirm exact symptom, affected resource or workload, incident start time, environment, subscription or resource-group boundary, region, and current customer impact.
+2. **Check platform-health signals first**  
+   Review Resource Health status for the named resource or scoped set of resources. Check whether the signal is `Available`, `Unavailable`, `Degraded`, or `Unknown`, and capture reason/details if present.
+3. **Check broader service-impact signals**  
+   Review Service Health events relevant to the subscription, services, region, and time window. Distinguish active issues, planned maintenance, advisories, and resolved history.
+4. **Correlate with Activity Log and alert evidence**  
+   Check recent activity-log events, Resource Health notifications, and Service Health or activity-log alert behavior to see whether the timeline matches a platform event, a user or automation change, or neither.
+5. **Classify the likely failure domain**  
+   Put the incident in one of these bins: `likely provider incident`, `likely tenant misconfiguration or change`, `resource-local issue with no broad Azure evidence`, or `unresolved`.
+6. **Return bounded next actions**  
+   Recommend the next safest move: monitor, escalate to Microsoft, inspect specific tenant changes, hand off to application/SRE owners, or collect missing evidence.
+
+## Role-Specific Stress Checks
+
+- Do not treat `Unknown` as proof of Azure outage. It is a signal gap, not a verdict.
+- Do not treat Service Health absence as proof Azure is healthy for the affected resource.
+- Do not treat Resource Health `Unavailable` as proof the tenant did nothing wrong; Microsoft documents both platform and non-platform events.
+- Check timing. If the incident started immediately after a deployment, policy change, networking change, identity change, or stop/start action, tenant causality is still on the table.
+- Distinguish subscription-level or service-level notices from resource-level degradation.
+- Do not recommend broad failover, rollback, or routing changes before confirming blast radius and approval path.
+- Do not rewrite history from alerts alone; alerts show configured detection, not the full causal chain.
+
+## Output Template
+
+```markdown
+# Azure Health Triage: <scope>
+
+## Current verdict
+- Status: LIKELY PROVIDER INCIDENT / LIKELY TENANT CHANGE OR MISCONFIGURATION / RESOURCE-LOCAL ISSUE / UNRESOLVED
+- Confidence: HIGH / MEDIUM / LOW
+- Evidence level: live evidence / documentation-based / sanitized evidence / inference
+
+## Incident frame
+- Affected scope:
+- Subscription or resource group:
+- Region:
+- Resource(s):
+- Symptom:
+- Reported start time:
+
+## Health evidence
+| Signal | Finding | Time window | Evidence type | What it proves | What it does not prove |
+|---|---|---|---|---|---|
+
+## Blast radius assessment
+- Single resource:
+- Multiple resources:
+- Service/region pattern:
+- User-visible impact:
+
+## Likely failure domain
+- Provider incident evidence:
+- Tenant-side change evidence:
+- Remaining unknowns:
+
+## Immediate next actions
+1.
+2.
+3.
+
+## Escalation and handoff
+- Escalate to:
+- Include these artifacts:
+- Do not claim:
+```
+
+## Red Flags
+
+- The request says "Azure is down" but no subscription, region, resource, or time boundary is given.
+- The conclusion relies on social media, public status chatter, or a single screenshot without tenant-scoped evidence.
+- Resource Health shows no current issue, but the answer still declares a confirmed provider outage.
+- A recent deployment or access-policy change exists, but the analysis ignores it.
+- The skill is being pushed into full RCA when only first-pass platform-health triage is justified.
+- The response recommends destructive remediation before separating provider signal from tenant error.

package/skills/azure/azure-role-selector/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: azure-role-selector
+description: Use this skill when the user asks which Azure role to assign, how to grant minimum access, whether a built-in role is sufficient, or when a custom role may be required.
+metadata:
+  author: github: Raishin
+  version: 0.1.0
+---
+
+# Azure Role Selector
+
+## Purpose
+
+Select the narrowest Azure role and assignment scope that satisfies the requested access without defaulting to broad standing privilege.
+
+## When to use
+
+Use this skill when the user needs to:
+
+- map requested Azure operations to a role,
+- grant minimum access to a user, group, service principal, managed identity, or workload identity,
+- decide whether a built-in role is enough,
+- separate control-plane permissions from data-plane permissions,
+- decide whether a custom role is justified,
+- choose the safest assignment scope and validation path.
+
+Do not use this skill for tenant-wide governance design, access review programs, or broad RBAC posture critique. Route those asks toward `azure-rbac-review` or a governance-focused skill.
+
+## 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-role-selector/metadata.json

@@ -0,0 +1,28 @@
+{
+  "id": "azure-role-selector",
+  "name": "Azure Role Selector",
+  "type": "skill",
+  "provider": "azure",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Select the narrowest Azure built-in role, custom-role fallback, and assignment scope for a requested access pattern while separating control-plane and data-plane permissions.",
+  "source_type": "adapted",
+  "official_docs": [
+    "https://learn.microsoft.com/en-us/azure/role-based-access-control/overview",
+    "https://learn.microsoft.com/en-us/azure/role-based-access-control/best-practices",
+    "https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles",
+    "https://learn.microsoft.com/en-us/azure/role-based-access-control/role-definitions",
+    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/"
+  ],
+  "security_notes": "Prefer built-in roles before custom roles, minimize assignment scope, and keep control-plane and data-plane permissions separate. Do not default to Owner or Contributor for routine access requests.",
+  "last_verified": "2026-04-27",
+  "path": "skills/azure/azure-role-selector",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/azure/azure-role-selector/references/mcp-and-evidence.md

@@ -0,0 +1,12 @@
+# MCP and Evidence Path
+
+## Evidence path
+
+Ground recommendations in Microsoft documentation first.
+
+1. Azure RBAC overview for the control model and scope hierarchy.
+2. Azure RBAC best practices for least privilege, scope minimization, and assignment hygiene.
+3. Azure built-in roles and role-definition docs to match actions before inventing a custom role.
+4. Azure MCP tool references, when available, to inspect role information or confirm live context with less guesswork.
+
+If Azure MCP is available and supported in the session, `role` is the most relevant namespace for this skill. Use it to reduce guesswork, not to bypass the need for least-privilege reasoning.

package/skills/azure/azure-role-selector/references/official-sources.md

@@ -0,0 +1,18 @@
+# Official Sources
+
+Load these only when needed:
+
+- [What is Azure role-based access control (Azure RBAC)?](https://learn.microsoft.com/azure/role-based-access-control/overview) — use for the basic role-assignment model and scope hierarchy.
+- [Azure built-in roles](https://learn.microsoft.com/azure/role-based-access-control/built-in-roles) — use as the first stop before proposing any custom role.
+- [Understand Azure role definitions](https://learn.microsoft.com/azure/role-based-access-control/role-definitions) — use for control-plane versus data-plane actions and how role permissions are actually expressed.
+- [Azure custom roles](https://learn.microsoft.com/azure/role-based-access-control/custom-roles) — use when built-ins do not fit and you need exact constraints on `Actions`, `DataActions`, wildcarding, and assignable scope.
+- [Best practices for Azure RBAC](https://learn.microsoft.com/azure/role-based-access-control/best-practices) — use for least privilege, privileged role avoidance, and automation hygiene.
+- [Assign Azure roles using Azure CLI](https://learn.microsoft.com/azure/role-based-access-control/role-assignments-cli) — use when the answer must include the permission needed to create role assignments.
+- [Azure RBAC tools for the Azure MCP Server overview](https://learn.microsoft.com/azure/developer/azure-mcp-server/tools/azure-rbac) — use to confirm the documented `role` namespace rather than assuming arbitrary RBAC tooling exists.
+
+## Grounded insights worth carrying into the skill
+
+- If a custom role uses `DataActions`, Microsoft documents that it cannot be assigned at management-group scope.
+- Microsoft recommends specifying `Actions` and `DataActions` explicitly instead of using `*` wildcards in custom roles.
+- Role names can change; role IDs are the safer automation anchor.
+- Control plane and data plane are separate authorization paths. A “close enough” role often is not close enough if the wrong plane is involved.

package/skills/azure/azure-role-selector/references/workflow-and-output.md

@@ -0,0 +1,102 @@
+# Workflow and Output Contract
+
+## Workflow
+
+1. Parse the request exactly.
+   - Identify the target resource type and exact operations.
+   - Identify principal type: user, group, service principal, managed identity, or workload identity.
+   - Identify whether the ask is permanent, temporary, human, or machine access.
+2. Separate permission planes.
+   - Control plane: Azure Resource Manager actions such as create, update, delete, deploy, read configuration, or assign policy.
+   - Data plane: service data actions such as reading blobs, secrets, queues, tables, or database data.
+   - If the user mixes both, keep them separate in the answer.
+3. Minimize scope before role selection.
+   - Prefer resource scope over resource-group scope.
+   - Prefer resource-group scope over subscription scope.
+   - Prefer subscription scope over management-group scope.
+   - Treat broad inherited scope as a risk that must be justified.
+4. Prefer the narrowest built-in role.
+   - Check whether a Microsoft built-in role already matches the required actions.
+   - Reject habitual escalation to `Owner`, `Contributor`, or other broad roles unless the requested actions truly require them.
+   - If a role includes meaningful extra privilege, say so explicitly.
+5. Decide whether custom role fallback is justified.
+   - Only consider a custom role when no built-in role safely matches the needed actions.
+   - State which required actions are missing from the closest built-in role.
+   - Keep custom-role scope and assignable scopes narrow.
+   - Avoid wildcard-heavy custom roles unless the user has explicitly accepted the blast radius.
+   - If the design requires `DataActions`, remember that Microsoft documents these custom roles as not assignable at management-group scope.
+6. Recommend assignment scope.
+   - Return the lowest workable scope.
+   - Call out inherited access risk if the user asks for a broader scope than needed.
+   - If the ask spans multiple resources, say whether one shared scope is acceptable or whether split assignments are safer.
+7. Define the validation path.
+   - Validate the role definition or built-in role against the requested actions.
+   - Validate the assignment at the chosen scope.
+   - Validate the real task with a bounded operator test instead of assuming the grant works.
+
+## Output contract
+
+Return all of the following:
+
+- requested access summary,
+- control-plane needs,
+- data-plane needs,
+- recommended built-in role first, or explicit custom-role fallback rationale,
+- recommended assignment scope,
+- validation path,
+- risks, assumptions, and any missing facts.
+
+Use this response shape:
+
+```text
+Requested access
+- <principal> needs <actions> on <resource>
+
+Plane split
+- Control plane: ...
+- Data plane: ...
+
+Recommended role
+- Built-in role: <name> at <scope>
+- Why: <why it fits>
+- Gaps or excess privilege: <if any>
+
+Custom role fallback
+- Needed: yes|no
+- Why: <only if built-in roles do not fit>
+
+Validation path
+- Confirm role definition
+- Confirm assignment scope
+- Perform bounded task test
+
+Risks and assumptions
+- ...
+```
+
+## Eval gate
+
+Treat the skill output as failing if any of the following are missing:
+
+- the requested actions were not parsed into concrete operations,
+- control plane and data plane were not separated,
+- a built-in role search was skipped,
+- a custom role was suggested without stating why built-in roles failed,
+- the assignment scope was omitted,
+- the validation path did not include an actual bounded verification step,
+- risks or assumptions were omitted when facts are incomplete.
+
+Minimum scenarios this skill should handle:
+
+1. read-only storage access,
+2. narrow deploy-oriented application access,
+3. custom-role fallback when built-in roles are too broad or incomplete.
+
+## Safety notes
+
+- Do not recommend `Owner` for routine operations.
+- Do not recommend `Contributor` by default for application onboarding.
+- Do not blur Azure control-plane RBAC with service data-plane permissions.
+- Do not suggest management-group or subscription-wide grants unless the blast radius is explicitly justified.
+- Do not invent custom roles when a built-in role is already close enough and safer.
+- Do not claim least privilege if the answer has not identified excess privilege, missing facts, or validation steps.

package/skills/azure/azure-security-posture-hardening/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: azure-security-posture-hardening
+description: Use this skill for Azure security posture review, baseline hardening, managed identity adoption, Key Vault posture, private access decisions, Azure Policy guardrails, and logging or audit gap analysis. Trigger when the user asks how to harden an Azure workload or platform without defaulting to broad access or public exposure.
+metadata:
+  author: github: Raishin
+  version: 0.1.0
+---
+
+# Azure Security Posture Hardening
+
+## Purpose
+
+Review and harden Azure platform or workload posture using operator-grade controls:
+
+- least privilege,
+- managed identities over stored secrets,
+- private access where justified,
+- Key Vault hardening,
+- policy-enforced controls,
+- audit and diagnostic coverage,
+- staged remediation with rollout safety.
+
+## When to use
+
+Use this skill when the user asks for:
+
+- Azure security baseline or posture review,
+- managed identity migration guidance,
+- Key Vault hardening or secret-handling critique,
+- private endpoint or public exposure decisions for sensitive services,
+- Azure Policy or Defender-backed hardening recommendations,
+- logging, diagnostics, or auditability expectations for Azure security controls,
+- zero-trust-oriented review of platform or workload controls.
+
+Do not use this skill as a full compliance audit, incident forensics runbook, or a substitute for deep service-specific implementation docs.
+
+## 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-security-posture-hardening/metadata.json

@@ -0,0 +1,34 @@
+{
+  "id": "azure-security-posture-hardening",
+  "name": "Azure Security Posture Hardening",
+  "type": "skill",
+  "provider": "azure",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Azure security posture with least privilege, managed identities, Key Vault hardening, private access decisions, policy guardrails, and audit-ready logging expectations.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/security",
+    "https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-areas",
+    "https://learn.microsoft.com/en-us/azure/security/fundamentals/best-practices-and-patterns",
+    "https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/managed-identity-best-practice-recommendations",
+    "https://learn.microsoft.com/en-us/azure/key-vault/general/best-practices",
+    "https://learn.microsoft.com/en-us/azure/key-vault/general/rbac-guide",
+    "https://learn.microsoft.com/en-us/azure/key-vault/general/how-to-azure-key-vault-network-security",
+    "https://learn.microsoft.com/en-us/azure/key-vault/general/howto-logging",
+    "https://learn.microsoft.com/en-us/azure/key-vault/general/monitor-key-vault",
+    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/",
+    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/services/azure-mcp-server-for-key-vault"
+  ],
+  "security_notes": "Do not recommend broad admin roles, stored secrets, or public exposure by default. Prefer managed identities, scoped RBAC, policy-enforced controls, private access where justified, and verified logging coverage.",
+  "last_verified": "2026-04-27",
+  "path": "skills/azure/azure-security-posture-hardening",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/azure/azure-security-posture-hardening/references/mcp-and-evidence.md

@@ -0,0 +1,23 @@
+# MCP and Evidence Path
+
+## Evidence path
+
+Ground the review in this order:
+
+1. **Live Azure evidence when available**
+   - resource exposure,
+   - identity model,
+   - role assignments,
+   - policy assignments/exemptions,
+   - Key Vault configuration,
+   - diagnostic settings and monitoring paths.
+2. **Azure MCP evidence when supported by the client and enabled**
+   - `keyvault` for vault inventory and secret/certificate posture,
+   - `role` for RBAC evidence,
+   - `policy` for guardrail posture,
+   - `monitor` for diagnostic and logging checks,
+   - `advisor` for supporting posture signals.
+3. **Official Microsoft documentation** for design decisions and corrective guidance.
+4. **Explicit assumptions** when live evidence is missing.
+
+If the evidence is incomplete, say so. Do not claim the environment is secure from design intent alone.

package/skills/azure/azure-security-posture-hardening/references/official-sources.md

@@ -0,0 +1,15 @@
+# Official Sources
+
+## Official sources
+
+- Azure landing zone security design area: https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/security
+- Azure landing zone design areas: https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-areas
+- Azure security best practices and patterns: https://learn.microsoft.com/en-us/azure/security/fundamentals/best-practices-and-patterns
+- Managed identity best practice recommendations: https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/managed-identity-best-practice-recommendations
+- Secure your Azure Key Vault: https://learn.microsoft.com/en-us/azure/key-vault/general/best-practices
+- Azure Key Vault RBAC guide: https://learn.microsoft.com/en-us/azure/key-vault/general/rbac-guide
+- Configure network security for Azure Key Vault: https://learn.microsoft.com/en-us/azure/key-vault/general/how-to-azure-key-vault-network-security
+- Enable Key Vault logging: https://learn.microsoft.com/en-us/azure/key-vault/general/howto-logging
+- Monitor Azure Key Vault: https://learn.microsoft.com/en-us/azure/key-vault/general/monitor-key-vault
+- Azure MCP Server tools: https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/
+- 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

package/skills/azure/azure-security-posture-hardening/references/workflow-and-output.md

@@ -0,0 +1,96 @@
+# Workflow and Output Contract
+
+## Workflow
+
+1. **Scope the review**
+   - Identify tenant, management group, subscription, resource group, workload, or service scope.
+   - Separate platform controls from workload-local controls.
+   - Identify whether the ask is greenfield hardening, brownfield remediation, or exception review.
+
+2. **Map identity and secret flows**
+   - List human admins, workload identities, service principals, and managed identities.
+   - Challenge stored credentials, connection strings in code/config, and over-scoped service principals.
+   - Prefer system-assigned or user-assigned managed identities when they reduce secret handling and blast radius.
+   - Check whether Key Vault access uses Azure RBAC and whether permissions are scoped narrowly.
+
+3. **Check network exposure and private access posture**
+   - Identify internet-reachable management or data paths.
+   - Challenge public endpoints for sensitive data paths by default.
+   - Recommend private endpoints, Private Link, or tighter network restrictions when justified by data sensitivity, lateral-movement risk, or zero-trust requirements.
+   - Do not force private access blindly; call out DNS, routing, operational, and cost implications.
+
+4. **Review Key Vault posture**
+   - Check whether secrets, keys, and certificates are centralized appropriately instead of embedded in apps or pipelines.
+   - Check RBAC model, network restrictions, diagnostic logging, and access patterns.
+   - Prefer vault-per-application-per-environment patterns unless there is a justified shared-services design.
+   - Flag broad vault administrator access, uncontrolled secret sprawl, and missing monitoring.
+
+5. **Review policy-enforced controls**
+   - Check for Azure Policy assignments or equivalent guardrails that enforce the intended baseline.
+   - Distinguish audit-only, deny, deployIfNotExists, and remediation-driven controls.
+   - Look for missing controls around public exposure, diagnostics, encryption expectations, approved regions/SKUs, and identity hygiene.
+
+6. **Review detection, audit, and logging coverage**
+   - Check whether critical services emit diagnostics to the intended destination.
+   - Check whether Key Vault logging/monitoring is enabled and retained in an auditable destination.
+   - Call out when security recommendations lack detection coverage, ownership, or alert routing.
+   - Separate “control exists” from “control is monitored.”
+
+7. **Prioritize remediation safely**
+   - Classify findings into urgent, near-term, and strategic.
+   - Sequence changes to avoid breaking apps, pipelines, or operators.
+   - For brownfield environments, recommend validate-first rollout steps and rollback expectations.
+
+## Output contract
+
+Return all of the following:
+
+- **Scope and evidence summary**
+  - reviewed scope,
+  - evidence sources used,
+  - important unknowns.
+- **Current posture summary**
+  - identity model,
+  - secret handling model,
+  - network exposure posture,
+  - policy and monitoring posture.
+- **High-risk findings**
+  - issue,
+  - why it matters,
+  - likely blast radius.
+- **Prioritized hardening plan**
+  - urgent actions,
+  - near-term actions,
+  - strategic improvements.
+- **Safe sequencing**
+  - dependency notes,
+  - validation steps,
+  - rollback cautions.
+- **Assumptions and evidence gaps**
+  - what was inferred,
+  - what must be verified before change approval.
+
+## Eval gate
+
+The skill output is only acceptable if it:
+
+1. identifies identities, secret flows, and network exposure explicitly,
+2. separates control-plane, data-plane, and policy/monitoring concerns,
+3. recommends managed identities and least privilege where applicable,
+4. addresses Key Vault posture, not just generic “use a vault” advice,
+5. includes logging or diagnostic expectations,
+6. prioritizes actions by risk and rollout safety,
+7. states assumptions and missing evidence when live posture is incomplete.
+
+Fail the response if it defaults to broad access, treats public exposure as harmless, ignores telemetry, or gives generic compliance prose without an operator action path.
+
+## Safety notes
+
+- Do not request or expose secrets, tokens, certificates, keys, tenant secrets, or customer data.
+- Do not recommend `Owner`, subscription-wide `Contributor`, or broad vault admin access unless the user has justified the blast radius.
+- Do not recommend public endpoints by default for sensitive services or secret-bearing paths.
+- Do not present private endpoints as free or automatic; call out DNS, routing, and operational dependencies.
+- Do not assume Azure Policy enforcement exists just because a standard is documented.
+- Do not treat diagnostic settings as optional for sensitive services.
+- If the task becomes a deep RBAC redesign, route to `azure-rbac-review` or a role-selection skill.
+- If the task becomes a broader governance initiative rollout, route to a governance/policy guardrail skill.

package/skills/azure/azure-subscription-resource-organization/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: azure-subscription-resource-organization
+description: Use this skill for Azure management-group hierarchy, subscription placement, resource-group boundary, and platform-versus-workload ownership decisions that affect governance, operations, and landing-zone scale.
+metadata:
+  author: github: Raishin
+  version: 0.1.0
+---
+
+# Azure Subscription Resource Organization
+
+## Role Charter
+
+Act as a ruthless Azure resource-organization architect. Your job is to stop weak hierarchy decisions before they become permanent governance debt. Force clarity on management-group purpose, subscription boundary, resource-group lifecycle, policy inheritance, operating ownership, and workload isolation before recommending structure changes.
+
+Default posture:
+
+- Prefer official Microsoft Learn guidance for Azure landing zones, resource organization, and governance.
+- Prefer live Azure MCP evidence when the client exposes relevant official Azure tools and current-state inspection reduces guesswork.
+- Do not invent management-group or subscription capabilities that the active client does not actually expose.
+- Do not ask the user to paste secrets, credentials, tenant secrets, access tokens, or customer identifiers into chat.
+- Do not hard-code tenant names, management-group IDs, subscription IDs, resource-group names, or organizational structure unless the user provides them as confirmed context.
+
+## Trigger Situations
+
+Use this skill when the user asks to:
+
+- Design or review an Azure management-group hierarchy.
+- Decide where subscriptions should sit in a platform or application landing-zone model.
+- Separate platform subscriptions from workload subscriptions.
+- Decide whether a boundary belongs at management-group, subscription, or resource-group level.
+- Review governance, policy inheritance, cost, operations, or security implications of resource organization choices.
+- Clarify which team should own shared services, platform controls, or workload-local resources.
+- Critique brownfield Azure estates with subscription sprawl, flat hierarchy drift, or weak ownership boundaries.
+
+## 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.