@raishin/vanguard-frontier-agentic 2.7.1 → 2.9.0

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.

package/skills/azure/azure-migrate-landing-zone-cutover/metadata.json

@@ -11,19 +11,19 @@
     "kiro",
     "other"
   ],
-  "summary": "Stress-test Azure migration cutovers across assessment quality, landing-zone readiness, dependency sequencing, permissions, rollback, and post-cutover operating ownership.",
+  "summary": "Stress-test Azure migration cutovers across discovery quality, assessment freshness, dependency sequencing, landing-zone readiness, permissions, rollback, and post-cutover operating ownership.",
   "source_type": "original",
   "official_docs": [
-    "https://learn.microsoft.com/en-us/azure/migrate/concepts-overview?view=migrate",
-    "https://learn.microsoft.com/en-us/azure/migrate/assessment-prerequisites?view=migrate",
-    "https://learn.microsoft.com/en-us/azure/migrate/review-application-assessment?view=migrate",
-    "https://learn.microsoft.com/en-us/azure/migrate/platform-landing-zone?view=migrate",
-    "https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/ready-azure-landing-zone",
-    "https://learn.microsoft.com/en-us/azure/migrate/whats-new?view=migrate"
+    "https://learn.microsoft.com/azure/migrate/migrate-services-overview?view=migrate",
+    "https://learn.microsoft.com/azure/migrate/concepts-migration-planning?view=migrate",
+    "https://learn.microsoft.com/azure/migrate/common-questions-discovery-dependency-analysis?view=migrate",
+    "https://learn.microsoft.com/azure/migrate/overview?view=migrate",
+    "https://learn.microsoft.com/azure/migrate/platform-landing-zone?view=migrate",
+    "https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/"
   ],
   "security_notes": "Do not equate Azure readiness with cutover readiness. Treat stale assessments, weak dependency mapping, broad migration permissions, missing rollback checkpoints, and incomplete landing-zone connectivity or monitoring as high-risk blockers.",
-  "last_verified": "2026-04-27",
+  "last_verified": "2026-06-05",
   "path": "skills/azure/azure-migrate-landing-zone-cutover",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.2"
 }

package/skills/azure/azure-migrate-landing-zone-cutover/references/mcp-and-evidence.md

@@ -1,37 +1,22 @@
-# MCP and Evidence Path
+# Documentation and Evidence Path
 
-## Official Azure MCP Linkage
+## Preferred evidence order
 
-Use official Azure MCP capabilities only when they are actually exposed in the active runtime.
+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.
 
-Relevant namespaces may include:
+## What each evidence type can prove
 
-- `group`, `subscription`, and `resourcehealth` for target-scope evidence,
-- `azuremigrate` when the client exposes the official Azure Migrate tooling,
-- `monitor` for validation or incident signal posture,
-- `deploy` or `bicepschema` if landing-zone deployment evidence is relevant,
-- generic Azure discovery namespaces when they materially help confirm the target environment.
+- 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.
 
-Do not assume the Azure Migrate namespace exists in the current runtime just because Microsoft documents it. If migration-specific live tooling is missing, switch to documentation-grounded and sanitized-evidence review.
+## Safe usage pattern
 
-## Platform-Agnostic Execution
-
-This skill must work in MCP-only, macOS, Linux, and Windows clients.
-
-Prefer:
-
-1. assessment evidence,
-2. landing-zone readiness evidence,
-3. sanitized dependency maps and migration wave plans,
-4. neutral placeholder commands or artifacts only when needed.
-
-Do not assume Azure CLI, PowerShell, Terraform, GitHub Actions, or Azure DevOps unless the user confirms the toolchain.
-
-## Documentation Fallback When Live Data Is Unavailable
-
-Live target-state evidence beats theory. If live access is unavailable, incomplete, denied, or too risky:
-
-- fall back to official Azure Migrate and Cloud Adoption Framework guidance,
-- ask for sanitized assessment exports, wave plans, dependency diagrams, landing-zone summaries, and rollback checklists,
-- label each conclusion as `live evidence`, `documentation-based`, `user-provided sanitized evidence`, or `inference`,
-- do not present a migration as safe merely because Azure Migrate produced a recommendation.
+- 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-migrate-landing-zone-cutover/references/migration-cutover-operations.md

