@raishin/vanguard-frontier-agentic 2.8.0 → 2.10.0

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

@@ -1,79 +1,41 @@
-# Workflow and Output Contract
+# Workflow and output contract
 
-## Safe Workflow
+Use this reference for full execution of `azure-resource-health-incident-triage`.
 
-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.
+## Workflow
 
-## Role-Specific Stress Checks
+1. **Classify the request**
+   - Identify service/domain, resource scope, environment, production impact, and whether mutation is requested.
+   - Identify whether the task needs documentation-only guidance, sampled read-only current-state evidence, or sanitized user evidence.
 
-- 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.
+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.
 
-## Output Template
+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.
 
-```markdown
-# Azure Health Triage: <scope>
+4. **Recommend minimal safe action**
+   - Prefer read-only inspection, preview, what-if, dry run, diagnostic query, or staged rollout before mutation.
+   - Require explicit approval for live or destructive actions.
+   - Keep the recommendation scoped and reversible where possible.
 
-## 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
+5. **Validate and hand off**
+   - Name verification targets and evidence gaps.
+   - Provide safe next actions and escalation criteria.
+   - Do not claim tenant, subscription, resource, quota, or incident state that was not observed.
 
-## Incident frame
-- Affected scope:
-- Subscription or resource group:
-- Region:
-- Resource(s):
-- Symptom:
-- Reported start time:
+## Output contract
 
-## Health evidence
-| Signal | Finding | Time window | Evidence type | What it proves | What it does not prove |
-|---|---|---|---|---|---|
+Return:
 
-## 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.
+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, or reversal path where applicable

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

@@ -4,8 +4,8 @@ description: Use this skill when the user asks which Azure role to assign, how t
 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
 ---
 
@@ -30,7 +30,7 @@ Do not use this skill for tenant-wide governance design, access review programs,
 
 ## 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.
@@ -39,7 +39,9 @@ Do not use this skill for tenant-wide governance design, access review programs,
 
 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 Role Selection Operations](references/role-selection-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-role-selector/metadata.json

@@ -14,15 +14,17 @@
   "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/"
+    "https://learn.microsoft.com/azure/role-based-access-control/overview",
+    "https://learn.microsoft.com/azure/role-based-access-control/best-practices",
+    "https://learn.microsoft.com/azure/role-based-access-control/built-in-roles",
+    "https://learn.microsoft.com/azure/role-based-access-control/role-definitions",
+    "https://learn.microsoft.com/azure/role-based-access-control/custom-roles",
+    "https://learn.microsoft.com/azure/role-based-access-control/role-assignments-steps",
+    "https://learn.microsoft.com/azure/role-based-access-control/scope-overview"
   ],
-  "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",
+  "security_notes": "Prefer built-in job-function roles before custom roles, minimize assignment scope, separate control-plane and data-plane permissions, and do not default to Owner, Contributor, or wildcard custom roles for routine access requests.",
+  "last_verified": "2026-06-05",
   "path": "skills/azure/azure-role-selector",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.2"
 }

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

@@ -1,12 +1,21 @@
-# MCP and Evidence Path
+# MCP and evidence path
 
-## Evidence path
+Use this reference when deciding how to ground `azure-role-selector` guidance.
 
-Ground recommendations in Microsoft documentation first.
+## Evidence order
 
-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.
+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 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.
+## 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-role-selector/references/official-sources.md

@@ -1,18 +1,25 @@
-# Official Sources
+# Official sources
 
-Load these only when needed:
+Use this reference when grounding current Azure behavior for `azure-role-selector`.
 
-- [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.
+## Microsoft Learn sources
 
-## Grounded insights worth carrying into the skill
+- https://learn.microsoft.com/azure/role-based-access-control/overview
+- https://learn.microsoft.com/azure/role-based-access-control/best-practices
+- https://learn.microsoft.com/azure/role-based-access-control/built-in-roles
+- https://learn.microsoft.com/azure/role-based-access-control/role-definitions
+- https://learn.microsoft.com/azure/role-based-access-control/custom-roles
+- https://learn.microsoft.com/azure/role-based-access-control/role-assignments-steps
+- https://learn.microsoft.com/azure/role-based-access-control/scope-overview
+- https://learn.microsoft.com/azure/role-based-access-control/role-assignments-steps#step-2-select-the-appropriate-role
+- https://learn.microsoft.com/azure/role-based-access-control/rbac-and-directory-admin-roles
 
-- 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.
+## 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-role-selector/references/role-selection-operations.md

@@ -0,0 +1,69 @@
+# Azure Role Selection 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
+
+- Starting from Owner or Contributor instead of required actions.
+- Ignoring the difference between control-plane Actions and data-plane DataActions.
+- Using a custom role when a narrower built-in role already fits.
+- Assigning at subscription scope when resource or resource-group scope is enough.
+- Using wildcard custom-role permissions that can expand with future provider operations.
+
+## Officially grounded service shape
+
+- Microsoft Learn evidence says Azure built-in roles expose Actions, NotActions, DataActions, and NotDataActions so reviewers can compare required permissions against role definitions.
+- Role selection guidance says start with job-function roles, review service categories, choose the most restrictive role, and create a custom role only when no suitable built-in role exists.
+- Control-plane authorization is handled through Azure Resource Manager, while data-plane authorization is handled by a resource provider or Azure Resource Manager depending on service behavior.
+- Custom roles can include data actions, but roles with DataActions cannot be assigned at management group scope. Microsoft recommends explicit permissions instead of wildcards.
+
+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
+
+- Start from required operations, target resource, principal type, and duration.
+- Separate management-plane and data-plane access before selecting a role.
+- Prefer built-in job-function roles and narrow scope before custom roles.
+- Use custom roles only with explicit Actions/DataActions and documented assignable scopes.
+- Require a removal, expiry, or review path for the assignment.
+
+## Minimal safe implementation flow
+
+- Capture principal, target resource, operations, data access, environment, and duration.
+- Map operations to resource provider actions and service built-in roles.
+- Choose the narrowest role and scope; add data-plane role separately if required.
+- If no built-in role fits, design an explicit custom role with narrow assignable scopes.
+- Return selected role, scope, evidence level, risks, validation checks, and cleanup path.
+
+## High-risk assumptions to kill
+
+- A built-in role name alone proves least privilege; it does not unless its Actions/DataActions match the requested operations.
+- Contributor is acceptable temporary access; temporary broad access still expands blast radius and needs expiry, approval, and removal evidence.
+- Management-plane access includes data access; many services require separate data-plane roles or provider-specific authorization.
+- Management group scope is a harmless convenience; data-action roles cannot be assigned there and broad inheritance is hard to unwind.
+- A wildcard custom role is future-proof; it can silently expand when resource providers add operations.
+
+## Safe command/code verification targets
+
+- Inspect candidate role definitions with read-only role-definition commands or SDK calls and compare required Actions/DataActions to the task.
+- List existing role assignments only at the proposed narrow scope and confirm no broader standing assignment already covers the same principal.
+- Check whether the requested operation is management-plane, data-plane, or both before recommending one role.
+- For custom-role drafts, lint JSON, require explicit permissions, confirm assignable scopes, and reject wildcard permissions unless Microsoft documentation proves no safer option.
+- Treat Microsoft Learn documentation as service-behavior evidence; treat read-only authorization queries as sampled current-state evidence only.
+
+## Safe verification targets
+
+- Role definition contains only needed Actions/DataActions for the task.
+- Assignment scope is no broader than the named resource set.
+- Privileged administrator roles are avoided or explicitly justified.
+- Custom role avoids wildcard permissions and has bounded assignable scopes.
+- Access can be tested and removed without broad collateral impact.
+
+## When to push back
+
+- The user asks for Owner/Contributor because it is faster.
+- The request mixes management-plane and data-plane access without naming both.
+- The custom role depends on wildcard permissions.
+- The target scope is broader than the requested task.

package/skills/azure/azure-role-selector/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-role-selector`.
+
+## 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-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.