@raishin/vanguard-frontier-agentic 2.8.0 → 2.10.0

package/skills/azure/azure-keyvault-certificate-issuer-review/references/workflow-and-output.md

@@ -1,190 +1,30 @@
 # Workflow and Output Contract
 
-## Review Workflow
+## Execution flow
 
-### Step 1 — Identify the cert-manager issuer configuration
+1. Scope the exact asset, environment boundary, owner, and requested decision.
+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.
 
-Locate the cert-manager issuer resource that references Azure Key Vault:
+## Required output
 
-```bash
-kubectl get issuer -A -o yaml | grep -A10 "azureKeyVault\|keyVault"
-kubectl get clusterissuer -o yaml | grep -A10 "azureKeyVault\|keyVault"
-```
+- `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.
 
-Extract the Key Vault name and vault URI from the issuer spec. The exact fields depend on the cert-manager Azure issuer plugin in use (e.g., `cert-manager-webhook-azure` or CAPZ-style issuers).
+## Stress checks
 
-### Step 2 — Check Managed Identity role assignment
+- What assumption would make this recommendation unsafe?
+- Which role, policy, network, lifecycle, or rollout action has the largest blast radius?
+- What evidence would disprove the claimed readiness?
+- Is the answer accidentally treating documentation as tenant-specific proof?
 
-Identify the Managed Identity or Service Principal used by cert-manager on AKS:
+## Response discipline
 
-```bash
-# Get the cert-manager pod's managed identity annotation
-kubectl get pod -n cert-manager -l app=cert-manager -o jsonpath='{.items[0].metadata.annotations}'
-
-# Or check the ServiceAccount for workload identity annotation
-kubectl get serviceaccount cert-manager -n cert-manager -o jsonpath='{.metadata.annotations}'
-```
-
-Retrieve role assignments on the Key Vault:
-
-```bash
-KV_ID=$(az keyvault show --name <vault-name> --query id -o tsv)
-az role assignment list --scope "$KV_ID" --output table
-```
-
-**Correct role:** `Key Vault Certificate Officer` (data plane only)
-
-Role comparison:
-
-| Role | Plane | Grants | Risk |
-|------|-------|--------|------|
-| `Key Vault Certificate Officer` | Data | Create, update, import, delete certificates | Correct |
-| `Key Vault Certificates Officer` | Data | Same as above (alias) | Correct |
-| `Key Vault Contributor` | Management | Manage vault config, delete vault, change policies | HIGH — management plane access |
-| `Key Vault Administrator` | Data + Management | Full control including purge | HIGH |
-| `Owner` / `Contributor` at subscription | All | Everything | CRITICAL |
-
-### Step 3 — Check RBAC mode vs legacy access policies
-
-```bash
-az keyvault show --name <vault-name> --query properties.enableRbacAuthorization
-```
-
-- `true` — RBAC mode (preferred, auditable via Azure RBAC)
-- `false` or `null` — legacy access policies (harder to audit)
-
-If legacy access policies are in use, check the policy:
-
-```bash
-az keyvault show --name <vault-name> --query properties.accessPolicies
-```
-
-The cert-manager identity should only have `certificates: ["get", "create", "import", "update", "list"]` — not `all` and not management operations.
-
-### Step 4 — Review certificate policy and exportability
-
-```bash
-az keyvault certificate get-default-policy
-az keyvault certificate show --vault-name <vault-name> --name <cert-name>
-```
-
-Key fields in the certificate policy:
-
-```json
-{
-  "x509CertificateProperties": {
-    "subject": "CN=myapp.internal",
-    "validityInMonths": 3,
-    "keyUsage": ["digitalSignature", "keyEncipherment"]
-  },
-  "keyProperties": {
-    "exportable": false,
-    "keyType": "RSA",
-    "keySize": 2048,
-    "reuseKey": false
-  },
-  "issuerParameters": {
-    "name": "Self"
-  }
-}
-```
-
-**Flags:**
-- `exportable: true` on a cert used for cluster-internal mTLS — MEDIUM (private key extractable)
-- `keySize < 2048` for RSA or `keySize < 256` for EC — HIGH (weak key)
-- `validityInMonths > 12` for workload certs — MEDIUM (excessive validity)
-
-Note: Non-exportable certs require the application to use Key Vault SDK or CSI driver for key operations, not just cert retrieval. Confirm application capability before enforcing non-exportable.
-
-### Step 5 — Review Key Vault network access
-
-```bash
-az keyvault show --name <vault-name> --query properties.networkAcls
-az keyvault show --name <vault-name> --query properties.publicNetworkAccess
-```
-
-If `publicNetworkAccess: Disabled`:
-
-```bash
-# Check for private endpoint
-az network private-endpoint list \
-  --query "[?privateLinkServiceConnections[?groupIds[0]=='vault']].{name:name,subnet:subnet.id}" \
-  --output table
-
-# Check for private DNS zone
-az network private-dns zone list --query "[?contains(name,'vaultcore')]" --output table
-```
-
-For AKS access to Key Vault:
-- AKS cluster VNet must be peered with or the same as the VNet hosting the private endpoint
-- Private DNS zone `privatelink.vaultcore.azure.net` must be linked to the AKS cluster VNet
-- Outbound traffic from cert-manager pod must route through the private endpoint
-
-**Flags:**
-- Key Vault with public access from internet and no firewall restrictions — MEDIUM
-- Key Vault with `publicNetworkAccess: Disabled` but missing private endpoint — HIGH (cert issuance will fail)
-- No private DNS zone link to AKS VNet (DNS resolution fails for private endpoint) — HIGH
-
-### Step 6 — Review integrated CA configuration (if applicable)
-
-For DigiCert or GlobalSign integrated CAs:
-
-```bash
-az keyvault certificate issuer show --vault-name <vault-name> --issuer-name DigiCert
-```
-
-Check that the issuer credential secret is stored in Key Vault and scoped to a minimum profile:
-
-```bash
-az keyvault secret show --vault-name <vault-name> --name DigiCert-issuer-creds
-```
-
-**Flags:**
-- Integrated CA credentials that have account-wide issuance scope (not single profile) — MEDIUM
-- Integrated CA credentials stored outside Key Vault (e.g., in a Kubernetes Secret) — MEDIUM
-
-### Step 7 — Review rotation race condition
-
-cert-manager rotation schedule:
-```bash
-kubectl get certificate <name> -n <namespace> -o jsonpath='{.spec.duration} {.spec.renewBefore}'
-```
-
-Key Vault auto-rotation policy:
-```bash
-az keyvault certificate get-default-policy | jq '.lifetimeActions'
-```
-
-A `lifetimeAction` of type `AutoRenew` triggers Key Vault to request a new cert from the issuer. If cert-manager's `renewBefore` window overlaps with the Key Vault auto-renewal trigger (both fire within the same rotation window), both may attempt to renew simultaneously, causing a temporary version mismatch.
-
-**Mitigation:** Disable Key Vault auto-rotation for certs managed by cert-manager, or ensure the Key Vault auto-renewal threshold is set beyond the cert-manager `renewBefore` window.
-
----
-
-## Output Format
-
-### Finding: `<short title>`
-
-| Field | Value |
-|-------|-------|
-| Severity | CRITICAL / HIGH / MEDIUM / LOW |
-| Resource | Key Vault name, role assignment, cert name, or policy field |
-| Evidence | documentation-based / live evidence / inference |
-| Description | What is wrong and its impact |
-| Remediation | Azure CLI command, policy JSON, or configuration change |
-
----
-
-### Overall Posture
-
-| Category | Status |
-|----------|--------|
-| Managed Identity role (data plane only) | PASS / FAIL |
-| RBAC mode (not legacy policies) | PASS / FAIL |
-| Certificate exportability | PASS / FAIL |
-| Key Vault network access | PASS / FAIL |
-| Certificate validity periods | PASS / FAIL |
-| Integrated CA credential scope | PASS / N/A / FAIL |
-| Rotation policy alignment | PASS / FAIL |
-
-**Verdict:** TRUSTED / UNTRUSTED / CONDITIONAL (list conditions)
+Use Microsoft Learn documentation through the user's configured documentation MCP for documented Key Vault certificate behavior. Use sampled read-only Azure evidence only for certificate policy, issuer, RBAC, network, and renewal observations; never request private keys or CA account secrets.

package/skills/azure/azure-landing-zone-architect/SKILL.md

@@ -4,8 +4,8 @@ description: Use this skill for Azure landing-zone design, management-group and
 allowed-tools: Read Grep Glob
 metadata:
   author: github: Raishin
-  version: 0.1.0
-  updated: "2026-05-05"
+  version: 0.1.3
+  updated: "2026-06-05"
   category: compliance
 ---
 
@@ -46,7 +46,7 @@ Do not use this skill for:
 
 ## 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 the active client exposes it, 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.
@@ -55,7 +55,9 @@ Do not use this skill for:
 
 Load these only when needed:
 
+- [Azure Landing Zone Architecture Operations](references/landing-zone-architecture-operations.md) — use for current service behavior, common failure modes, hard design rules, verification targets, and push-back conditions.
 - [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing live Azure evidence, confirming Microsoft MCP capability, or switching to documentation mode.
+- [Safety checklist](references/safety-checklist.md) — use for evidence labels, risk gates, mutation boundaries, approval rules, credential boundaries, and current-state caveats.
 - [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-landing-zone-architect/metadata.json

@@ -11,20 +11,21 @@
     "kiro",
     "other"
   ],
-  "summary": "Design or review Azure landing-zone architecture across management groups, subscriptions, governance, security, networking, and operations dependencies.",
+  "summary": "Design or review Azure landing-zone architecture across management groups, subscriptions, governance, security, networking, identity, management, and platform automation dependencies.",
   "source_type": "original",
   "official_docs": [
+    "https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/",
     "https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-areas",
     "https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/identity-access",
     "https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/governance",
     "https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/security",
-    "https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/implementation-options",
-    "https://learn.microsoft.com/azure/architecture/networking/architecture/hub-spoke",
-    "https://learn.microsoft.com/azure/developer/azure-mcp-server/tools/"
+    "https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/management",
+    "https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/platform-automation-devops",
+    "https://learn.microsoft.com/azure/architecture/networking/architecture/hub-spoke"
   ],
-  "security_notes": "Do not prescribe a one-size-fits-all hierarchy, broad admin grants, or a production-ready verdict without governance, management, and recovery dependencies being addressed.",
-  "last_verified": "2026-04-27",
+  "security_notes": "Do not prescribe a one-size-fits-all hierarchy, broad admin grants, or production-ready verdict without identity, governance, security, management, network, subscription, cost, and recovery dependencies being addressed.",
+  "last_verified": "2026-06-05",
   "path": "skills/azure/azure-landing-zone-architect",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.3"
 }

package/skills/azure/azure-landing-zone-architect/references/landing-zone-architecture-operations.md

@@ -0,0 +1,68 @@
+# Azure Landing Zone Architecture 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
+
+- Drawing a management-group tree before clarifying operating model and ownership.
+- Treating a landing-zone accelerator deployment as proof that governance is complete.
+- Putting every workload under one subscription because it is simpler today.
+- Ignoring identity, security, monitoring, backup, policy, and cost baselines in a network-only design.
+- Copying hub-spoke without proving routing, DNS, inspection, and shared-service ownership.
+
+## Officially grounded service shape
+
+Microsoft Learn evidence says Azure landing zones are platform foundations spanning platform and application landing zones, management groups, subscriptions, policy inheritance, connectivity, identity, governance, security, management, and platform automation. The design-areas guidance explicitly calls out billing/tenant, identity/access, resource organization, network topology/connectivity, security, management, governance, and platform automation/DevOps as decisions that affect the foundation.
+
+- A landing zone separates platform shared services from application landing zones while preserving governance and autonomy.
+- Management-group and subscription design control policy inheritance, RBAC scope, chargeback, quota, and blast radius.
+- The platform needs identity/access, governance, management, security, network connectivity, and automation decisions before workload scale.
+- Application landing zones need guardrails but must still let workload teams operate within defined boundaries.
+- Implementation options are starting points; documented design areas must be tailored to business and technical requirements.
+
+## Non-negotiable design rules
+
+- Start with design areas and decision records, not tooling preference.
+- Require explicit ownership for platform subscriptions, application subscriptions, policies, connectivity, monitoring, and incident response.
+- Prefer least-privilege and subscription democratization with policy guardrails over central bottlenecks or unmanaged autonomy.
+- Document exceptions, inheritance boundaries, and migration path for brownfield environments.
+- Never claim production readiness without current-state evidence and operational ownership.
+
+## Minimal safe implementation flow
+
+- Scope business units, environments, regulatory boundaries, connectivity model, identity model, and platform-team responsibilities.
+- Map current or proposed management groups, subscriptions, policy inheritance, RBAC, and shared services.
+- Evaluate each landing-zone design area for missing decisions and unsafe coupling.
+- Rank architecture gaps by blast radius and irreversibility: tenant, management group hierarchy, connectivity, policy, identity, and logging first.
+- Return a staged target architecture with blockers, decision points, and safe next actions.
+
+## High-risk assumptions to kill
+
+- A management-group diagram is not a landing zone unless identity, governance, network, security, management, cost, and automation decisions are explicit.
+- Deploying an accelerator is not proof that the operating model, ownership, exceptions, and brownfield migration risks are solved.
+- Subscription democratization fails if application teams get autonomy without inherited guardrails, monitoring, budget visibility, and recovery boundaries.
+- Hub-spoke is not automatically correct; routing, DNS, inspection, private access, shared-service ownership, and failure domains decide fitness.
+- Broad platform Owner assignments and shared identities destroy the very blast-radius boundaries landing zones are meant to create.
+
+## Safe command/code verification targets
+
+- Inspect architecture docs or IaC for management group hierarchy, platform/application subscription split, environment isolation, and policy inheritance.
+- Review role-assignment patterns for group-based least privilege, PIM/JIT where appropriate, and separation between platform and application responsibilities.
+- Check networking artifacts for hub/spoke or alternative topology, DNS, egress inspection, private endpoint strategy, route tables, and connectivity ownership.
+- Verify governance, security, management, backup, cost, and diagnostic baselines are assigned at intentional scopes with exception handling.
+- Confirm subscription vending or onboarding automation can repeatedly create governed landing zones without hard-coded tenant-specific secrets or one-off manual grants.
+
+## Safe verification targets
+
+- Management group and subscription model supports platform/application separation and environment isolation.
+- Policy, RBAC, diagnostic, security, cost, and backup baselines are inherited where intended.
+- Connectivity design includes routing, DNS, private access, inspection, and failure domains.
+- Subscription vending or onboarding process can produce repeatable, governed application landing zones.
+- Brownfield migration steps avoid breaking existing workloads and preserve rollback options.
+
+## When to push back
+
+- The user wants Terraform/Bicep before design decisions are made.
+- The architecture depends on broad permanent Owner assignments.
+- Shared services have no owner, budget, monitoring, or recovery model.
+- A single subscription or network boundary is hiding compliance, quota, or blast-radius problems.

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

@@ -1,25 +1,26 @@
-# MCP and Evidence Path
+# Documentation and Evidence Path
 
-## Evidence path
+## Preferred evidence order
 
-Prefer evidence in this order:
+1. Microsoft Learn documentation through the user's configured documentation MCP for documented Azure behavior.
+2. Sampled read-only Azure or Kubernetes evidence, when safely available, for current configured-environment observations.
+3. Sanitized user-provided evidence.
+4. Clearly labeled inference.
 
-1. Microsoft Learn Azure landing-zone guidance:
-   - landing-zone design areas,
-   - identity and access design area,
-   - governance design area,
-   - security design area,
-   - implementation options when delivery model matters.
-2. Microsoft Learn Azure architecture guidance when network topology is part of the decision.
-3. Azure MCP evidence, if the client exposes the relevant namespaces and live tenant inspection reduces guesswork.
+## What each evidence type can prove
 
-Useful Azure MCP namespaces from repo-backed specs:
+- Microsoft Learn documentation can prove documented service behavior, supported concepts, 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.
 
-- `cloudarchitect`
-- `wellarchitectedframework`
-- `policy`
-- `role`
-- `group`
-- `subscription`
+## Safe usage pattern
 
-Use MCP evidence to confirm current hierarchy, scope, or governance reality. Do not use it as an excuse to skip design-area reasoning.
+- 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.
+
+## Asset guidance
+
+Use Microsoft Learn documentation through the user's configured documentation MCP for documented landing-zone design areas and patterns. Use sampled read-only Azure evidence only to inspect current hierarchy, policies, RBAC, resources, and diagnostics, and label it as sampled evidence.

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

@@ -1,19 +1,28 @@
 # Official Sources
 
-Load these only when needed:
+Use these sources to ground the skill. Microsoft Learn documentation proves documented Azure behavior; it does not prove the user's tenant, RBAC, quotas, deployed resources, or production readiness.
 
-- [What is an Azure landing zone?](https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/) — use for platform versus application landing zones and the reference-architecture baseline.
-- [Azure landing zone design areas and conceptual architecture](https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-areas) — use for the design-area map and the dependency between resource organization, networking, governance, management, and automation.
-- [Azure landing zone design principles](https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-principles) — use for policy-driven governance, Azure-native alignment, and avoiding application-agnostic hierarchy mistakes.
-- [Deploy Azure landing zones](https://learn.microsoft.com/azure/architecture/landing-zones/landing-zone-deploy) — use for platform landing zone deployment approaches and application landing zone patterns.
-- [Platform landing zone vs. application landing zones](https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/#platform-landing-zone-vs-application-landing-zones) — use when teams are blurring shared platform services with workload-local ownership.
-- [Tailor the Azure landing zone architecture to meet requirements](https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/tailoring-alz) — use when the user wants to deviate from the reference architecture without pretending there is one canonical hierarchy.
-- [Ready your Azure environment for workloads](https://learn.microsoft.com/azure/cloud-adoption-framework/ready/) — use for the baseline expectation that management, governance, security, and monitoring apply across subscriptions.
-- [Azure MCP Server tools inventory](https://learn.microsoft.com/azure/developer/azure-mcp-server/tools/) — use to verify `cloudarchitect`, `policy`, `group`, `subscription`, `role`, or `wellarchitectedframework` before naming them.
+## Primary Microsoft Learn sources
 
-## Grounded insights worth carrying into the skill
+- https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/
+- https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-areas
+- https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/identity-access
+- https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/governance
+- https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/security
+- https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/management
+- https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/platform-automation-devops
+- https://learn.microsoft.com/azure/architecture/networking/architecture/hub-spoke
 
-- Microsoft’s landing-zone guidance is explicitly modular and should be tailored; a single canned hierarchy is usually a sign of lazy thinking.
-- Platform landing zones and application landing zones are different operating boundaries; mixing them casually creates ownership and governance confusion.
-- Azure AI workloads do not require a separate “AI landing zone” by default; Microsoft says they should usually fit inside normal application landing zones governed by the same design areas.
-- A landing zone is not complete if management, governance, monitoring, and recovery posture are still deferred.
+## Grounding notes
+
+- Documentation-based claim: Microsoft Learn evidence says Azure landing zones are platform foundations spanning platform and application landing zones, management groups, subscriptions, policy inheritance, connectivity, identity, governance, security, management, and platform automation. The design-areas guidance explicitly calls out billing/tenant, identity/access, resource organization, network topology/connectivity, security, management, governance, and platform automation/DevOps as decisions that affect the foundation.
+- 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-landing-zone-architect/references/safety-checklist.md

@@ -0,0 +1,29 @@
+# Safety Checklist
+
+## Evidence labels
+
+- `documentation-based`: grounded in Microsoft Learn or official Kubernetes documentation where listed.
+- `sampled-current-state`: grounded in read-only Azure or Kubernetes 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, rotate, purge, recover, apply, restart, drain, cordon, scale, rollout, role-assignment, policy-assignment, or network changes unless the user explicitly asks and approval is clear.
+- Prefer preview, dry-run, status, describe, what-if, list, show, and policy evaluation evidence before any mutation.
+
+## Credential and data boundary
+
+- Never ask users to paste credentials, tokens, tenant IDs, subscription IDs, customer data, private keys, kubeconfig contents, CA requester credentials, secret values, or connection strings.
+- 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 rollback, or missing owner for high-impact assets.
+- Treat broad permissions, permanent privileged access, public exposure, purge authority, destructive operations, and live rollout changes as high-risk.
+- Separate documented product behavior from sampled configured-environment evidence.
+
+## Asset-specific hard line
+
+Do not prescribe a one-size-fits-all hierarchy, broad admin grants, or production-ready verdict without identity, governance, security, management, network, subscription, cost, and recovery dependencies being addressed.

package/skills/azure/azure-landing-zone-architect/references/workflow-and-output.md

@@ -1,86 +1,30 @@
 # Workflow and Output Contract
 
-## Workflow
+## Execution flow
 
-1. Classify the operating context.
-   - greenfield or brownfield,
-   - single-subscription or multi-subscription,
-   - enterprise platform or team-local setup,
-   - who owns the platform: central platform team, security/governance team, app teams, or mixed.
-2. State missing facts before pretending certainty.
-   - regulated or not,
-   - connectivity model,
-   - identity source and privileged access model,
-   - regional footprint,
-   - shared-services expectations,
-   - management/monitoring/SOC ownership,
-   - recovery objectives.
-3. Map the problem to landing-zone design areas.
-   - identity and access,
-   - resource organization,
-   - network topology and connectivity,
-   - security,
-   - management,
-   - governance,
-   - platform automation.
-4. Define the target platform model.
-   - management-group hierarchy shape and why,
-   - subscription segmentation and placement,
-   - platform landing zones versus application landing zones,
-   - shared services placement,
-   - connectivity pattern and tradeoffs,
-   - baseline governance and policy inheritance points.
-5. Stress-test dependencies that are often skipped.
-   - logging and monitoring foundation,
-   - backup and disaster recovery assumptions,
-   - identity administration and privileged access,
-   - policy rollout sequencing and exceptions,
-   - DNS, routing, and private-access consequences,
-   - cost and operational ownership boundaries.
-6. Challenge unsafe defaults.
-   - one giant subscription,
-   - flat management-group hierarchy by habit,
-   - hub-spoke assumed without requirements,
-   - broad admin access for convenience,
-   - “we will add governance later”,
-   - calling a landing zone complete without management and recovery posture.
-   - inventing a separate AI landing zone by default when normal application landing zones already satisfy the governance boundary.
-7. Route narrower follow-up work when needed.
-   - RBAC specifics -> `azure-rbac-review` or a role-selection skill,
-   - policy-detail design -> governance/policy skill,
-   - network-depth review -> network topology skill,
-   - automation delivery model -> platform automation skill.
+1. Scope the exact asset, environment boundary, owner, and requested decision.
+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.
 
-## Output contract
+## Required output
 
-Return all of the following:
+- `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.
 
