@raishin/vanguard-frontier-agentic 2.7.1 → 2.9.0

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

@@ -1,102 +1,41 @@
-# Workflow and Output Contract
+# 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:
+Use this reference for full execution of `azure-role-selector`.
 
-```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
+## Workflow
 
-Risks and assumptions
-- ...
-```
+1. **Classify the request**
+   - Identify service/domain, resource scope, environment, production impact, and whether mutation or billing impact is requested.
+   - Identify whether the task needs documentation-only guidance, sampled read-only current-state evidence, or sanitized user evidence.
 
-## Eval gate
+2. **Ground in current sources**
+   - Prefer Microsoft Learn documentation through the user's configured documentation MCP.
+   - Read the component operations guide before issuing design, safety, or readiness conclusions.
+   - Treat current-state claims as unproven unless supported by sampled read-only evidence or sanitized user-provided evidence.
 
-Treat the skill output as failing if any of the following are missing:
+3. **Stress-test the plan**
+   - Kill broad permissions, vague ownership, missing rollback, missing validation, and unsupported production-readiness claims.
+   - Separate facts from inference.
+   - State blockers before recommendations.
 
-- 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.
+4. **Recommend minimal safe action**
+   - Prefer read-only inspection, preview, what-if, diagnostic query, cost forecast, or staged rollout before mutation.
+   - Require explicit approval for live, destructive, access, reliability, hierarchy, or billing-impacting actions.
+   - Keep the recommendation scoped and reversible where possible.
 
-Minimum scenarios this skill should handle:
+5. **Validate and hand off**
+   - Name verification targets and evidence gaps.
+   - Provide safe next actions and escalation criteria.
+   - Do not claim tenant, subscription, resource, billing, quota, or posture state that was not observed.
 
-1. read-only storage access,
-2. narrow deploy-oriented application access,
-3. custom-role fallback when built-in roles are too broad or incomplete.
+## Output contract
 
-## Safety notes
+Return:
 
-- 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.
+1. Scope and target
+2. Evidence level: documentation-based, sampled read-only evidence, user-provided evidence, repo evidence, or inference
+3. Key findings and risks
+4. Blockers or missing evidence
+5. Minimal safe next actions
+6. Verification targets
+7. Rollback, cleanup, expiry, or reversal path where applicable

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

@@ -4,8 +4,8 @@ description: Use this skill for Azure security posture review, baseline hardenin
 allowed-tools: Read Grep Glob
 metadata:
   author: github: Raishin
-  version: 0.1.0
-  updated: "2026-05-05"
+  version: 0.1.2
+  updated: "2026-06-05"
   category: security
 ---
 
@@ -39,7 +39,7 @@ Do not use this skill as a full compliance audit, incident forensics runbook, or
 
 ## 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.
+- Prefer Microsoft Learn documentation through the user's configured documentation MCP, then sampled read-only Azure evidence when available, then 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.
@@ -48,7 +48,9 @@ Do not use this skill as a full compliance audit, incident forensics runbook, or
 
 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.
+- [Azure Security Posture Hardening Operations](references/security-posture-hardening-operations.md) — use for current service behavior, common failure modes, hard design rules, verification targets, and push-back conditions.
+- [Safety checklist](references/safety-checklist.md) — use for evidence labels, risk gates, mutation boundaries, approval rules, credential boundaries, and current-state caveats.
+- [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing documentation-based evidence, sampled read-only evidence, or sanitized user evidence.
 - [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.
 

package/skills/azure/azure-security-posture-hardening/metadata.json

@@ -11,24 +11,20 @@
     "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.",
+  "summary": "Review Azure security posture with least privilege, managed identities, Key Vault hardening, private access decisions, policy guardrails, Defender recommendations, 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"
+    "https://learn.microsoft.com/azure/key-vault/general/secure-key-vault",
+    "https://learn.microsoft.com/security/benchmark/azure/baselines/key-vault-security-baseline",
+    "https://learn.microsoft.com/security/benchmark/azure/baselines/microsoft-defender-for-cloud-security-baseline",
+    "https://learn.microsoft.com/azure/defender-for-cloud/recommendations-reference-identity-access",
+    "https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/security",
+    "https://learn.microsoft.com/azure/governance/policy/overview",
+    "https://learn.microsoft.com/azure/role-based-access-control/best-practices"
   ],
-  "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",
+  "security_notes": "Do not recommend broad admin roles, stored secrets, legacy Key Vault access policies, or public exposure by default. Prefer managed identities, scoped RBAC, policy-enforced controls, private access where justified, soft delete/purge protection, and verified logging coverage.",
+  "last_verified": "2026-06-05",
   "path": "skills/azure/azure-security-posture-hardening",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.2"
 }

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

