@raishin/vanguard-frontier-agentic 2.8.0 → 2.10.0

package/skills/azure/azure-live-pim-jit-activation-guard/metadata.json

@@ -11,17 +11,19 @@
     "kiro",
     "other"
   ],
-  "summary": "Gate Entra ID PIM eligible role activations with justification, MFA, ticket binding, time-bound scope, and approval workflow gates before any privileged Azure role becomes active.",
+  "summary": "Gate Microsoft Entra PIM eligible role activations with justification, MFA, reduced scope, ticket binding, time-bound duration, approval workflow checks, and cache/propagation caveats.",
   "source_type": "original",
   "official_docs": [
-    "https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-deployment-plan",
-    "https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-resource-roles-configure-role-settings",
-    "https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-how-to-activate-role",
-    "https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure-azure-ad-roles"
+    "https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-configure",
+    "https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-resource-roles-activate-your-roles",
+    "https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-resource-roles-configure-role-settings",
+    "https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-resource-roles-approval-workflow",
+    "https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-deployment-plan",
+    "https://learn.microsoft.com/entra/identity/role-based-access-control/best-practices"
   ],
-  "security_notes": "Never activate a PIM role without justification, ticket reference, and MFA confirmation. An agent cannot activate another user's PIM role on their behalf \u2014 only the eligible principal may submit. Requires Entra ID P2 or equivalent license.",
-  "last_verified": "2026-04-30",
+  "security_notes": "Never activate or approve PIM privileged access without confirming eligible principal, scope, role, activation duration, MFA/Conditional Access requirement, justification or ticket, approval status, and deactivation/expiry behavior.",
+  "last_verified": "2026-06-05",
   "path": "skills/azure/azure-live-pim-jit-activation-guard",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.6"
 }

package/skills/azure/azure-live-pim-jit-activation-guard/references/mcp-and-evidence.md

@@ -0,0 +1,22 @@
+# Documentation and Evidence Path
+
+## Preferred evidence order
+
+1. Microsoft Learn documentation through the user's configured documentation MCP for documented Azure behavior.
+2. Sampled read-only Azure evidence, when safely available, for current configured-environment observations.
+3. Sanitized user-provided evidence.
+4. Clearly labeled inference.
+
+## What each evidence type can prove
+
+- Microsoft Learn documentation can prove documented service behavior, supported concepts, limitations, and recommended patterns.
+- Sampled read-only evidence can prove the sampled configured state at the time observed.
+- Sanitized user evidence can prove only what the snippet shows.
+- None of these alone prove broad regional availability, future success, full account posture, or production readiness.
+
+## Safe usage pattern
+
+- State whether each claim is documentation-based, sampled-current-state, user-provided, or inference.
+- Use read-only queries before recommending changes.
+- Do not include sensitive internal identifiers, tenant identifiers, subscription identifiers, or secrets in committed docs or final findings.
+- If no sampled evidence is available, say the review is documentation-based and list the exact evidence still needed.

package/skills/azure/azure-live-pim-jit-activation-guard/references/official-sources.md

@@ -1,13 +1,26 @@
-# Official Sources: Azure Live PIM JIT Activation Guard
+# Official Sources
 
-## Privileged Identity Management
+Use these sources to ground the skill. Microsoft Learn documentation proves documented Azure behavior; it does not prove the user's tenant, subscription, RBAC, quota, migration project, network, telemetry, deployed resources, or production readiness.
 
-- https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-how-to-activate-role
-- https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure
-- https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-resource-roles-overview
-- https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-apis
+## Primary Microsoft Learn sources
 
-## Source-grounding rule
+- https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-configure
+- https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-resource-roles-activate-your-roles
+- https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-resource-roles-configure-role-settings
+- https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-resource-roles-approval-workflow
+- https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-deployment-plan
+- https://learn.microsoft.com/entra/identity/role-based-access-control/best-practices
 
