@raishin/vanguard-frontier-agentic 2.8.0 → 2.9.0

package/skills/aws/aws-waf-security-review/references/official-sources.md

@@ -1,30 +1,29 @@
-# Official Sources
+# Official sources
 
-Use when grounding AWS WAF Security Pillar behavior or citing documentation.
+Use this reference only when you need source grounding for AWS service behavior or the detailed source list.
 
-## AWS WAF Security Pillar
+## AWS documentation
 
+Use these as starting points, not as proof of the user's live AWS state:
 - https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html
-- https://docs.aws.amazon.com/wellarchitected/latest/framework/a-security.html
-
-## Identity and access
-
+- https://docs.aws.amazon.com/wellarchitected/latest/framework/security.html
 - https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html
-- https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html
-- https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html
+- https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub-v2.html
 
-## Detective controls
+## Grounding rule
 
-- https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html
-- https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html
-- https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html
+Official documentation explains AWS service behavior. It does not prove the user's current account, Region, quota, resource configuration, IAM boundary, pricing, entitlement, or operational state. Prefer read-only AWS MCP or CLI evidence, repository evidence, or sanitized user-provided evidence for current-state claims.
 
-## Data protection
+## Current MCP/documentation refresh (2026-06-02)
 
-- https://docs.aws.amazon.com/kms/latest/developerguide/overview.html
-- https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html
-- https://docs.aws.amazon.com/macie/latest/user/what-is-macie.html
+Service facts from official docs:
+- The Well-Architected Security Pillar focuses on protecting data, systems, and assets while delivering business value through risk assessments and mitigation strategies.
+- Security review domains include identity and access management, detective controls, infrastructure protection, data protection, and incident response.
 
-## Grounding rule
+Sampled live evidence:
+- Read-only API availability sampling reported `WellArchitected+GetWorkload` as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Read-only product/API sampling also reported Security Hub and `SecurityHub+GetFindings` available in the sampled regions, but that does not prove detector coverage or finding remediation.
 
-Official documentation explains service behavior — not the user's current account state. Prefer live AWS MCP evidence or sanitized user-provided evidence for current-state claims.
+Review implications:
+- Require IAM evidence, logging/detection coverage, network and workload protection, encryption/data-boundary controls, vulnerability posture, incident-response readiness, and exception tracking.
+- Do not claim Well-Architected security readiness from questionnaire answers without live/repo evidence.

package/skills/aws/aws-waf-security-review/references/well-architected-security-review.md

@@ -0,0 +1,59 @@
+# Well-Architected Security Review Guide
+
+Use this reference for AWS Well-Architected Framework Security Pillar reviews. In this repository, `aws-waf-security-review` means Well-Architected Framework review, not AWS Web Application Firewall configuration.
+
+## What people get wrong
+
+The lazy story is:
+
+> Security review is checking IAM, encryption, and public access.
+
+Wrong. Security posture is an end-to-end control system: identity, detection, infrastructure protection, data protection, vulnerability management, and incident response must all have evidence.
+
+Common bad assumptions:
+
+- No Security Hub finding means secure.
+- Encryption enabled means data protection is complete.
+- IAM managed policies are least privilege.
+- CloudTrail exists, so detective controls are covered.
+- Network private means workload secure.
+- Incident response is ready because a runbook exists.
+
+## Security-specific failure modes
+
+- Multi-account boundaries, SCPs, permission boundaries, and break-glass controls are undefined.
+- Static credentials, long-lived access keys, or broad cross-account trust remain active.
+- Logging/detection coverage is incomplete across accounts, Regions, services, or data planes.
+- KMS key policies, bucket policies, secrets, and data residency controls are unreviewed.
+- Public exposure hides behind CDN/API/LB layers or misconfigured security groups.
+- Findings have no owner, SLA, exception record, or verification after remediation.
+
+## Minimum safe workflow
+
+1. Confirm workload scope, accounts, Regions, data classification, regulatory context, and threat model.
+2. Review identity first: human access, workload roles, federation, privilege boundaries, and break-glass.
+3. Check detective controls: CloudTrail, Config, GuardDuty, Security Hub, IAM Access Analyzer, log retention, and alert routing.
+4. Review infrastructure and data protection: network exposure, KMS, secrets, storage policies, backups, and vulnerability posture.
+5. Check incident readiness: runbooks, contacts, containment paths, forensics logging, and game-day evidence.
+6. Prioritize findings by exploitability, blast radius, business impact, and remediation safety.
+7. Keep recommendations non-mutating unless a separate guarded operator workflow is invoked.
+
+## Verification targets
+
+- Organization/account structure, SCPs, permission boundaries, identity center/federation, MFA, and break-glass controls
+- IAM policies, trust policies, access analyzer findings, unused access, and credential age
+- CloudTrail, Config, GuardDuty, Security Hub, VPC Flow Logs, log destinations, retention, and alert paths
+- public exposure evidence across ALB/API Gateway/CloudFront/S3/security groups/routes
+- KMS key policies, secret rotation, S3/data-store encryption, backups, and data classification
+- incident response runbooks, contacts, tabletop/game-day evidence, and exception register
+
+## When to push back
+
+Push back if the user asks to:
+
+- claim security readiness from questionnaire answers alone
+- ignore unsupported accounts, Regions, or log gaps
+- widen IAM or network access as a shortcut
+- hide critical findings behind generic “best practice” language
+- treat encryption as proof of authorization or data minimization
+- confuse this Well-Architected Framework review with AWS Web Application Firewall rules