@@ -1,23 +1,21 @@
-# MCP and Evidence Path
+# MCP and evidence path
 
-## Evidence path
+Use this reference when deciding how to ground `azure-security-posture-hardening` guidance.
 
-Ground the review in this order:
+## Evidence 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.
+1. Microsoft Learn documentation through the user's configured documentation MCP for documented Azure behavior.
+2. Sampled read-only Azure evidence when the user has configured it and current-state confirmation is necessary.
+3. Sanitized user-provided evidence when no read-only evidence path is available.
+4. Clearly labeled inference when evidence is incomplete.
 
-If the evidence is incomplete, say so. Do not claim the environment is secure from design intent alone.
+## Boundaries
+
+- Documentation evidence does not prove the user's tenant, subscription, RBAC, quotas, deployed resources, billing state, security posture, reliability state, or production readiness.
+- Sampled read-only evidence proves only the sampled configured environment and time window.
+- User-provided evidence can be incomplete or stale; preserve uncertainty.
+- Never ask for credentials, tokens, secrets, tenant IDs, subscription IDs, resource IDs, customer data, private keys, or raw incident payloads.
+
+## Required phrasing
+
+Use generic phrasing such as "Microsoft Learn documentation through the user's configured documentation MCP". Do not expose internal tool names, profile names, environment names, or local identifiers in committed docs.

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

@@ -1,15 +1,26 @@
-# 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
+# Official sources
+
+Use this reference when grounding current Azure behavior for `azure-security-posture-hardening`.
+
+## Microsoft Learn sources
+
+- https://learn.microsoft.com/azure/key-vault/general/secure-key-vault
+- https://learn.microsoft.com/security/benchmark/azure/baselines/key-vault-security-baseline
+- https://learn.microsoft.com/security/benchmark/azure/baselines/microsoft-defender-for-cloud-security-baseline
+- https://learn.microsoft.com/azure/defender-for-cloud/recommendations-reference-identity-access
+- https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/security
+- https://learn.microsoft.com/azure/governance/policy/overview
+- https://learn.microsoft.com/azure/role-based-access-control/best-practices
+- https://learn.microsoft.com/azure/defender-for-cloud/secure-score-security-controls
+- https://learn.microsoft.com/azure/defender-for-cloud/concept-cloud-security-posture-management
+- https://learn.microsoft.com/azure/defender-for-cloud/review-security-recommendations
+
+## Current documentation refresh (2026-06-05)
+
+- Microsoft Learn documentation through the user's configured documentation MCP is the primary source for documented Azure behavior.
+- Documentation evidence is not live customer-state evidence. It does not prove the user's tenant, subscription, RBAC, quotas, deployed resources, billing state, security posture, or production readiness.
+- Use sampled read-only Azure evidence only when the user has configured it and the task requires current-state confirmation. Label it as sampled evidence, not broad proof.
+
+## Grounding rule
+
+Docs explain service behavior. Current-state claims require sampled read-only evidence or sanitized user-provided evidence. If current state was not queried or shown, say so.