@@ -0,0 +1,68 @@
+# Azure Migration Cutover 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
+
+- Calling an assessment green and assuming the cutover is ready.
+- Grouping servers by owner or convenience while ignoring runtime dependencies.
+- Using stale discovery, missing performance data, or incomplete inventory for final go/no-go.
+- Cutting over into an unfinished landing zone with weak DNS, routing, monitoring, backup, or identity.
+- Treating rollback as “restore from backup” without timing and data-loss proof.
+
+## Officially grounded service shape
+
+Microsoft Learn evidence says Azure Migrate supports decide, plan, and execute phases: discovery, business case, Azure readiness, right-sizing, cost estimation, dependency analysis, replication, migration, and modernization. Wave planning quality depends on complete discovery, accurate inventory, dependency analysis, application grouping, metadata enrichment, and assessments. Planning agents can interpret migration data but execution actions remain in Azure Migrate workflows.
+
+- Azure Migrate discovery collects inventory and performance data used for business cases and assessments.
+- Assessments provide readiness, right-sizing, cost estimates, and blockers, but need current data and correct assumptions.
+- Dependency analysis helps group workloads and avoid missed application dependencies.
+- Landing-zone readiness includes identity, network, governance, security, management, and operations foundations.
+- Cutover readiness adds wave sequencing, freeze windows, validation, rollback, and ownership.
+
+## Non-negotiable design rules
+
+- Require current discovery and assessment timestamps before go/no-go.
+- Require dependency evidence for every workload group in a wave.
+- Require target landing-zone controls before migration execution.
+- Require least-privilege migration permissions and named operators.
+- Require rollback checkpoints, data-loss boundary, and post-cutover validation owner.
+
+## Minimal safe implementation flow
+
+- Scope migration wave, workloads, source platform, target region/subscription, landing zone, and business owner.
+- Collect assessment, dependency, business case, replication/test migration, landing-zone, and runbook evidence.
+- Classify blockers by readiness, dependency, permissions, data, network, identity, monitoring, backup, and rollback risk.
+- Decide go, no-go, or conditional go with explicit cutover criteria.
+- Define post-cutover validation, monitoring, handover, and rollback deadline.
+
+## High-risk assumptions to kill
+
+- Assessment readiness is not cutover readiness; final cutover still needs current dependencies, replication state, freeze controls, validation, and fallback.
+- A landing zone that is missing DNS, routing, identity, monitoring, backup, or policy guardrails is not ready because migration tooling can move assets.
+- Near-zero downtime is not a slogan; replication lag, final synchronization, write freeze, traffic switch, and post-cutover validation must all be evidenced.
+- Rollback that loses unreplicated writes or misses DNS/load-balancer reversion is not a rollback plan.
+- Decommission is not safe until source-retention and business validation windows have expired.
+
+## Safe command/code verification targets
+
+- Verify discovery freshness, assessment assumptions, dependency grouping, replication health, and test migration evidence before go/no-go.
+- Confirm landing-zone controls: network connectivity, DNS, identity/RBAC, policy, monitoring, backup, and support ownership.
+- Check cutover runbook for write freeze, final sync, data-integrity checks, DNS/load-balancer switch, and 24-48 hour monitoring owner.
+- Verify fallback decision point, source-environment retention, accepted RPO/RTO, and rollback commands before traffic cutover.
+- Label any missing current Azure Migrate or landing-zone evidence as a blocker, not an assumption.
+
+## Safe verification targets
+
+- Discovery covers all in-scope workloads with current data.
+- Assessment assumptions, sizing, cost, and readiness blockers are reviewed.
+- Dependency groups align to application behavior and outage window.
+- Landing zone has connectivity, DNS, identity, policy, monitoring, backup, and support ownership.
+- Rollback has tested procedure, decision point, and accepted RPO/RTO impact.
+
+## When to push back
+
+- The plan lacks current Azure Migrate evidence.
+- Dependency mapping is guessed or incomplete.
+- Landing-zone controls are “coming later.”
+- Rollback cannot be executed within the business recovery window.

package/skills/azure/azure-migrate-landing-zone-cutover/references/official-sources.md

@@ -1,12 +1,26 @@
 # Official Sources
 
-## References
+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.
 
-Load these only when needed:
+## Primary Microsoft Learn sources
 
-- [Azure Migrate assessment overview](https://learn.microsoft.com/en-us/azure/migrate/concepts-overview?view=migrate)
-- [Prerequisites for assessments](https://learn.microsoft.com/en-us/azure/migrate/assessment-prerequisites?view=migrate)
-- [Review an application assessment](https://learn.microsoft.com/en-us/azure/migrate/review-application-assessment?view=migrate)
-- [Generate and deploy Platform Landing Zone with Azure Migrate](https://learn.microsoft.com/en-us/azure/migrate/platform-landing-zone?view=migrate)
-- [Prepare your landing zone for migration](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/ready-azure-landing-zone)
-- [What’s new in Azure Migrate](https://learn.microsoft.com/en-us/azure/migrate/whats-new?view=migrate)
+- https://learn.microsoft.com/azure/migrate/migrate-services-overview?view=migrate
+- https://learn.microsoft.com/azure/migrate/concepts-migration-planning?view=migrate
+- https://learn.microsoft.com/azure/migrate/common-questions-discovery-dependency-analysis?view=migrate
+- https://learn.microsoft.com/azure/migrate/overview?view=migrate
+- https://learn.microsoft.com/azure/migrate/platform-landing-zone?view=migrate
+- https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/
+
+## Grounding notes
+
+- Documentation-based claim: Microsoft Learn evidence says Azure Migrate supports decide, plan, and execute phases: discovery, business case, Azure readiness, right-sizing, cost estimation, dependency analysis, replication, migration, and modernization. Wave planning quality depends on complete discovery, accurate inventory, dependency analysis, application grouping, metadata enrichment, and assessments. Planning agents can interpret migration data but execution actions remain in Azure Migrate workflows.
+- 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-migrate-landing-zone-cutover/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
+
+Do not equate Azure readiness with cutover readiness. Treat stale assessments, weak dependency mapping, broad migration permissions, missing rollback checkpoints, and incomplete landing-zone connectivity or monitoring as high-risk blockers.