-Use official Microsoft Learn documentation as the source of truth for PIM behavior.
-PIM API versions change — verify the API version parameter in all Graph API calls against current docs.
+## Grounding notes
+
+- Documentation-based claim: Microsoft Learn evidence says PIM provides just-in-time, time-bound, approval-based privileged access for Microsoft Entra and Azure resources. Azure resource role activation can require MFA, reduced scope, start time, duration, and reason; approval can leave a request pending. PIM temporarily adds active assignment and later removes it, but applications can cache role state so access changes may not appear immediately.
+- Current-state claim: requires sampled read-only Azure evidence or sanitized user-provided evidence.
+- Inference: allowed only when labeled and tied to observed fields or documented behavior.
+- Do not include sensitive internal identifiers or secret material in findings.
+
+## Source use rules
+
+- Prefer Microsoft Learn documentation through the user's configured documentation MCP for current Azure service behavior.
+- Use sampled read-only Azure evidence only to validate current configured-environment observations.
+- If documentation and sampled evidence appear to conflict, report both and stop short of a production-ready verdict.
+- Re-check official sources before changing high-risk guidance, because cloud behavior and feature availability can change.

package/skills/azure/azure-live-pim-jit-activation-guard/references/permission-model.md

@@ -27,7 +27,7 @@ Preferred model:
   ],
   "NotActions": [],
   "AssignableScopes": [
-    "/subscriptions/<SUBSCRIPTION_ID>"
+    "$APPROVED_AZURE_SCOPE"
   ]
 }
 ```
@@ -54,3 +54,5 @@ Use Conditional Access + time-bounded Entra ID Group membership via Access Packa
 - Standing `Owner` at subscription scope
 - Standing `User Access Administrator` (allows arbitrary role assignments)
 - `Microsoft.Authorization/roleAssignments/write` to non-PIM principals
+
+Use exact resource scopes from approved change records; do not paste raw subscription identifiers into chat.

package/skills/azure/azure-live-pim-jit-activation-guard/references/pim-jit-activation-operations.md

@@ -0,0 +1,68 @@
+# Azure PIM JIT Activation Operations
+
+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
+
+- Treating eligible assignment as active access.
+- Activating the broadest eligible scope instead of reducing scope to the actual resource needed.
+- Skipping justification, ticket, MFA, or approval because the task is urgent.
+- Assuming deactivation instantly removes access from every downstream application cache.
+- Trying to activate another user’s eligible role from an agent context.
+
+## Officially grounded service shape
+
+Microsoft Learn evidence says PIM provides just-in-time, time-bound, approval-based privileged access for Microsoft Entra and Azure resources. Azure resource role activation can require MFA, reduced scope, start time, duration, and reason; approval can leave a request pending. PIM temporarily adds active assignment and later removes it, but applications can cache role state so access changes may not appear immediately.
+
+- PIM role settings are configured per role and per resource.
+- Eligible members activate roles only when needed and within configured maximum duration.
+- Activation can require MFA, justification, ticket information, Conditional Access, and approval.
+- Users can view pending requests, cancel pending requests, and deactivate active assignments subject to timing rules.
+- PIM audit and notification signals are part of the control, not optional decoration.
+
+## Non-negotiable design rules
+
+- Confirm the eligible principal is the requester or authorized approver; do not impersonate activation.
+- Require the narrowest scope, shortest duration, and explicit business reason.
+- Require approval state before treating access as usable.
+- Document cache and sign-out/sign-in caveats for access add/remove.
+- Refuse activation when target scope, role, principal, approval, or rollback/deactivation path is ambiguous.
+
+## Minimal safe implementation flow
+
+- Scope principal, role, resource scope, duration, approval workflow, and task ticket.
+- Collect read-only evidence of eligibility, current active assignments, PIM role settings, and request status.
+- Check MFA, Conditional Access, approval, justification, and reduced-scope requirements.
+- If mutation is requested, require explicit user approval before activation, approval, cancellation, or deactivation.
+- Verify request status, active assignment, expiry time, audit evidence, and deactivation plan.
+
+## High-risk assumptions to kill
+
+- Eligible does not mean active. Do not treat an eligible assignment as usable access until request status proves activation or approval state.
+- PIM activation is not a way for an agent to impersonate another human; the eligible principal or authorized approver boundary must remain explicit.
+- Broad management-group or subscription activation is not justified when a narrower resource scope satisfies the task.
+- Deactivation is not an instant proof of downstream access removal because applications can cache role state.
+- Approval, MFA, justification, ticket, and duration controls are not paperwork; they are the evidence that privileged access was bounded.
+
+## Safe command/code verification targets
+
+- Verify eligible assignment, active assignment, request status, role settings, approval requirement, MFA requirement, and maximum duration before any activation path.
+- Check reduced scope and shortest viable duration before submitting or approving an activation.
+- Capture request state as pending, approved, active, denied, canceled, expired, or deactivated; do not infer it from intent.
+- Verify audit evidence and expiry/deactivation plan after activation.
+- State access-cache and sign-out/sign-in caveats whenever access add/remove is part of the verdict.
+
+## Safe verification targets
+
+- Eligible assignment exists for the requested principal and scope.
+- Activation duration is within policy and no broader than operational need.
+- MFA/approval/justification/ticket controls are satisfied where required.
+- Audit or request status proves pending, active, denied, canceled, expired, or deactivated state.
+- Access-cache caveat and sign-out/sign-in mitigation are stated.
+
+## When to push back
+
+- The user asks the agent to activate someone else’s role.
+- Scope or role is broader than the task requires.
+- Approval workflow is bypassed or approval owner is unclear.
+- The user needs permanent access but calls it JIT.

package/skills/azure/azure-live-pim-jit-activation-guard/references/preflight-commands.md

@@ -2,6 +2,10 @@
 
 Run these before initiating or approving a PIM activation.
 
+## Evidence-variable convention
+
+Shell variables in examples are local operator placeholders from an approved change record or already configured shell context. Do not commit real values, and redact them from shared evidence unless disclosure is explicitly approved.
+
 ## 1. Confirm current principal identity
 
 ```bash