package/skills/azure/azure-security-posture-hardening/references/safety-checklist.md

@@ -0,0 +1,24 @@
+# Safety checklist
+
+Use before recommending production Azure changes, access grants, security remediation, hierarchy moves, cost actions, reliability changes, or readiness conclusions for `azure-security-posture-hardening`.
+
+## Non-negotiables
+
+- Do not ask for or print credentials, client secrets, certificates, private keys, access tokens, tenant IDs, subscription IDs, resource IDs, customer data, raw incident payloads, or environment-specific identifiers.
+- Prefer Microsoft Learn documentation through the user's configured documentation MCP for documented Azure behavior.
+- Use sampled read-only Azure evidence only for current-state claims and label it as sampled evidence.
+- Require explicit approval before recommending live mutation, broad access, destructive remediation, billing changes, commitment purchases, hierarchy moves, failover, failback, or alert suppression.
+- Keep recommendations least-privilege, reversible where possible, and scoped to the named resource or workload.
+- Separate documentation-based claims, sampled evidence, user-provided evidence, and inference.
+
+## Component risks
+
+- **Identity and roles:** broad privileged roles, direct user grants, wildcard custom roles, missing PIM/time-bound controls, inherited scope surprises.
+- **Security posture:** stored secrets, public exposure, missing managed identities, weak Key Vault boundaries, no diagnostic coverage, untracked policy exemptions.
+- **Resource organization:** flat hierarchy drift, fake isolation via resource groups, subscription sprawl, weak ownership, policy inheritance surprises.
+- **Cost:** optimizing recommendations without workload context, deleting resources without owner confirmation, buying commitments before rightsizing, ignoring licensing and reliability cost tradeoffs.
+- **Reliability:** vague SLOs, untested recovery, overengineered topology, missing health model, no dependency mapping, unvalidated chaos or failover assumptions.
+
+## Evidence labels
+
+Use `documentation-based`, `sampled read-only evidence`, `repo evidence`, `user-provided evidence`, or `inference`. Documentation alone never proves the user's live Azure environment.

package/skills/azure/azure-security-posture-hardening/references/security-posture-hardening-operations.md