-- **Architecture verdict**: whether the current or proposed landing-zone model is sound, risky, or incomplete.
-- **Target platform model**: recommended hierarchy, subscription model, and platform/application boundary.
-- **Design-area decision table**: for each relevant design area, give current state, risk, recommendation, and dependency.
-- **Unresolved risks**: explicit gaps, assumptions, and blocked decisions.
-- **Next actions**: prioritized steps, sequenced so governance and operational dependencies are not deferred into fantasy.
-- **Evidence used**: Microsoft Learn pages and any Azure MCP namespaces actually used.
+## Stress checks
 
-## Eval gate
+- What assumption would make this recommendation unsafe?
+- Which role, policy, network, lifecycle, or rollout action has the largest blast radius?
+- What evidence would disprove the claimed readiness?
+- Is the answer accidentally treating documentation as tenant-specific proof?
 
-The skill output is not acceptable unless it:
+## Response discipline
 
-1. distinguishes greenfield versus brownfield context,
-2. identifies platform ownership assumptions,
-3. covers every relevant landing-zone design area,
-4. separates platform landing zones from application landing zones,
-5. addresses management-group and subscription placement,
-6. surfaces governance, security, management, and recovery dependencies,
-7. states assumptions and unknowns explicitly,
-8. avoids broad-admin or one-size-fits-all hierarchy advice.
-
-Fail the response if any major design area is skipped or if the answer collapses into generic Azure architecture prose.
-
-## Safety notes
-
-- Do not recommend a single canonical management-group hierarchy without business and governance context.
-- Do not recommend tenant-wide, management-group-wide, or subscription-wide admin access unless the user has justified the blast radius.
-- Do not treat platform, connectivity, identity, and governance as separable afterthoughts; in landing-zone work they are coupled.
-- Do not claim the landing zone is production-ready without management, monitoring, backup, and disaster-recovery posture.
-- Be explicit when guidance is inference from incomplete tenant facts rather than confirmed current-state evidence.
+Use Microsoft Learn documentation through the user's configured documentation MCP for documented landing-zone design areas and patterns. Use sampled read-only Azure evidence only to inspect current hierarchy, policies, RBAC, resources, and diagnostics, and label it as sampled evidence.