@@ -14,16 +18,16 @@ az ad signed-in-user show --query "{displayName:displayName, id:id, userPrincipa
 ```bash
 # Using Azure CLI
 az role eligibility-schedule list \
-  --scope "/subscriptions/<SUBSCRIPTION_ID>" \
-  --query "[?principalId=='<PRINCIPAL_ID>'].{roleName:roleDefinitionDisplayName, scope:scope, endDateTime:endDateTime}"
+  --scope "$APPROVED_AZURE_SCOPE" \
+  --query "[?principalId=='$PRINCIPAL_OBJECT_ID'].{roleName:roleDefinitionDisplayName, scope:scope, endDateTime:endDateTime}"
 ```
 
 ## 3. List active role assignments (not eligible — currently active)
 
 ```bash
 az role assignment list \
-  --assignee <PRINCIPAL_ID_OR_UPN> \
-  --scope "/subscriptions/<SUBSCRIPTION_ID>" \
+  --assignee $PRINCIPAL_LOOKUP_VALUE \
+  --scope "$APPROVED_AZURE_SCOPE" \
   --query "[].{role:roleDefinitionName, scope:scope, principalType:principalType}"
 ```
 
@@ -31,7 +35,7 @@ az role assignment list \
 
 ```bash
 az role assignment schedule request list \
-  --scope "/subscriptions/<SUBSCRIPTION_ID>" \
+  --scope "$APPROVED_AZURE_SCOPE" \
   --query "[?status=='PendingApproval' || status=='PendingAdminDecision'].{requestId:name, role:roleDefinitionDisplayName, requestor:requestorId, justification:justification}"
 ```
 

package/skills/azure/azure-live-pim-jit-activation-guard/references/rollback-playbook.md

@@ -1,18 +1,22 @@
 # Rollback Playbook: Azure Live PIM JIT Activation Guard
 