@@ -0,0 +1,69 @@
+# Azure Security Posture Hardening Operations
+
+> Version note: Azure service behavior and tooling change over time. Verify exact command syntax, permissions, and feature availability against Microsoft Learn documentation through the user's configured documentation MCP before production use. Do not paste secrets or sensitive identifiers into commands, files, or chat.
+
+Use this reference for current, source-grounded service behavior and the hard review gates that the lean `SKILL.md` intentionally does not carry.
+
+## What people get wrong
+
+- Calling a workload hardened because it has a Key Vault.
+- Using stored service-principal secrets when managed identities are supported.
+- Keeping Key Vault public access or legacy access policies without justification.
+- Treating Defender recommendations as optional noise instead of risk signals to triage.
+- Skipping diagnostics and audit logs until after an incident.
+
+## Officially grounded service shape
+
+- Microsoft Learn Key Vault guidance implements Zero Trust principles: verify explicitly, use least privilege, and assume breach.
+- Key Vault hardening includes one vault per application/region/environment where appropriate, private access or firewall controls, Azure RBAC over legacy access policies for critical workloads, PIM for privileged operations, soft delete, purge protection, rotation, logging, Defender, policy enforcement, and backup/recovery testing.
+- Security baselines call out managed identities, Azure Policy audit/deny/deploy-if-not-exists effects, Defender for Cloud monitoring, conditional access where supported, and secure storage of credentials in Key Vault.
+- Documentation-based security recommendations do not prove the user has enabled these controls. Current-state posture needs sampled read-only evidence.
+
+Documentation evidence proves documented Azure service behavior. It does not prove the user's tenant, subscription, RBAC, quotas, deployed resources, billing state, security posture, or production readiness.
+
+## Non-negotiable design rules
+
+- Prefer managed identities over stored secrets where the service supports them.
+- Use Azure RBAC, least privilege, and PIM/time-bound elevation for privileged operations.
+- Disable public exposure or restrict network access where workload requirements allow it.
+- Require diagnostic logs, alerts, and policy compliance evidence before calling posture audit-ready.
+- Stage remediation and avoid broad production changes without rollback and owner approval.
+
+## Minimal safe implementation flow
+
+- Scope workload, data sensitivity, identities, secrets, public exposure, policies, logging, and production impact.
+- Collect documentation requirements and sampled posture evidence when available.
+- Classify gaps by identity, network, secret lifecycle, policy, monitoring, and backup/recovery risk.
+- Prioritize reversible least-privilege remediations before disruptive controls.
+- Return hardened target state, blockers, safe rollout sequence, verification checks, and residual risk.
+
+## High-risk assumptions to kill
+
+- Secure score equals production readiness; it is an input, not a substitute for owner-reviewed risk acceptance.
+- A Defender recommendation is false positive noise until triaged; unreviewed recommendations are unbounded risk debt.
+- Enabling a paid plan, policy, or deny effect is automatically safe; it can affect cost, deployment paths, and operations.
+- A Key Vault exists, therefore secrets are safe; network access, RBAC model, purge protection, diagnostics, and rotation still matter.
+- Documentation guidance proves current posture; it only proves documented service behavior unless sampled evidence confirms the environment.
+
+## Safe command/code verification targets
+
+- Query Defender secure score controls and recommendations read-only, then label results as sampled current-state evidence.
+- Review policy assignments, exemptions, and compliance states before recommending deny or deploy-if-not-exists effects.
+- Inspect identity usage, Key Vault access model, network settings, soft delete, purge protection, rotation, and diagnostic settings without exposing secrets.
+- Verify log destinations and alert ownership; an enabled diagnostic setting with no owner is not audit readiness.
+- Separate documentation evidence, sampled read-only evidence, and sanitized user evidence in the final verdict.
+
+## Safe verification targets
+
+- Managed identities or approved credential model are used for service access.
+- Key Vault RBAC, network controls, soft delete, purge protection, rotation, and diagnostics match sensitivity.
+- Policy assignments or Defender recommendations cover required controls and exemptions are justified.
+- Audit logs and alerts reach an owned destination.
+- Remediation has rollback or staged deployment plan.
+
+## When to push back
+
+- The user wants public access because private networking is inconvenient.
+- The plan stores credentials in repo, pipeline files, or app settings without a secure reference.
+- The request skips logging or Defender/Policy evidence.
+- The remediation would break production without staged validation.

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

@@ -1,96 +1,41 @@
-# Workflow and Output Contract
+# 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.
+Use this reference for full execution of `azure-security-posture-hardening`.
 
-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.
+## Workflow
 
-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.
+1. **Classify the request**
+   - Identify service/domain, resource scope, environment, production impact, and whether mutation or billing impact is requested.
+   - Identify whether the task needs documentation-only guidance, sampled read-only current-state evidence, or sanitized user evidence.
 
-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.
+2. **Ground in current sources**
+   - Prefer Microsoft Learn documentation through the user's configured documentation MCP.
+   - Read the component operations guide before issuing design, safety, or readiness conclusions.
+   - Treat current-state claims as unproven unless supported by sampled read-only evidence or sanitized user-provided evidence.
 
-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.
+3. **Stress-test the plan**
+   - Kill broad permissions, vague ownership, missing rollback, missing validation, and unsupported production-readiness claims.
+   - Separate facts from inference.
+   - State blockers before recommendations.
 
-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.”
+4. **Recommend minimal safe action**
+   - Prefer read-only inspection, preview, what-if, diagnostic query, cost forecast, or staged rollout before mutation.
+   - Require explicit approval for live, destructive, access, reliability, hierarchy, or billing-impacting actions.
+   - Keep the recommendation scoped and reversible where possible.
 