package/skills/azure/azure-live-aks-rollout-guard/SKILL.md

@@ -4,8 +4,8 @@ description: Guard live AKS deployment rollouts with PDB audit, maxUnavailable/s
 allowed-tools: Read Grep Glob WebFetch
 metadata:
   author: "github: Raishin"
-  version: "0.1.0"
-  updated: "2026-05-05"
+  version: 0.1.4
+  updated: "2026-06-05"
   category: delivery
 ---
 
@@ -25,7 +25,7 @@ Use this skill when:
 
 ## Lean operating rules
 
-- Prefer Azure CLI (`az`) official documentation when available; fall back to Microsoft Learn docs and sanitized user evidence.
+- Prefer Microsoft Learn documentation through the user's configured documentation MCP; use sampled read-only Azure or Kubernetes evidence when the active client exposes it, then sanitized user evidence.
 - Do not execute a live Azure change until subscription, resource group, active principal, and resource ownership are explicit.
 - Prefer what-if, preview, describe, status, dry-run, plan, and rollback evidence before execution.
 - If the request skips preview or rollback design, push back.
@@ -36,9 +36,13 @@ Use this skill when:
 
 Load these only when needed:
 
+- [Azure AKS Rollout Operations](references/aks-rollout-operations.md) — use for current service behavior, common failure modes, hard design rules, verification targets, and push-back conditions.
 - [Preflight commands](references/preflight-commands.md) — CLI commands to run before any mutation.
 - [Rollback playbook](references/rollback-playbook.md) — concrete rollback steps for this service.
 - [Permission model](references/permission-model.md) — RBAC role definitions and PIM guidance.
+- [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing documentation-based evidence, sampled read-only evidence, or sanitized user evidence.
+- [Safety checklist](references/safety-checklist.md) — use for evidence labels, live-operation gates, approval rules, credential boundaries, and current-state caveats.
+- [Workflow and output contract](references/workflow-and-output.md) — execution flow and final response contract.
 - [Official sources](references/official-sources.md) — authoritative Azure documentation links.
 
 ## Response minimum