+## Evidence-variable convention
+
+Shell variables in examples are local operator placeholders from an approved change record or already configured shell context. Do not commit real values, and redact them from shared evidence unless disclosure is explicitly approved.
+
 ## Deactivate an active PIM role assignment immediately
 
 ```bash
 # Find the active role assignment schedule instance to cancel
 az role assignment schedule list \
-  --scope "/subscriptions/<SUBSCRIPTION_ID>" \
-  --query "[?assignedTo=='<PRINCIPAL_ID>'].{id:name, role:roleDefinitionDisplayName, endDateTime:endDateTime}"
+  --scope "$APPROVED_AZURE_SCOPE" \
+  --query "[?assignedTo=='$PRINCIPAL_OBJECT_ID'].{id:name, role:roleDefinitionDisplayName, endDateTime:endDateTime}"
 
 # Submit a deactivation request
 az role assignment schedule request create \
-  --scope "/subscriptions/<SUBSCRIPTION_ID>" \
-  --role-definition-id <ROLE_DEF_ID> \
-  --principal-id <PRINCIPAL_ID> \
+  --scope "$APPROVED_AZURE_SCOPE" \
+  --role-definition-id $ROLE_DEFINITION_ID \
+  --principal-id $PRINCIPAL_OBJECT_ID \
   --request-type SelfDeactivate
 ```
 
@@ -30,9 +34,9 @@ Body: { "properties": { "status": "Denied", "justification": "<reason>" } }
 ```bash
 # Remove the active role assignment
 az role assignment delete \
-  --assignee <PRINCIPAL_ID> \
-  --role <ROLE_NAME> \
-  --scope "/subscriptions/<SUBSCRIPTION_ID>"
+  --assignee $PRINCIPAL_OBJECT_ID \
+  --role $ROLE_DEFINITION_NAME \
+  --scope "$APPROVED_AZURE_SCOPE"
 ```
 
 After revoking, immediately review Azure Monitor activity log for actions taken

package/skills/azure/azure-live-pim-jit-activation-guard/references/safety-checklist.md

@@ -0,0 +1,28 @@
+# Safety Checklist
+
+## Evidence labels
+
+- `documentation-based`: grounded in Microsoft Learn or listed official documentation.
+- `sampled-current-state`: grounded in read-only Azure observations from the user's configured tools.
+- `user-provided`: grounded in sanitized snippets supplied by the user.
+- `inference`: reasoned from evidence but not directly proven.
+
+## Mutation boundary
+
+- Default to read-only review.
+- Do not perform create, update, delete, activate, approve, cancel, deactivate, migrate, cut over, route, peer, deploy, alert, suppress, or configuration changes unless the user explicitly asks and approval is clear.
+- Prefer preview, assessment, status, list, show, query, activity-log, dependency, and diagnostic evidence before any mutation.
+
+## Credential and data boundary
+
+- Never ask users to paste credentials, tokens, tenant IDs, subscription IDs, customer data, private keys, appliance secrets, migration inventory dumps, log payload secrets, or raw environment dumps.
+- Summarize sensitive evidence by field presence, control state, and risk; do not reproduce secret material.
+
+## Risk gates
+
+- Stop on ambiguous target, ambiguous principal, missing approval, missing owner, missing rollback, stale assessment, incomplete dependency mapping, unclear routing, or missing telemetry for high-impact assets.
+- Separate documented product behavior from sampled configured-environment evidence.
+
+## Asset-specific hard line
+
+Never activate or approve PIM privileged access without confirming eligible principal, scope, role, activation duration, MFA/Conditional Access requirement, justification or ticket, approval status, and deactivation/expiry behavior.

package/skills/azure/azure-live-pim-jit-activation-guard/references/workflow-and-output.md