-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.
+5. **Validate and hand off**
+   - Name verification targets and evidence gaps.
+   - Provide safe next actions and escalation criteria.
+   - Do not claim tenant, subscription, resource, billing, quota, or posture state that was not observed.
 
 ## 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
+Return:
 
-- 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.
+1. Scope and target
+2. Evidence level: documentation-based, sampled read-only evidence, user-provided evidence, repo evidence, or inference
+3. Key findings and risks
+4. Blockers or missing evidence
+5. Minimal safe next actions
+6. Verification targets
+7. Rollback, cleanup, expiry, or reversal path where applicable

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

@@ -4,8 +4,8 @@ description: Use this skill for Azure management-group hierarchy, subscription p
 allowed-tools: Read Grep Glob
 metadata:
   author: github: Raishin
-  version: 0.1.0
-  updated: "2026-05-05"
+  version: 0.1.2
+  updated: "2026-06-05"
   category: compliance
 ---
 
@@ -17,11 +17,10 @@ Act as a ruthless Azure resource-organization architect. Your job is to stop wea
 
 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.
+- Prefer Microsoft Learn documentation through the user's configured documentation MCP, then sampled read-only Azure evidence when available, then sanitized user evidence.
 - 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.
+- Do not hard-code tenant names, management-group names, subscription IDs, resource-group names, or organizational structure unless the user provides them as confirmed context.
 
 ## Trigger Situations
 
@@ -37,7 +36,7 @@ Use this skill when the user asks to:
 
 ## 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.
+- Prefer Microsoft Learn documentation through the user's configured documentation MCP, then sampled read-only Azure evidence when available, then 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.
@@ -46,7 +45,9 @@ Use this skill when the user asks to:
 
 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.
+- [Azure Subscription Resource Organization Operations](references/subscription-resource-organization-operations.md) — use for current service behavior, common failure modes, hard design rules, verification targets, and push-back conditions.
+- [Safety checklist](references/safety-checklist.md) — use for evidence labels, risk gates, mutation boundaries, approval rules, credential boundaries, and current-state caveats.
+- [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing documentation-based evidence, sampled read-only evidence, or sanitized user evidence.
 - [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.
 

package/skills/azure/azure-subscription-resource-organization/metadata.json

@@ -11,21 +11,20 @@
     "kiro",
     "other"
   ],
-  "summary": "Design and review Azure management-group, subscription, and resource-group boundaries with explicit governance, ownership, and landing-zone operating-model consequences.",
+  "summary": "Design and review Azure management-group, subscription, and resource-group boundaries with explicit governance, ownership, policy inheritance, scale-unit, and landing-zone operating-model consequences.",
   "source_type": "original",
   "official_docs": [
-    "https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-areas",
-    "https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/",
-    "https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/resource-org",
-    "https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/resource-org-management-groups",
-    "https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/governance",
-    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/",
-    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/subscription",
-    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/resource-group"
+    "https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/resource-org",
+    "https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/resource-org-management-groups",
+    "https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/resource-org-subscriptions",
+    "https://learn.microsoft.com/azure/cloud-adoption-framework/ready/azure-setup-guide/organize-resources",
+    "https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/management-application-environments",
+    "https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/governance",
+    "https://learn.microsoft.com/training/modules/design-governance/"
   ],
-  "security_notes": "Do not recommend flat hierarchies, fake isolation via resource groups, or subscription moves without proving governance, ownership, policy inheritance, and operational blast-radius implications.",
-  "last_verified": "2026-04-27",
+  "security_notes": "Do not recommend flat hierarchies, fake isolation via resource groups, or subscription moves without proving governance, ownership, policy inheritance, RBAC, cost, quota, and operational blast-radius implications.",
+  "last_verified": "2026-06-05",
   "path": "skills/azure/azure-subscription-resource-organization",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.2"
 }