package/skills/azure/azure-ai-foundry-ops-governor/SKILL.md

@@ -4,8 +4,8 @@ description: Use this skill for Microsoft Foundry and Azure AI Foundry operation
 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: ai
 ---
 
@@ -16,7 +16,7 @@ metadata:
 Act as a ruthless Azure AI Foundry operations governor. Prevent access sprawl, quota collisions, weak isolation, and unsafe MCP mutations.
 
 Default posture:
-- Prefer live evidence from official Microsoft Foundry or Azure MCP capabilities when available.
+- Prefer Microsoft Learn documentation through the user's configured documentation MCP, and use sampled read-only Azure evidence only when the active client exposes it.
 - Treat the **Foundry resource** as the top-level governance, security, networking, monitoring, and deployment boundary.
 - Treat the **project** as the development boundary for teams, agents, files, evaluations, and project-scoped workflows.
 - Do not assume every API or feature works at project scope. Verify whether the workload requires parent resource scope.
@@ -35,7 +35,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 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.
@@ -44,7 +44,9 @@ Use this skill when the user asks to:
 
 Load these only when needed:
 
-- [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing live Azure evidence, confirming Microsoft MCP capability, or switching to documentation mode.
+- [Operations guide](references/foundry-ops-governance.md) — use for service-specific pitfalls, design rules, verification targets, and pushback criteria.
+- [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing documentation-based evidence, sampled read-only Azure evidence, or sanitized user evidence.
+- [Safety checklist](references/safety-checklist.md) — use for evidence labels, risk gates, mutation boundaries, approval rules, and credential boundaries.
 - [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-ai-foundry-ops-governor/metadata.json

@@ -23,11 +23,14 @@
     "https://learn.microsoft.com/en-us/azure/foundry/how-to/quota",
     "https://learn.microsoft.com/en-us/azure/foundry/foundry-models/quotas-limits",
     "https://learn.microsoft.com/en-us/azure/foundry/foundry-models/how-to/monitor-models",
-    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/"
+    "https://learn.microsoft.com/azure/foundry/mcp/security-best-practices",
+    "https://learn.microsoft.com/security/benchmark/azure/baselines/azure-ai-foundry-security-baseline",
+    "https://learn.microsoft.com/en-us/azure/security/fundamentals/ai-security-best-practices",
+    "https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai/platform/networking"
   ],
-  "security_notes": "Keep Foundry resource governance separate from project developer isolation, prefer Entra ID over key-based auth, verify quota and diagnostics before rollout, and treat MCP mutations as higher risk than read-only discovery, especially because hosted Foundry MCP security guidance documents preview and public-endpoint limitations.",
-  "last_verified": "2026-04-27",
+  "security_notes": "Keep Foundry resource governance separate from project developer isolation, prefer Entra ID over key-based auth, verify quota and diagnostics before rollout, and treat tool-backed mutations as higher risk than read-only discovery, especially because hosted Foundry MCP capability security guidance documents preview and public-endpoint limitations.",
+  "last_verified": "2026-06-05",
   "path": "skills/azure/azure-ai-foundry-ops-governor",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.3"
 }

package/skills/azure/azure-ai-foundry-ops-governor/references/foundry-ops-governance.md

@@ -0,0 +1,62 @@
+# Microsoft Foundry operations governance
+
+## What people get wrong
+
+- They treat a Foundry project as the whole security boundary. It is only a development boundary; connected services still need their own RBAC, networking, logging, and lifecycle controls.
+- They assign broad Azure roles because Foundry-specific roles feel new. That expands blast radius across model deployment, project management, and access assignment.
+- They discuss model rollout without proving regional feature support, deployment type, and quota. Documentation is not capacity evidence.
+- They enable tool or agent workflows before deciding which identity is allowed to read, write, delete, or assign access.
+- They design private access to Foundry but forget Storage, Key Vault, AI Search, registry, logging sinks, and outbound dependencies.
+
+## Officially grounded service shape
+
+Microsoft Learn describes a layered Foundry model: a top-level Foundry resource for governance, networking, security, monitoring, and deployments; projects for team development isolation; and connected Azure resources such as Storage, Key Vault, and AI Search under separate governance boundaries. RBAC is scope-sensitive and uses Foundry-specific built-in roles. Some role names were renamed, so automation should prefer stable role definition IDs where possible.
+
+## Non-negotiable design rules
+
+1. Identify whether each operation is resource-scoped, project-scoped, or connected-resource-scoped.
+2. Use least-privilege Foundry roles first; justify any Owner, Contributor, or custom role action.
+3. Prefer Microsoft Entra ID and managed identity. Treat keys as full-access secrets unless proven otherwise.
+4. Verify regional availability and quota for the exact deployment type before approving rollout.
+5. Verify network isolation for Foundry and every connected dependency.
+6. Require diagnostic settings or equivalent monitoring for operations, model usage, errors, and access changes.
+7. Put mutation approval behind blast-radius, rollback, and evidence review.
+
+## Minimal safe implementation flow
+
+1. Inventory intended teams, projects, model deployments, agent/tool usage, and connected resources.
+2. Map every persona and managed identity to the smallest Foundry and connected-resource scope.
+3. Validate target regions, features, deployment types, and quotas against Microsoft Learn and sampled configured-environment evidence if available.
+4. Validate private access and outbound paths for Foundry plus Storage, Key Vault, AI Search, registry, and monitoring sinks.
+5. Confirm diagnostics, retention, alerting, and access-review ownership.
+6. Run a preproduction rollout with the same role, network, and quota shape as production.
+7. Approve production only with a rollback plan for access, networking, deployments, and tool registration changes.
+
+## High-risk assumptions to kill
+
+- A project boundary is not enough for production isolation unless connected resources, model deployments, networking, diagnostics, and RBAC are separately verified.
+- A documented Foundry capability is not proof that the target region, deployment type, quota, or project scope can support the workload.
+- Managed identity only reduces key exposure if each identity has narrowly scoped permissions on Foundry and every connected resource.
+- Private access to the Foundry resource does not automatically make Storage, Key Vault, AI Search, registry, monitoring, or agent outbound paths private.
+- Content safety or guardrail configuration is not production readiness unless intervention points, model deployment scope, logging, and operational ownership are defined.
+
+## Safe command/code verification targets
+
+- Inspect infrastructure definitions for `Microsoft.CognitiveServices/accounts`, `Microsoft.CognitiveServices/accounts/projects`, deployments, private endpoint, diagnostic setting, and role-assignment resources.
+- Verify automation distinguishes resource-scope and project-scope operations before creating deployments, projects, agents, evaluations, or connections.
+- Check policy-as-code or templates for private DNS, Key Vault, Storage, AI Search, and log destination wiring rather than only the Foundry resource.
+- Review scripts for secret material, key-based auth, broad `Owner` or `Contributor` grants, and unguarded delete/update actions.
+- Confirm generated evidence labels separate Microsoft Learn documentation from sampled configured-environment evidence.
+
+## Safe verification targets
+
+- Role assignments at Foundry resource and project scopes.
+- Managed identity assignments on project and connected resources.
+- Model deployment type, region, capacity, and quota.
+- Public network access, private endpoint, DNS, and outbound dependency paths.
+- Diagnostic settings and log destinations.
+- Guardrail and tool-registration configuration where applicable.
+
+## When to push back
+
+Push back on production approval from diagrams only, broad role grants, project-only isolation claims, region-agnostic quota claims, key-based automation, or tool operations without an approval and rollback boundary.

package/skills/azure/azure-ai-foundry-ops-governor/references/mcp-and-evidence.md

@@ -1,34 +1,27 @@
-# MCP and Evidence Path
+# MCP and evidence path for Microsoft Foundry operations governance
 
-## Official Azure / Foundry MCP Linkage
+Use Microsoft Learn documentation through the user's configured documentation MCP as the first grounding path for Azure service behavior. This file defines evidence boundaries; it must not imply that documentation proves the user's tenant, subscription, RBAC, quotas, deployed resources, or production readiness.
 
-Use only official Microsoft MCP surfaces documented for this role.
+## Evidence ladder
 
-Preferred order:
-1. **Foundry MCP Server** for Foundry-native operations when the active client exposes it.
-2. **Azure MCP Server** for adjacent Azure evidence such as monitoring, quotas, and Key Vault-backed dependency checks.
-3. **Portal / CLI / documentation fallback** when the required capability is absent or write safety is unclear.
+1. `docs_only`: Microsoft Learn documentation and official architecture guidance. Use for documented behavior, caveats, and safe review criteria.
+2. `sampled_read_only`: configured-environment evidence from read-only tools, if available and explicitly scoped. Use only for the sampled resource/time window.
+3. `user_supplied`: sanitized outputs, IaC, diagrams, or metrics provided by the user. Treat as unverified unless independently checked.
+4. `mutation_ready`: documentation plus current-state evidence plus explicit approval, blast-radius statement, and rollback path.
 
-Rules:
-- Do **not** invent MCP namespaces or assume a namespace exists because it would be convenient.
-- Discover tool availability first, then map the request to the exposed capability.
-- Treat read/list/query operations as lower risk than create/update/delete operations.
-- For mutating operations, require explicit confirmation of target scope, environment, and rollback path.
-- If using Foundry MCP Server, remember Microsoft documents it as preview and documents public-endpoint and cross-region processing caveats.
+## Rules
 
-## Platform-Agnostic Execution
+- Do not expose environment-specific implementation details in committed docs or user-facing guidance.
+- Do not ask for credentials, tokens, tenant identifiers, subscription identifiers, connection strings, private keys, customer data, or raw secrets.
+- If current-state evidence was not sampled, say `not sampled`; do not imply it.
+- If evidence is representative or partial, say so. A sample does not prove broad regional availability or production readiness.
+- Prefer read-only evidence before mutation planning. Stop for approval before write operations.
 
-This skill must work in MCP-only, portal-guided, CLI-guided, macOS, Linux, and Windows environments.
+## Final-answer evidence language
 
-When examples are needed:
-- use neutral placeholders like `<subscription>`, `<resource-group>`, `<foundry-resource>`, and `<project>`,
-- avoid shell-specific assumptions until the platform is known,
-- prefer evidence collection and decision framing over long command dumps.
+Use phrases like:
 
-## Documentation Fallback When Live Data Is Unavailable
-
-If live access is missing, denied, incomplete, or unsafe:
-- ground recommendations in official Microsoft Learn documentation only,
-- label conclusions as `live evidence`, `documentation-based`, `sanitized user evidence`, or `inference`,
-- do not present documentation as proof of the user's current state,
-- ask for sanitized scope details only when needed: subscription layout, resource count, project count, regions, environment split, or redacted screenshots.
+- "Based on Microsoft Learn documentation..."
+- "Configured-environment evidence was not sampled in this review."
+- "The following is an inference from the provided configuration, not proven live state."
+- "This recommendation is mutation-ready only after explicit approval and rollback review."

package/skills/azure/azure-ai-foundry-ops-governor/references/official-sources.md

@@ -1,25 +1,29 @@
-# Official Sources
+# Official sources for Azure AI Foundry Ops Governor
 
-## References
+Use this file to ground reviews in Microsoft Learn documentation through the user's configured documentation MCP. Documentation evidence proves Microsoft-published behavior; it does not prove the user's tenant, RBAC, quotas, network routes, deployed resources, or production readiness.
 
-Load only what is needed:
-- Microsoft Foundry architecture
-- Microsoft Foundry rollout planning
-- Foundry RBAC guidance
-- Foundry MCP security best practices
-- Foundry network isolation guidance
-- Foundry quota and monitoring guidance
-- Azure MCP Server tools inventory
+## Primary Microsoft Learn sources
 
-## Official Sources
+| Source | Review implication |
+| --- | --- |
+| [Microsoft Foundry architecture](https://learn.microsoft.com/en-us/azure/foundry/concepts/architecture) | Treat the Foundry resource as the governance/security/network/deployment boundary and projects as team development boundaries. Verify connected resources separately. |
+| [Role-based access control for Microsoft Foundry](https://learn.microsoft.com/en-us/azure/foundry/concepts/rbac-foundry) | Validate scope and role fit. Do not recommend broad Owner/Contributor when Foundry-specific roles or split data/control-plane roles are enough. |
+| [Azure AI security best practices](https://learn.microsoft.com/en-us/azure/security/fundamentals/ai-security-best-practices) | Ground network isolation, least privilege, model governance, secure compute, and monitoring recommendations. |
+| [Configure secure networking for Azure AI platform services](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai/platform/networking) | Use for private endpoint and supporting-service network-boundary checks. |
+| [Foundry Model Context Protocol security best practices](https://learn.microsoft.com/en-us/azure/foundry/mcp/security-best-practices) | Use only for Foundry product MCP behavior, identity, RBAC categories, and Conditional Access review. Do not confuse product documentation with evidence about this user's runtime. |
+| [Feature availability across cloud regions](https://learn.microsoft.com/en-us/azure/foundry/reference/region-support) | Confirm model, agent, evaluation, and feature regional support before endorsing a rollout. |
+| [Azure OpenAI quotas and limits](https://learn.microsoft.com/en-us/azure/foundry/openai/quotas-limits) | Treat quota as regional and deployment-dependent; require configured-environment evidence before claiming capacity. |
+| [Agent Service limits, quotas, and regions](https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/limits-quotas-regions) | Use for agent-specific limit checks; do not extrapolate from model quota alone. |
 
-- Microsoft Foundry architecture: https://learn.microsoft.com/en-us/azure/foundry/concepts/architecture
-- Role-based access control for Microsoft Foundry: https://learn.microsoft.com/en-us/azure/foundry/concepts/rbac-foundry
-- Microsoft Foundry rollout across my organization: https://learn.microsoft.com/en-us/azure/foundry/concepts/planning
-- Foundry MCP Server security best practices: https://learn.microsoft.com/en-us/azure/foundry/mcp/security-best-practices?view=foundry
-- Configure network isolation for Microsoft Foundry: https://learn.microsoft.com/en-us/azure/foundry/how-to/configure-private-link
-- Configure managed virtual network for Microsoft Foundry projects: https://learn.microsoft.com/en-us/azure/foundry/how-to/managed-virtual-network
-- Manage and increase quotas for Foundry resources: https://learn.microsoft.com/en-us/azure/foundry/how-to/quota
-- Microsoft Foundry Models quotas and limits: https://learn.microsoft.com/en-us/azure/foundry/foundry-models/quotas-limits
-- Monitor model deployments in Microsoft Foundry Models: https://learn.microsoft.com/en-us/azure/foundry/foundry-models/how-to/monitor-models
-- Azure MCP Server tools inventory: https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/
+## Source-grounding rules
+
+- Documentation claim: cite the relevant Microsoft Learn source and state it as documented behavior.
+- Current environment claim: require sampled read-only Azure evidence or user-provided sanitized output.
+- Inference: label it as inference and identify the missing proof.
+- Unsupported claim: do not include it. Push back and ask for safe evidence instead.
+
+## Release-note deltas to keep current
+
+- Foundry role names can appear under old or new names during rollout. Prefer role definition IDs when writing automation, and explain the rename instead of treating one label as wrong.
+- Some APIs and UI paths are project-scoped while others remain resource-scoped. Verify scope before recommending automation.
+- Regional availability varies by model, deployment type, agents, evaluations, and quota. A successful design in one region does not prove availability in another.

package/skills/azure/azure-ai-foundry-ops-governor/references/safety-checklist.md

@@ -0,0 +1,37 @@
+# Safety checklist for Azure AI Foundry Ops Governor
+
+## Non-negotiable gates
+
+- Do not ask for keys, connection strings, tokens, tenant identifiers, subscription identifiers, private data, or prompts containing customer data.
+- Prefer Microsoft Entra ID and managed identity. Treat key-based authentication as a risk because it bypasses granular RBAC boundaries.
+- Separate Foundry resource scope from project scope before reviewing access, quota, networking, or deployment rights.
+- Verify connected Storage, Key Vault, AI Search, networking, logging, and monitoring as separate Azure resources; do not assume Foundry configuration governs them.
+- Require explicit approval before any write, delete, role assignment, network change, deployment change, model deployment, quota movement, diagnostic retention, guardrail, tool-registration, or data residency mutation.
+
+## High-risk assumptions to kill
+
+- "Project isolation means dependency isolation." It does not; connected resources have their own access and network controls.
+- "Contributor is fine for developers." Usually too broad; challenge with Foundry-specific roles and scoped assignments.
+- "The model is available because it appears in docs." Docs do not prove regional or tenant quota availability.
+- "Private endpoint on Foundry secures the whole workload." Supporting resources and outbound paths still need verification.
+- "Tool access is harmless because it is just an assistant." Tool operations inherit identity, RBAC, policy, network, and approval risks.
+
+## Evidence labels
+
+- `docs_only`: Microsoft Learn evidence only. Safe for design guidance, not for tenant assertions.
+- `sampled_read_only`: read-only configured-environment evidence was sampled. State exact scope and timestamp in the answer.
+- `user_supplied`: sanitized user evidence was provided. State that it was not independently verified.
+- `mutation_ready`: docs plus current-state evidence plus explicit approval plus rollback path exist.
+
+## Mutation boundaries
+
+Block or escalate when a plan changes RBAC assignments, project membership, network/public access, Key Vault connections, model deployment or deletion, quota allocations, diagnostic retention, guardrails, tool registration, or data residency posture.
+
+## Minimum safe evidence before approval
+
+- Target Foundry resource and project boundary identified without exposing sensitive IDs.
+- Role scope and role definition checked against Microsoft Learn.
+- Region, deployment type, quota, and feature availability checked for the target scenario.
+- Connected resources reviewed for RBAC, network, and secret boundaries.
+- Diagnostics and audit trail destination identified.
+- Rollback or break-glass path documented for each planned change.

package/skills/azure/azure-ai-foundry-ops-governor/references/workflow-and-output.md

@@ -1,96 +1,39 @@
-# Workflow and Output Contract
+# Workflow and output contract for Azure AI Foundry Ops Governor
 
-## Safe Workflow
+## Minimal safe workflow
 
-1. **Classify the boundary**
-   - Identify tenant, subscription, resource group, Foundry resource, and project scope.
-   - Decide whether the question is resource-governance, project-operations, or connected-resource governance.
+1. Classify the request: architecture review, RBAC review, quota planning, network isolation, observability, or mutation approval.
+2. Load Microsoft Learn evidence through the user's configured documentation MCP. Use official sources before drawing conclusions.
+3. Define the scope: Foundry resource, project, connected resource, region, deployment type, and environment. If any are unknown, label the review as partial.
+4. Build the evidence table: documentation-based claims, sampled read-only evidence if available, sanitized user evidence, and explicit unknowns.
+5. Stress test the design against separation of concerns, least privilege, quota, regional support, network isolation, secret flow, diagnostics, and rollback.
+6. Produce a verdict with blockers, safe next actions, and open questions.
+7. For any mutation request, require explicit user approval after showing blast radius and rollback.
 
-2. **Verify resource vs project fit**
-   - Check whether the workload can live at project scope.
-   - If a required API or capability stays at parent resource scope, do not fake project isolation; recommend separate Foundry resources where justified.
-
-3. **Review RBAC and identity model**
-   - Prefer Entra ID and least privilege.
-   - Separate admin, project manager, and project user responsibilities.
-   - Challenge key-based access because Microsoft documents that keys bypass RBAC restrictions.
-
-4. **Review quota and deployment posture**
-   - Check current model quotas, deployment counts, rate limits, and cross-team contention risk.
-   - Distinguish experimentation quota from production quota.
-   - Call out 429 risk, PTU saturation risk, and quota ownership gaps.
-
-5. **Review network isolation and connected resources**
-   - Separate inbound access, outbound access from Foundry, and outbound access from agents.
-   - Check whether private endpoints, DNS, and dependent resources are part of the design.
-   - Remember Storage, Key Vault, and Azure AI Search keep their own governance boundaries.
-
-6. **Review logging and monitoring**
-   - Check metrics, audit logs, request/response logs, trace logs, and diagnostic settings.
-   - Call out when monitoring exists only on paper and not in routed diagnostics.
-
-7. **Gate MCP execution safety**
-   - Read-only discovery first.
-   - Mutations only after target, blast radius, approval path, and rollback are explicit.
-   - Default production changes to staged or nonproduction-first unless the user clearly authorizes otherwise.
-
-8. **Return a go / no-go verdict**
-   - Summarize blockers, residual risks, and the safest next actions.
-
-## Role-Specific Stress Checks
-
-- Are you confusing the Foundry resource governance boundary with the project development boundary?
-- Are you assuming project-scoped RBAC works for APIs that still require parent resource scope?
-- Are you recommending key-based auth even though it bypasses RBAC restrictions?
-- Are you proposing private access without DNS, Private Link, dependent-resource, or agent-network implications?
-- Are you claiming observability exists without diagnostic settings and actual destinations?
-- Are you proposing MCP writes without confirming preview status, public-endpoint limitations, rollback, and environment scope?
-- Are you treating quota as a one-team problem when multiple projects share the same resource-level constraints?
-
-## Output Template
+## Output contract
 
 ```markdown
-# Foundry Operations Governance Review: <scope>
-
 ## Verdict
-- Status: READY / READY WITH RISKS / NOT READY
-- Biggest risk:
-- Evidence level: live evidence / documentation-based / sanitized user evidence / inference
-
-## Scope
-- Subscription / resource group:
-- Foundry resource:
-- Project(s):
-- Environment: dev / test / prod
-- Requested action:
+<go | conditional-go | no-go | docs-only advisory>
 
-## Boundary decision
-- Resource-level controls:
-- Project-level controls:
-- Connected resources requiring separate governance:
-- Unsupported or parent-scope-only capabilities:
+## Evidence level
+- Documentation: <sources used>
+- Configured-environment evidence: <sampled / not sampled>
+- User-supplied evidence: <present / absent>
 
 ## Findings
-| Area | Finding | Severity | Evidence | Recommendation | Owner |
-|---|---|---|---|---|---|
+1. <risk or confirmed control> — Evidence: <docs_only|sampled_read_only|user_supplied|inference>
 
-## Safe execution plan
-1.
-2.
-3.
+## Blockers
+- <missing proof that prevents stronger conclusion>
 
-## Rollout blockers
--
+## Safe next actions
+- <least-privilege, reversible action>
 
 ## Open questions
--
+- <only questions required to reduce risk>
 ```
 
-## Red Flags
+## When to push back
 
-- One Foundry resource is being used as a catch-all for unrelated teams with no cost, quota, or access ownership.
-- The design assumes projects alone provide full isolation even when required APIs operate at parent resource scope.
-- The plan uses key-based auth for convenience instead of Entra ID and scoped RBAC.
-- Private networking is requested, but no one owns private DNS, private endpoints, or connected-resource approvals.
-- Diagnostics are called mandatory, but no Log Analytics, retention, or alert ownership exists.
-- MCP mutation is proposed directly against production without a staged validation path.
+Push back on requests that ask you to approve production readiness with no current-state evidence, grant broad roles, bypass private networking review, skip quota verification, hide tool mutations, or treat a single project as a full isolation boundary.

package/skills/azure/azure-aks-platform-operator/SKILL.md

@@ -4,8 +4,8 @@ description: Operate Azure Kubernetes Service with an adversarial production pos
 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: platform
 ---
 
@@ -32,10 +32,10 @@ Force exact answers on:
 
 Default access posture:
 
-- Prefer Azure MCP read-oriented evidence when the active client exposes useful AKS or related Azure namespaces.
+- Prefer Microsoft Learn documentation through the user's configured documentation MCP; use sampled read-oriented Azure evidence when the active client exposes useful AKS or related capabilities.
 - Otherwise fall back to official Microsoft documentation and sanitized user-provided evidence.
 - Never ask the user to paste kubeconfigs, tokens, client secrets, certificates, raw connection strings, or private cluster internals into chat.
-- Do not hard-code MCP server names, subscription IDs, cluster names, tenant IDs, resource groups, namespaces, or local paths.
+- Do not hard-code environment-specific identifiers, resource names, namespaces, or local paths.
 
 ## Trigger Situations
 
@@ -53,7 +53,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 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.
@@ -62,7 +62,9 @@ Use this skill when the user asks to:
 
 Load these only when needed:
 
-- [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing live Azure evidence, confirming Microsoft MCP capability, or switching to documentation mode.
+- [Operations guide](references/aks-platform-operations.md) — use for service-specific pitfalls, design rules, verification targets, and pushback criteria.
+- [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing documentation-based evidence, sampled read-only Azure evidence, or sanitized user evidence.
+- [Safety checklist](references/safety-checklist.md) — use for evidence labels, risk gates, mutation boundaries, approval rules, and credential boundaries.
 - [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-aks-platform-operator/metadata.json

@@ -14,17 +14,18 @@
   "summary": "Review AKS platform design and operations with a production operator lens across node pools, identity, network policy, scaling, upgrades, rollback safety, and observability readiness.",
   "source_type": "original",
   "official_docs": [
-    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/",
-    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/azure-kubernetes",
     "https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/containers/aks/baseline-aks",
     "https://learn.microsoft.com/en-us/azure/aks/upgrade-options",
     "https://learn.microsoft.com/en-us/azure/aks/upgrade-conceptual",
     "https://learn.microsoft.com/en-us/azure/aks/workload-identity-overview",
-    "https://learn.microsoft.com/en-us/azure/aks/network-policy-best-practices"
+    "https://learn.microsoft.com/en-us/azure/aks/network-policy-best-practices",
+    "https://learn.microsoft.com/en-us/azure/aks/best-practices-app-cluster-reliability",
+    "https://learn.microsoft.com/en-us/azure/well-architected/service-guides/azure-kubernetes-service",
+    "https://learn.microsoft.com/en-us/azure/architecture/operator-guides/aks/aks-upgrade-practices"
   ],
   "security_notes": "Do not wave through AKS as production ready without explicit upgrade, rollback, workload identity, traffic-control, subnet-capacity, and observability evidence. Treat flat pod networking, static secrets, and untested drain behavior as high-risk.",
-  "last_verified": "2026-04-27",
+  "last_verified": "2026-06-05",
   "path": "skills/azure/azure-aks-platform-operator",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.3"
 }