@@ -0,0 +1,30 @@
+# Workflow and Output Contract
+
+## Execution flow
+
+1. Scope the exact target, environment boundary, owner, requested decision, and evidence available.
+2. Load `official-sources.md`, then the component operations guide for service behavior and risk gates.
+3. Gather sampled read-only evidence only when available and safe.
+4. Compare observed posture against documented behavior, least-privilege expectations, and operational safety rules.
+5. Return a verdict with evidence level, blockers, safe next actions, and open questions.
+
+## Required output
+
+- `verdict`: pass, warn, fail, or blocked.
+- `evidence_level`: documentation-based, sampled-current-state, user-provided, inference, or mixed.
+- `scope`: what was reviewed and what was not reviewed.
+- `blockers`: issues that prevent a safe or production-ready conclusion.
+- `findings`: severity-labeled risks with source labels.
+- `safe_next_actions`: reversible actions first; mutation only with explicit approval.
+- `open_questions`: missing facts that would change the verdict.
+
+## Stress checks
+
+- What assumption would make this recommendation unsafe?
+- Which identity, migration, network, telemetry, route, or dispatch decision has the largest blast radius?
+- What evidence would disprove the claimed readiness?
+- Is the answer accidentally treating documentation as configured-environment proof?
+
+## Response discipline
+
+Use Microsoft Learn documentation through the user's configured documentation MCP for documented Azure behavior. Use sampled read-only Azure evidence only for current configured-environment observations and label it as sampled evidence.

package/skills/azure/azure-maestro/SKILL.md

@@ -4,8 +4,8 @@ description: Use this skill to classify a user task, select the right Azure spec
 allowed-tools: Agent Skill Read Grep Glob
 metadata:
   author: github: Raishin
-  version: 0.1.0
-  updated: "2026-05-05"
+  version: 0.1.2
+  updated: "2026-06-05"
   category: ai
 ---
 
@@ -106,9 +106,19 @@ Mode: parallel (2 specialists)
 
 When any part of the task touches a live-guard agent, STOP before dispatching. Apply the live-guard gate protocol below.
 
+## References
+
+Load these only when needed:
+
+- [Azure Maestro Routing Operations](references/maestro-routing-operations.md) — use for current routing behavior, common failure modes, hard design rules, verification targets, and push-back conditions.
+- [Safety checklist](references/safety-checklist.md) — use for evidence labels, live-guard gates, dispatch boundaries, approval rules, and credential boundaries.
+- [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing documentation-based evidence, sampled read-only evidence, or sanitized user evidence.
+- [Official sources](references/official-sources.md) — use when you need the detailed Microsoft documentation list or source notes.
+- [Workflow and output contract](references/workflow-and-output.md) — execution flow and final response contract.
+
 ## Live-Guard Gate Protocol
 
-The following six agents are live-guard agents. They can mutate live production infrastructure. They must NEVER be auto-dispatched.
+The following seven agents are live-guard agents. They can mutate live production infrastructure. They must NEVER be auto-dispatched.
 
 | Live-Guard Agent | Production Mutation |
 |-----------------|---------------------|
@@ -117,6 +127,7 @@ The following six agents are live-guard agents. They can mutate live production
 | `azure-live-arm-deployment-stack-guard-agent` | Live ARM deployment stack apply or modify |
 | `azure-live-cost-budget-action-guard-agent` | Live cost budget action trigger |
 | `azure-live-keyvault-rotation-purge-guard-agent` | Live Key Vault secret rotation or purge |
+| `azure-live-entra-role-assignment-guard-agent` | Live permanent Entra ID or Azure RBAC role assignment |
 | `azure-live-pim-jit-activation-guard-agent` | Live PIM/JIT privileged role activation |
 
 **Gate steps — complete all three before dispatching any live-guard agent:**

package/skills/azure/azure-maestro/metadata.json

@@ -11,18 +11,18 @@
     "kiro",
     "other"
   ],
-  "summary": "Route Azure tasks to the narrowest specialist or team of specialists from the 30-agent catalog. Classifies by domain, dispatches single or parallel (max 4), and enforces live-guard gate for production-change agents.",
+  "summary": "Route Azure tasks to the narrowest specialist or bounded specialist team from the Azure catalog, with strict live-guard gates for production-change agents and no stale hard-coded catalog counts.",
   "source_type": "adapted",
   "official_docs": [
-    "https://learn.microsoft.com/en-us/azure/",
-    "https://learn.microsoft.com/en-us/azure/architecture/",
-    "https://learn.microsoft.com/en-us/azure/well-architected/",
-    "https://learn.microsoft.com/en-us/azure/role-based-access-control/overview",
-    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/overview"
+    "https://learn.microsoft.com/azure/architecture/",
+    "https://learn.microsoft.com/azure/well-architected/",
+    "https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-areas",
+    "https://learn.microsoft.com/azure/role-based-access-control/best-practices",
+    "https://learn.microsoft.com/azure/azure-monitor/fundamentals/overview"
   ],
-  "security_notes": "Live-guard gate is non-negotiable: never auto-dispatch live-guard agents without explicit human confirmation, blast-radius assessment, and rollback path.",
-  "last_verified": "2026-04-30",
+  "security_notes": "Never auto-dispatch live-guard agents. Any live Azure mutation path requires explicit human confirmation, blast-radius assessment, target confirmation, rollback or non-reversibility statement, and specialist handoff.",
+  "last_verified": "2026-06-05",
   "path": "skills/azure/azure-maestro",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.2"
 }

package/skills/azure/azure-maestro/references/maestro-routing-operations.md

@@ -0,0 +1,68 @@
+# Azure Maestro Routing Operations
+
+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
+
+- Answering specialist questions inside Maestro instead of routing.
+- Dispatching multiple agents because it feels safer when one narrow specialist fits.
+- Auto-dispatching live-guard agents for production changes.
+- Using stale hard-coded agent counts or missing a live-guard route.
+- Routing non-Azure work through the Azure catalog.
+
+## Officially grounded service shape
+
+Microsoft Learn evidence across Azure Architecture Center, Well-Architected Framework, Cloud Adoption Framework, Azure RBAC, and Azure Monitor supports domain-specific ownership, least privilege, operational evidence, and risk-based escalation. Maestro is a routing layer: official docs ground domains and safety principles, while repo catalog state proves which specialist IDs exist.
+
+- Maestro classifies domain, selects the narrowest matching specialist, then chooses single, parallel, or live-guard-gated handoff.
+- Multi-agent routing is capped and only justified by genuinely multi-domain work.
+- Live-guard agents are not normal specialists; they require a pause and confirmation before dispatch.
+- Catalog state is repo-derived and can change; docs should avoid stale fixed counts unless generated.
+- Documentation evidence grounds Azure behavior but not catalog completeness; repo files prove catalog routes.
+
+## Non-negotiable design rules
+
+- Prefer exact named agent when the user provides a valid catalog agent ID.
+- Use one specialist for one-domain tasks.
+- Use parallel specialists only for distinct domains, and keep the set bounded.
+- Stop before live-guard dispatch and present exact target/action/rollback gate.
+- Update routing tables when agents are added, removed, or renamed.
+
+## Minimal safe implementation flow
+
+- Classify the task domain and provider.
+- Check whether the user named a specific Azure catalog agent.
+- Select the narrowest specialist or bounded team.
+- If any selected route is live-guard, stop and ask for explicit confirmation with blast radius and rollback status.
+- Summarize route, rationale, mode, and evidence limits.
+
+## High-risk assumptions to kill
+
+- Maestro is not a specialist. If it answers domain-specific Azure implementation questions instead of routing, it is doing the wrong job.
+- Documentation evidence grounds Azure service behavior, but only repo catalog state proves which local specialist routes exist now.
+- Dispatching a team is not safer when one narrow specialist owns the problem; it increases conflict and diff noise.
+- Live-guard routing is not routine dispatch. It needs an explicit target, action, blast radius, approval, and rollback gate before execution.
+- Hard-coded agent counts and stale route lists are false confidence unless generated from current catalog files.
+
+## Safe command/code verification targets
+
+- Verify the requested provider and domain before selecting an Azure route.
+- Check current repo catalog/agent files for exact specialist IDs, live-guard status, and role coverage.
+- Prefer one specialist for one domain; require distinct ownership for every parallel route.
+- Enforce a live-guard pause with target/action/rollback wording before any production mutation route.
+- Reject or redirect non-Azure work rather than forcing it through Azure Maestro.
+
+## Safe verification targets
+
+- Routing table includes every current Azure live-guard agent.
+- Live-guard list and live-guard gate count match.
+- No stale hard-coded total catalog count is used as proof.
+- Non-Azure tasks are rejected or redirected rather than routed through Azure Maestro.
+- Parallel route has no more than four specialists and each has distinct ownership.
+
+## When to push back
+
+- The user asks Maestro to execute live mutation directly.
+- The task is ambiguous across providers.
+- The requested route does not exist in repo catalog state.
+- A parallel route would duplicate ownership or exceed four specialists.

package/skills/azure/azure-maestro/references/mcp-and-evidence.md

@@ -0,0 +1,22 @@
+# Documentation and Evidence Path
+
+## Preferred evidence order
+
+1. Microsoft Learn documentation through the user's configured documentation MCP for documented Azure behavior.
+2. Sampled read-only Azure evidence, when safely available, for current configured-environment observations.
+3. Sanitized user-provided evidence.
+4. Clearly labeled inference.
+
+## What each evidence type can prove
+
+- Microsoft Learn documentation can prove documented service behavior, supported concepts, limitations, and recommended patterns.
+- Sampled read-only evidence can prove the sampled configured state at the time observed.
+- Sanitized user evidence can prove only what the snippet shows.
+- None of these alone prove broad regional availability, future success, full account posture, or production readiness.
+
+## Safe usage pattern
+
+- State whether each claim is documentation-based, sampled-current-state, user-provided, or inference.
+- Use read-only queries before recommending changes.
+- Do not include sensitive internal identifiers, tenant identifiers, subscription identifiers, or secrets in committed docs or final findings.
+- If no sampled evidence is available, say the review is documentation-based and list the exact evidence still needed.

package/skills/azure/azure-maestro/references/official-sources.md

@@ -0,0 +1,25 @@
+# Official Sources
+
+Use these sources to ground the skill. Microsoft Learn documentation proves documented Azure behavior; it does not prove the user's tenant, subscription, RBAC, quota, migration project, network, telemetry, deployed resources, or production readiness.
+
+## Primary Microsoft Learn sources
+
+- https://learn.microsoft.com/azure/architecture/
+- https://learn.microsoft.com/azure/well-architected/
+- https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-areas
+- https://learn.microsoft.com/azure/role-based-access-control/best-practices
+- https://learn.microsoft.com/azure/azure-monitor/fundamentals/overview
+
+## Grounding notes
+
+- Documentation-based claim: Microsoft Learn evidence across Azure Architecture Center, Well-Architected Framework, Cloud Adoption Framework, Azure RBAC, and Azure Monitor supports domain-specific ownership, least privilege, operational evidence, and risk-based escalation. Maestro is a routing layer: official docs ground domains and safety principles, while repo catalog state proves which specialist IDs exist.
+- Current-state claim: requires sampled read-only Azure evidence or sanitized user-provided evidence.
+- Inference: allowed only when labeled and tied to observed fields or documented behavior.
+- Do not include sensitive internal identifiers or secret material in findings.
+
+## Source use rules
+
+- Prefer Microsoft Learn documentation through the user's configured documentation MCP for current Azure service behavior.
+- Use sampled read-only Azure evidence only to validate current configured-environment observations.
+- If documentation and sampled evidence appear to conflict, report both and stop short of a production-ready verdict.
+- Re-check official sources before changing high-risk guidance, because cloud behavior and feature availability can change.

package/skills/azure/azure-maestro/references/safety-checklist.md

@@ -0,0 +1,28 @@
+# Safety Checklist
+
+## Evidence labels
+
+- `documentation-based`: grounded in Microsoft Learn or listed official documentation.
+- `sampled-current-state`: grounded in read-only Azure observations from the user's configured tools.
+- `user-provided`: grounded in sanitized snippets supplied by the user.
+- `inference`: reasoned from evidence but not directly proven.
+
+## Mutation boundary
+
+- Default to read-only review.
+- Do not perform create, update, delete, activate, approve, cancel, deactivate, migrate, cut over, route, peer, deploy, alert, suppress, or configuration changes unless the user explicitly asks and approval is clear.
+- Prefer preview, assessment, status, list, show, query, activity-log, dependency, and diagnostic evidence before any mutation.
+
+## Credential and data boundary
+
+- Never ask users to paste credentials, tokens, tenant IDs, subscription IDs, customer data, private keys, appliance secrets, migration inventory dumps, log payload secrets, or raw environment dumps.
+- Summarize sensitive evidence by field presence, control state, and risk; do not reproduce secret material.
+
+## Risk gates
+
+- Stop on ambiguous target, ambiguous principal, missing approval, missing owner, missing rollback, stale assessment, incomplete dependency mapping, unclear routing, or missing telemetry for high-impact assets.
+- Separate documented product behavior from sampled configured-environment evidence.
+
+## Asset-specific hard line
+
+Never auto-dispatch live-guard agents. Any live Azure mutation path requires explicit human confirmation, blast-radius assessment, target confirmation, rollback or non-reversibility statement, and specialist handoff.

package/skills/azure/azure-maestro/references/workflow-and-output.md

@@ -0,0 +1,30 @@
+# Workflow and Output Contract
+
+## Execution flow
+
+1. Scope the exact target, environment boundary, owner, requested decision, and evidence available.
+2. Load `official-sources.md`, then the component operations guide for service behavior and risk gates.
+3. Gather sampled read-only evidence only when available and safe.
+4. Compare observed posture against documented behavior, least-privilege expectations, and operational safety rules.
+5. Return a verdict with evidence level, blockers, safe next actions, and open questions.
+
+## Required output
+
+- `verdict`: pass, warn, fail, or blocked.
+- `evidence_level`: documentation-based, sampled-current-state, user-provided, inference, or mixed.
+- `scope`: what was reviewed and what was not reviewed.
+- `blockers`: issues that prevent a safe or production-ready conclusion.
+- `findings`: severity-labeled risks with source labels.
+- `safe_next_actions`: reversible actions first; mutation only with explicit approval.
+- `open_questions`: missing facts that would change the verdict.
+
+## Stress checks
+
+- What assumption would make this recommendation unsafe?
+- Which identity, migration, network, telemetry, route, or dispatch decision has the largest blast radius?
+- What evidence would disprove the claimed readiness?
+- Is the answer accidentally treating documentation as configured-environment proof?
+
+## Response discipline
+
+Use Microsoft Learn documentation through the user's configured documentation MCP for documented Azure behavior. Use sampled read-only Azure evidence only for current configured-environment observations and label it as sampled evidence.

package/skills/azure/azure-migrate-landing-zone-cutover/SKILL.md

@@ -4,8 +4,8 @@ description: Plan and stress-test Azure migration cutovers across landing-zone r
 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
 ---
 
@@ -29,7 +29,7 @@ Force clarity on:
 
 Default posture:
 
-- Prefer Azure Migrate assessments, landing-zone evidence, and official Microsoft guidance over broad migration slogans.
+- Prefer Microsoft Learn documentation through the user's configured documentation MCP, then Azure Migrate assessment or landing-zone evidence when available, then sanitized user evidence.
 - Never accept “Azure ready” as equivalent to “cutover ready.”
 - Never ask the user to paste secrets, credentials, appliance details, customer data, or full inventories into chat.
 
@@ -47,7 +47,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.
@@ -56,6 +56,8 @@ Use this skill when the user asks to:
 
 Load these only when needed:
 
+- [Azure Migration Cutover Operations](references/migration-cutover-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 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.