@raishin/vanguard-frontier-agentic 2.8.0 → 2.10.0

package/skills/azure/azure-waf-reliability-review/metadata.json

@@ -3,16 +3,28 @@
   "name": "Azure WAF Reliability Review",
   "type": "skill",
   "provider": "azure",
-  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
-  "summary": "Review Azure workload reliability against the Well-Architected Framework Reliability pillar: availability targets, AZ/region topology, health monitoring, data resilience, deployment safety, and chaos testing.",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Azure workload reliability against the Well-Architected Framework Reliability pillar: business requirements, critical flows, resilience, recovery, observability, operations, simplicity, availability zones/regions, health modeling, and reliability testing.",
   "source_type": "original",
   "official_docs": [
     "https://learn.microsoft.com/azure/well-architected/reliability/",
-    "https://learn.microsoft.com/azure/reliability/availability-zones-overview"
+    "https://learn.microsoft.com/azure/well-architected/reliability/principles",
+    "https://learn.microsoft.com/azure/well-architected/reliability/reliability-test",
+    "https://learn.microsoft.com/azure/well-architected/reliability/disaster-recovery",
+    "https://learn.microsoft.com/azure/well-architected/design-guides/regions-availability-zones",
+    "https://learn.microsoft.com/azure/reliability/concept-business-continuity-high-availability-disaster-recovery",
+    "https://learn.microsoft.com/azure/reliability/overview-reliability-guidance"
   ],
-  "security_notes": "Read-only advisory. Do not modify autoscaling policies, backup schedules, or Azure Site Recovery configurations without explicit approval.",
-  "last_verified": "2026-05-09",
+  "security_notes": "Read-only advisory by default. Do not modify autoscaling, backup, failover, traffic routing, deployment, or recovery settings without explicit approval, current-state evidence, blast-radius review, and rollback or failback plan.",
+  "last_verified": "2026-06-05",
   "path": "skills/azure/azure-waf-reliability-review",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.2"
 }

package/skills/azure/azure-waf-reliability-review/references/mcp-and-evidence.md

@@ -0,0 +1,21 @@
+# MCP and evidence path
+
+Use this reference when deciding how to ground `azure-waf-reliability-review` guidance.
+
+## Evidence order
+
+1. Microsoft Learn documentation through the user's configured documentation MCP for documented Azure behavior.
+2. Sampled read-only Azure evidence when the user has configured it and current-state confirmation is necessary.
+3. Sanitized user-provided evidence when no read-only evidence path is available.
+4. Clearly labeled inference when evidence is incomplete.
+
+## Boundaries
+
+- Documentation evidence does not prove the user's tenant, subscription, RBAC, quotas, deployed resources, billing state, security posture, reliability state, or production readiness.
+- Sampled read-only evidence proves only the sampled configured environment and time window.
+- User-provided evidence can be incomplete or stale; preserve uncertainty.
+- Never ask for credentials, tokens, secrets, tenant IDs, subscription IDs, resource IDs, customer data, private keys, or raw incident payloads.
+
+## Required phrasing
+
+Use generic phrasing such as "Microsoft Learn documentation through the user's configured documentation MCP". Do not expose internal tool names, profile names, environment names, or local identifiers in committed docs.

package/skills/azure/azure-waf-reliability-review/references/official-sources.md

@@ -0,0 +1,23 @@
+# Official sources
+
+Use this reference when grounding current Azure behavior for `azure-waf-reliability-review`.
+
+## Microsoft Learn sources
+
+- https://learn.microsoft.com/azure/well-architected/reliability/principles
+- https://learn.microsoft.com/azure/well-architected/reliability/reliability-test
+- https://learn.microsoft.com/azure/well-architected/reliability/disaster-recovery
+- https://learn.microsoft.com/azure/well-architected/design-guides/regions-availability-zones
+- https://learn.microsoft.com/azure/reliability/concept-business-continuity-high-availability-disaster-recovery
+- https://learn.microsoft.com/azure/reliability/overview-reliability-guidance
+- https://learn.microsoft.com/azure/well-architected/reliability/checklist
+
+## Current documentation refresh (2026-06-05)
+
+- Microsoft Learn documentation through the user's configured documentation MCP is the primary source for documented Azure behavior.
+- Documentation evidence is not live customer-state evidence. It does not prove the user's tenant, subscription, RBAC, quotas, deployed resources, billing state, security posture, or production readiness.
+- Use sampled read-only Azure evidence only when the user has configured it and the task requires current-state confirmation. Label it as sampled evidence, not broad proof.
+
+## Grounding rule
+
+Docs explain service behavior. Current-state claims require sampled read-only evidence or sanitized user-provided evidence. If current state was not queried or shown, say so.

package/skills/azure/azure-waf-reliability-review/references/safety-checklist.md

@@ -0,0 +1,24 @@
+# Safety checklist
+
+Use before recommending production Azure changes, access grants, security remediation, hierarchy moves, cost actions, reliability changes, or readiness conclusions for `azure-waf-reliability-review`.
+
+## Non-negotiables
+
+- Do not ask for or print credentials, client secrets, certificates, private keys, access tokens, tenant IDs, subscription IDs, resource IDs, customer data, raw incident payloads, or environment-specific identifiers.
+- Prefer Microsoft Learn documentation through the user's configured documentation MCP for documented Azure behavior.
+- Use sampled read-only Azure evidence only for current-state claims and label it as sampled evidence.
+- Require explicit approval before recommending live mutation, broad access, destructive remediation, billing changes, commitment purchases, hierarchy moves, failover, failback, or alert suppression.
+- Keep recommendations least-privilege, reversible where possible, and scoped to the named resource or workload.
+- Separate documentation-based claims, sampled evidence, user-provided evidence, and inference.
+
+## Component risks
+
+- **Identity and roles:** broad privileged roles, direct user grants, wildcard custom roles, missing PIM/time-bound controls, inherited scope surprises.
+- **Security posture:** stored secrets, public exposure, missing managed identities, weak Key Vault boundaries, no diagnostic coverage, untracked policy exemptions.
+- **Resource organization:** flat hierarchy drift, fake isolation via resource groups, subscription sprawl, weak ownership, policy inheritance surprises.
+- **Cost:** optimizing recommendations without workload context, deleting resources without owner confirmation, buying commitments before rightsizing, ignoring licensing and reliability cost tradeoffs.
+- **Reliability:** vague SLOs, untested recovery, overengineered topology, missing health model, no dependency mapping, unvalidated chaos or failover assumptions.
+
+## Evidence labels
+
+Use `documentation-based`, `sampled read-only evidence`, `repo evidence`, `user-provided evidence`, or `inference`. Documentation alone never proves the user's live Azure environment.

package/skills/azure/azure-waf-reliability-review/references/waf-reliability-operations.md

@@ -0,0 +1,69 @@
+# Azure WAF Reliability Operations
+
+> Version note: Azure service behavior and tooling change over time. Verify exact command syntax, permissions, and feature availability against Microsoft Learn documentation through the user's configured documentation MCP before production use. Do not paste secrets or sensitive identifiers into commands, files, or chat.
+
+Use this reference for current, source-grounded service behavior and the hard review gates that the lean `SKILL.md` intentionally does not carry.
+
+## What people get wrong
+
+- Using generic uptime targets instead of critical user-flow reliability requirements.
+- Assuming redundancy exists because a service is managed by Azure.
+- Skipping dependency mapping and blast-radius analysis.
+- Treating backup existence as recovery proof.
+- Running chaos or failover tests without hypothesis, safety guardrails, and rollback.
+
+## Officially grounded service shape
+
+- Microsoft Learn evidence says reliability requires workloads to be resilient, recoverable, and available according to business promises.
+- Reliability design principles cover business requirements, resilience, recovery, operations, and simplicity.
+- Reliability guidance emphasizes critical user flows, realistic constraints, fault isolation, redundancy, self-healing, tested recovery plans, observable systems, failure simulation, automation, and avoiding unnecessary complexity.
+- Reliability testing verifies the workload can withstand faults, scale under demand, and recover within defined targets; testing must evolve as architecture and incidents reveal new weaknesses.
+
+Documentation evidence proves documented Azure service behavior. It does not prove the user's tenant, subscription, RBAC, quotas, deployed resources, billing state, security posture, or production readiness.
+
+## Non-negotiable design rules
+
+- Define reliability targets per critical user flow before proposing architecture.
+- Map dependencies and failure modes before approving redundancy claims.
+- Separate high availability, disaster recovery, backup, and operational readiness.
+- Require observability and actionable alerts for critical paths.
+- Test recovery and resilience safely before claiming readiness.
+
+## Minimal safe implementation flow
+
+- Scope workload, critical flows, business promises, regions/zones, dependencies, and recovery targets.
+- Collect architecture, health model, alerts, scaling, backup, deployment, failover, and test evidence.
+- Classify gaps in resilience, recovery, operations, simplicity, and service-specific reliability.
+- Prioritize fixes by user impact, blast radius, and reversibility.
+- Return reliability verdict, blockers, safe tests, target-state changes, and verification checks.
+
+## High-risk assumptions to kill
+
+- Azure service SLA equals workload reliability; workload reliability depends on architecture, dependencies, configuration, and operations.
+- Backup existence proves recoverability; restore and failback must be tested against RTO and RPO.
+- Availability zones or multiple regions automatically improve reliability; topology must match critical flows, data consistency, and operational capacity.
+- Chaos testing is always mature; unsafe tests without hypothesis, blast-radius controls, and stop conditions are reckless.
+- Monitoring dashboards prove health; alerts need ownership, thresholds, retained evidence, and incident response paths.
+
+## Safe command/code verification targets
+
+- Inventory critical flows, dependencies, zones/regions, health probes, autoscaling, backups, deployment slots, traffic routing, and alert rules read-only.
+- Verify SLO, RTO, and RPO per critical flow before judging architecture choices.
+- Check service-specific reliability guides for each major dependency rather than extrapolating from generic Azure behavior.
+- Review restore, failover, failback, and deployment rollback evidence before claiming readiness.
+- Label architecture inventory as sampled current-state evidence and Microsoft Learn references as documented service-behavior evidence.
+
+## Safe verification targets
+
+- SLOs, RTO, and RPO are documented per critical flow.
+- Dependencies and single points of failure are mapped.
+- Health model, metrics, logs, alerts, and ownership cover critical paths.
+- Backup, restore, failover, and failback are tested against targets.
+- Reliability tests have hypothesis, blast-radius controls, stop conditions, and rollback.
+
+## When to push back
+
+- The user wants reliability approval without critical-flow targets.
+- A managed service SLA is used as proof of workload reliability.
+- Recovery was never tested.
+- Chaos or failover testing would be unsafe or ownerless.

package/skills/azure/azure-waf-reliability-review/references/workflow-and-output.md

@@ -0,0 +1,41 @@
+# Workflow and output contract
+
+Use this reference for full execution of `azure-waf-reliability-review`.
+
+## Workflow
+
+1. **Classify the request**
+   - Identify service/domain, resource scope, environment, production impact, and whether mutation or billing impact is requested.
+   - Identify whether the task needs documentation-only guidance, sampled read-only current-state evidence, or sanitized user evidence.
+
+2. **Ground in current sources**
+   - Prefer Microsoft Learn documentation through the user's configured documentation MCP.
+   - Read the component operations guide before issuing design, safety, or readiness conclusions.
+   - Treat current-state claims as unproven unless supported by sampled read-only evidence or sanitized user-provided evidence.
+
+3. **Stress-test the plan**
+   - Kill broad permissions, vague ownership, missing rollback, missing validation, and unsupported production-readiness claims.
+   - Separate facts from inference.
+   - State blockers before recommendations.
+
+4. **Recommend minimal safe action**
+   - Prefer read-only inspection, preview, what-if, diagnostic query, cost forecast, or staged rollout before mutation.
+   - Require explicit approval for live, destructive, access, reliability, hierarchy, or billing-impacting actions.
+   - Keep the recommendation scoped and reversible where possible.
+
+5. **Validate and hand off**
+   - Name verification targets and evidence gaps.
+   - Provide safe next actions and escalation criteria.
+   - Do not claim tenant, subscription, resource, billing, quota, or posture state that was not observed.
+
+## Output contract
+
+Return:
+
+1. Scope and target
+2. Evidence level: documentation-based, sampled read-only evidence, user-provided evidence, repo evidence, or inference
+3. Key findings and risks
+4. Blockers or missing evidence
+5. Minimal safe next actions
+6. Verification targets
+7. Rollback, cleanup, expiry, or reversal path where applicable

package/skills/azure/azure-waf-security-review/SKILL.md

@@ -1,83 +1,53 @@
 ---
 name: azure-waf-security-review
-description: "Review Azure workload security posture against the Well-Architected Framework Security pillar: identity and access, network boundaries, data protection, threat detection, DevSecOps maturity, and policy compliance."
+description: "Review Azure workload security posture against the Well-Architected Framework Security pillar: identity and access, segmentation, data protection, threat detection, secure development lifecycle, incident response, and policy compliance."
 allowed-tools: Read Grep Glob
 metadata:
-  author: "github: Raishin"
-  version: "0.1.0"
-  updated: "2026-05-09"
+  author: github: Raishin
+  version: 0.1.1
+  updated: "2026-06-05"
   category: security
 ---
 
 # Azure WAF Security Review
 
-The Azure Well-Architected Framework Security pillar provides guidance for protecting workload data, systems, and assets while maintaining confidentiality and integrity.
+## Purpose
 
-## 8 Security Design Principles
+Act as a ruthless Azure workload security reviewer. Stop broad, vague, or unverified security claims before they become production risk.
 
-1. **Plan your security readiness** — understand security requirements, threats, and compliance obligations before building
-2. **Design to protect confidentiality** — prevent exposure of sensitive data through encryption, access controls, and data classification
-3. **Design to protect integrity** — detect and prevent unauthorized access to systems and data; use identity-based access
-4. **Design to protect availability** — defend against attacks that deny access to workloads; use DDoS protection and redundancy
-5. **Sustain and evolve your security posture** — continuously monitor, learn from incidents, and improve defenses
-6. **Defense in depth** — layer multiple security controls so no single failure exposes the workload
-7. **Zero trust** — verify explicitly, use least privilege access, assume breach
-8. **Minimize the blast radius** — limit the scope of impact from security incidents
+Use Microsoft Learn documentation and current-state evidence to judge whether a workload has credible controls for:
 
-## Azure Security Service Areas
+- security baseline and compliance alignment,
+- secure development lifecycle and threat modeling,
+- data classification and encryption,
+- identity, access, and workload identity boundaries,
+- network segmentation and egress/ingress controls,
+- resource hardening and secret protection,
+- threat monitoring, testing, and incident response.
 
-### Identity
-- Azure Active Directory (Entra ID), Conditional Access, MFA, Privileged Identity Management (PIM), Managed Identity
+## Lean operating rules
 
-### Network Security
-- Azure Firewall Premium, Azure Front Door + WAF, DDoS Protection Standard, Network Security Groups (NSG), Azure Private Link, Virtual Network Service Endpoints
+- 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, public exposure, unclassified data, missing logs, untested incident response, and hand-wavy production claims.
+- Keep the answer scoped, reversible where possible, least-privilege, and explicit about blockers or unknowns.
+- Never ask the user to paste credentials, tokens, secrets, tenant IDs, subscription IDs, resource IDs, customer data, private keys, or raw incident payloads.
 
-### Data Protection
-- Azure Key Vault (keys, secrets, certificates), Azure Disk Encryption, Storage Service Encryption, Always Encrypted (SQL), Microsoft Purview (data governance, sensitivity labels)
+## References
 
-### Threat Detection
-- Microsoft Defender for Cloud, Microsoft Sentinel (SIEM/SOAR), Azure Monitor, Defender for Servers/Containers/SQL/Storage/App Service
+Load these only when needed:
 
-### Governance
-- Azure Policy, Management Groups, Blueprints (deprecated → use Deployment Stacks), Microsoft Cloud Security Benchmark (MCSB)
+- [Azure WAF Security Operations](references/waf-security-operations.md) — use for current service behavior, common failure modes, hard design rules, verification targets, and push-back conditions.
+- [Safety checklist](references/safety-checklist.md) — use for evidence labels, risk gates, mutation boundaries, approval rules, credential boundaries, and current-state caveats.
+- [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing documentation-based evidence, sampled read-only evidence, or sanitized user evidence.
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, applying stress checks, or formatting the final answer.
+- [Official sources](references/official-sources.md) — use when you need the detailed Microsoft documentation list or source notes.
 
-### DevSecOps
-- GitHub Advanced Security (CodeQL SAST, secret scanning), Microsoft Defender for DevOps, Container image scanning in ACR, Infrastructure scanning (PSRule for Azure, Checkov)
+## Response minimum
 
-## Assessment Questions
+Return, at minimum:
 
-- How do you manage identity and access to your workload resources?
-- How do you protect your network boundaries?
-- How do you classify and protect your data?
-- How do you detect and respond to security threats?
-- How do you ensure your workload and supply chain are free of vulnerabilities?
-- How do you enforce and validate compliance with security policies?
-- How do you segment access and contain blast radius?
-
-## Validation Checklist
-
-- [ ] All human access uses Entra ID — no local accounts or shared credentials on Azure resources
-- [ ] Managed Identity used for all Azure service-to-service access — no client secrets or certificates in code
-- [ ] MFA enforced via Conditional Access for all users with Azure RBAC assignments
-- [ ] PIM used for privileged roles (Owner, Contributor, User Access Administrator) with approval workflow and just-in-time access
-- [ ] Azure Policy assignments block public storage accounts, unapproved VM SKUs, non-compliant regions
-- [ ] Microsoft Defender for Cloud Standard tier enabled across all subscriptions; security score tracked
-- [ ] All storage accounts and Key Vaults use Private Endpoints — no public network access
-- [ ] Key Vault soft-delete and purge protection enabled for all key vaults
-- [ ] Azure Monitor diagnostic settings enabled for all critical resources; logs sent to Log Analytics
-- [ ] Microsoft Sentinel connected to Log Analytics workspace with MCSB analytics rules enabled
-- [ ] NSG Flow Logs enabled for all production VNets
-- [ ] Container images scanned in ACR; Defender for Containers enabled for AKS
-
-## Response Shape
-
-Identity and access posture → network security assessment → data protection → threat detection coverage → DevSecOps maturity → policy compliance → prioritized recommendations → open risks
-
-## Official Documentation
-
-- https://learn.microsoft.com/azure/well-architected/security/
-- https://learn.microsoft.com/security/benchmark/azure/
-
-## Security Notes
-
-Read-only advisory. Do not modify Entra ID policies, Conditional Access rules, Azure Policy, or Defender configurations without explicit approval.
+- the scoped target and evidence level,
+- the main risks or control gaps,
+- the safest next actions,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/azure/azure-waf-security-review/metadata.json

@@ -3,16 +3,27 @@
   "name": "Azure WAF Security Review",
   "type": "skill",
   "provider": "azure",
-  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
-  "summary": "Review Azure workload security posture against the Well-Architected Framework Security pillar: identity and access, network boundaries, data protection, threat detection, DevSecOps maturity, and policy compliance.",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Azure workload security posture against the Well-Architected Framework Security pillar: baseline, secure development lifecycle, data classification, segmentation, IAM, networking, encryption, hardening, secrets, threat monitoring, security testing, and incident response.",
   "source_type": "original",
   "official_docs": [
-    "https://learn.microsoft.com/azure/well-architected/security/",
-    "https://learn.microsoft.com/security/benchmark/azure/"
+    "https://learn.microsoft.com/azure/well-architected/security/principles",
+    "https://learn.microsoft.com/azure/well-architected/security/checklist",
+    "https://learn.microsoft.com/security/benchmark/azure/introduction",
+    "https://learn.microsoft.com/azure/defender-for-cloud/concept-regulatory-compliance",
+    "https://learn.microsoft.com/azure/defender-for-cloud/secure-score-security-controls",
+    "https://learn.microsoft.com/azure/defender-for-cloud/review-security-recommendations"
   ],
-  "security_notes": "Read-only advisory. Do not modify Entra ID policies, Conditional Access rules, Azure Policy, or Defender configurations without explicit approval.",
-  "last_verified": "2026-05-09",
+  "security_notes": "Read-only advisory by default. Do not modify Entra ID, Conditional Access, RBAC, PIM, Azure Policy, Defender, Sentinel, network controls, Key Vault, or production diagnostics without explicit approval, current-state evidence, blast-radius review, and rollback plan.",
+  "last_verified": "2026-06-05",
   "path": "skills/azure/azure-waf-security-review",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.1"
 }

package/skills/azure/azure-waf-security-review/references/mcp-and-evidence.md

@@ -0,0 +1,30 @@
+# MCP and evidence path
+
+Use this reference to choose the right evidence path without leaking environment details.
+
+## Evidence order
+
+1. Microsoft Learn documentation through the user's configured documentation MCP for documented Azure behavior.
+2. Sampled read-only Azure evidence when the user has configured it and current-state posture matters.
+3. Sanitized user-provided evidence when read-only evidence is unavailable.
+4. Explicit inference only when evidence is incomplete.
+
+## What each evidence type proves
+
+- Microsoft Learn proves documented Azure service behavior, Well-Architected guidance, and Microsoft security recommendations.
+- Sampled read-only Azure evidence can prove observed configuration or API results in the configured environment at the time sampled.
+- User-provided evidence proves only what the user provided, and only if identifiers and secrets are sanitized.
+- Inference is not proof; label it and keep recommendations conditional.
+
+## What evidence does not prove
+
+- Documentation does not prove the user's tenant, subscriptions, RBAC, quotas, deployed resources, billing state, security posture, or production readiness.
+- Sampled read-only evidence does not prove broad regional availability, all accounts, all subscriptions, all resources, or future posture.
+- Secure score, compliance state, and recommendation counts do not prove risk acceptance, owner readiness, or incident-response capability.
+
+## Safe phrasing
+
+- “Microsoft Learn documentation through the user's configured documentation MCP says...”
+- “Sampled current-state evidence shows...”
+- “The current state was not queried, so this remains an assumption.”
+- “This recommendation is documentation-based and needs environment validation before production change.”

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

@@ -0,0 +1,36 @@
+# Official sources
+
+Use this reference when grounding current Azure behavior for `azure-waf-security-review`.
+
+## Microsoft Learn sources
+
+- https://learn.microsoft.com/azure/well-architected/security/principles
+- https://learn.microsoft.com/azure/well-architected/security/checklist
+- https://learn.microsoft.com/azure/well-architected/security/establish-baseline
+- https://learn.microsoft.com/azure/well-architected/security/secure-development-lifecycle
+- https://learn.microsoft.com/azure/well-architected/security/threat-model
+- https://learn.microsoft.com/azure/well-architected/security/data-classification
+- https://learn.microsoft.com/azure/well-architected/security/segmentation
+- https://learn.microsoft.com/azure/well-architected/security/identity-access
+- https://learn.microsoft.com/azure/well-architected/security/networking
+- https://learn.microsoft.com/azure/well-architected/security/encryption
+- https://learn.microsoft.com/azure/well-architected/security/harden-resources
+- https://learn.microsoft.com/azure/well-architected/security/application-secrets
+- https://learn.microsoft.com/azure/well-architected/security/monitor-threats
+- https://learn.microsoft.com/azure/well-architected/security/test
+- https://learn.microsoft.com/azure/well-architected/security/incident-response
+- https://learn.microsoft.com/security/benchmark/azure/introduction
+- https://learn.microsoft.com/azure/defender-for-cloud/concept-regulatory-compliance
+- https://learn.microsoft.com/azure/defender-for-cloud/secure-score-security-controls
+- https://learn.microsoft.com/azure/defender-for-cloud/review-security-recommendations
+
+## Current documentation refresh (2026-06-05)
+
+- Microsoft Learn documentation through the user's configured documentation MCP is the primary source for documented Azure behavior.
+- Documentation evidence is not live customer-state evidence. It does not prove the user's tenant, subscription, RBAC, quotas, deployed resources, billing state, security posture, or production readiness.
+- Use sampled read-only Azure evidence only when the user has configured it and the task requires current-state confirmation. Label it as sampled evidence, not broad proof.
+- Secure score, regulatory compliance, and MCSB mappings help prioritize controls, but they do not replace workload-specific threat modeling, ownership, testing, and incident response evidence.
+
+## Grounding rule
+
+Docs explain service behavior. Current-state claims require sampled read-only evidence or sanitized user-provided evidence. If current state was not queried or shown, say so.

package/skills/azure/azure-waf-security-review/references/safety-checklist.md

@@ -0,0 +1,28 @@
+# Safety checklist
+
+Use before Azure workload security reviews, hardening recommendations, policy/Defender changes, identity changes, network exposure decisions, incident-response claims, or production-readiness statements.
+
+## Non-negotiables
+
+- Do not ask for or print credentials, tokens, secrets, tenant IDs, subscription IDs, resource IDs, customer data, private keys, or raw incident payloads.
+- Keep the default mode read-only and advisory.
+- Require explicit approval before changing Entra ID, Conditional Access, RBAC, PIM, Azure Policy, Defender plans, Sentinel connectors, network controls, Key Vault settings, or production diagnostics.
+- Prefer managed identities and least privilege over stored secrets and broad standing privilege.
+- Separate Microsoft Learn documentation evidence from sampled read-only Azure evidence and sanitized user evidence.
+- Do not call a workload secure unless evidence covers identity, segmentation, data, secrets, logging, threat detection, vulnerability management, and incident response.
+- Treat paid-plan, preview, manual, and shared-responsibility controls as caveated evidence.
+
+## Component risks
+
+- **Identity and access:** broad Owner/Contributor grants, weak Conditional Access, standing privilege, unmanaged workload identities, stale service principals.
+- **Segmentation and networking:** public ingress, uncontrolled egress, flat networks, missing Private Link DNS review, NSG/firewall rules without owners.
+- **Data protection:** unclassified data, unmanaged keys, missing audit trails, untested backup/recovery security, exfiltration paths.
+- **Secrets:** secret values in code, app settings, pipelines, logs, tickets, or chat; missing rotation and emergency rotation.
+- **Policy and compliance:** broad deny effects without safe deployment, stale exemptions, compliance dashboards used as proof without control review.
+- **Threat monitoring:** unowned alerts, missing diagnostic settings, weak log retention, disconnected SecOps process.
+- **DevSecOps:** no threat model, no SAST/dependency/IaC/image scanning, findings without SLA or release gate.
+- **Incident response:** paper runbooks, unclear owner, no tabletop, no recovery security validation.
+
+## Evidence labels
+
+Use `documentation-based`, `sampled current-state evidence`, `repo evidence`, `user-provided evidence`, or `inference`. Documentation alone never proves the user's live Azure posture.

package/skills/azure/azure-waf-security-review/references/waf-security-operations.md

@@ -0,0 +1,75 @@
+# Azure WAF Security Operations
+
+> Version note: Azure service behavior and tooling change over time. Verify exact command syntax, permissions, feature availability, and recommendation semantics against Microsoft Learn documentation through the user's configured documentation MCP before production use. Do not paste secrets or sensitive identifiers into commands, files, or chat.
+
+Use this reference for current, source-grounded service behavior and the hard review gates that the lean `SKILL.md` intentionally does not carry.
+
+## What people get wrong
+
+- Treating a generic security checklist as proof of workload security.
+- Calling secure score, Defender coverage, or policy compliance production readiness without owner-reviewed evidence.
+- Equating encryption-at-rest defaults with complete data protection.
+- Assuming private endpoints or firewalls fix weak identity, secret handling, or egress paths.
+- Skipping threat modeling, secure-development controls, incident-response testing, and recovery security.
+
+## Officially grounded service shape
+
+- Microsoft Learn evidence says Well-Architected security starts from Zero Trust, the CIA triad, and recurring security improvement rather than one-time hardening.
+- The Security checklist covers baseline/compliance, secure development lifecycle and threat modeling, data classification, segmentation, strict IAM, network isolation, encryption, resource hardening, application secrets, threat monitoring, security testing, and incident response.
+- Microsoft security guidance says to verify explicitly, use least privilege for the right duration and assets, and assume breach with compensating controls that limit blast radius.
+- Defender for Cloud can assess resources against security standards such as Microsoft Cloud Security Benchmark, but documentation-based recommendations do not prove the user's configured posture.
+- MCSB and Defender compliance evidence can support prioritization, but preview controls, manual/shared responsibilities, exemptions, and paid-plan requirements must be labeled clearly.
+
+Documentation evidence proves documented Azure service behavior. It does not prove the user's tenant, subscription, RBAC, quotas, deployed resources, billing state, security posture, or production readiness.
+
+## Non-negotiable design rules
+
+- Define the workload boundary, data classification, critical flows, compliance drivers, owners, and production impact before judging security.
+- Require identity-first access, least privilege, time-bound privileged access, and workload identities before approving sensitive operations.
+- Require intentional segmentation across identity, network, resource organization, and data paths; do not treat a single perimeter as sufficient.
+- Require evidence for data protection, secret lifecycle, logging, threat monitoring, vulnerability management, and incident response.
+- Treat security recommendations as staged risk reduction, not as permission to mutate policies, networking, Defender plans, or identity controls without approval.
+
+## Minimal safe implementation flow
+
+- Scope workload, environments, data sensitivity, critical flows, compliance obligations, owners, and current evidence sources.
+- Collect Microsoft Learn documentation requirements and sampled read-only evidence when available for identity, network, data, policy, Defender, logging, secrets, and DevSecOps controls.
+- Classify gaps against Security checklist areas: baseline, SDL/threat model, classification, segmentation, IAM, networking, encryption, hardening, secrets, monitoring, testing, and incident response.
+- Prioritize fixes by exploitability, business impact, blast radius, reversibility, and owner readiness.
+- Return verdict, evidence level, blockers, staged remediation, validation checks, and residual risk.
+
+## High-risk assumptions to kill
+
+- “We use Azure, so default platform security is enough.”
+- “Secure score is high, so the workload is secure.”
+- “Private networking means attackers cannot reach the workload.”
+- “Encryption is enabled, so data protection is complete.”
+- “PIM exists, so privileged access is solved.”
+- “Defender/Sentinel is connected, so detection and response are ready.”
+- “No incidents means no security gaps.”
+
+Those are lazy assumptions.
+
+## Safe command/code verification targets
+
+- Inventory role assignments, privileged access paths, workload identities, Conditional Access dependencies, and secret usage with read-only queries.
+- Inspect segmentation evidence across resource organization, network boundaries, ingress, egress, private access, and data flows.
+- Review data classification, encryption configuration, key ownership, Key Vault posture, secret rotation, and audit logs without exposing secret values.
+- Query Defender recommendations, secure score controls, policy compliance, exemptions, diagnostic settings, alert rules, and log destinations as sampled current-state evidence.
+- Check secure-development controls such as threat models, dependency scanning, IaC scanning, image scanning, release gates, and vulnerability triage evidence.
+- Verify incident-response runbooks, alert ownership, escalation paths, tabletop/test evidence, and post-incident feedback loops before claiming readiness.
+
+## Safe verification targets
+
+- Security baseline maps to compliance requirements, platform recommendations, and workload-specific threats.
+- IAM is strict, conditional, auditable, least-privilege, and time-bound for privileged operations.
+- Data is classified and protected with encryption, key ownership, access controls, and audit trails matching sensitivity.
+- Network segmentation controls north-south and east-west traffic and has explicit egress handling.
+- Threat monitoring, alert routing, vulnerability management, testing, and incident response are owned and exercised.
+
+## When to push back
+
+- The user wants production-ready approval without workload boundary, data classification, or critical-flow context.
+- Broad roles, public exposure, static secrets, or unowned alerts are normalized as temporary shortcuts.
+- Defender, Sentinel, or policy is cited without current-state evidence and owner follow-up.
+- The recommendation would change identity, network, policy, or Defender settings without explicit approval, blast-radius review, and rollback plan.

package/skills/azure/azure-waf-security-review/references/workflow-and-output.md

@@ -0,0 +1,40 @@
+# Workflow and output contract
+
+Use this reference for full Azure Well-Architected Security reviews.
+
+## Workflow
+
+1. **Classify scope**
+   - Workload, environment, data sensitivity, critical flows, compliance obligations, owners, and production impact.
+   - Identity, network, data, secrets, monitoring, policy, DevSecOps, and incident-response surfaces in scope.
+
+2. **Ground in Microsoft Learn**
+   - Use Microsoft Learn documentation through the user's configured documentation MCP for current Well-Architected Security, MCSB, Defender, Policy, Key Vault, Entra, and Azure Monitor guidance.
+   - Treat commands and exact feature availability as version-sensitive until verified.
+
+3. **Collect current-state evidence when available**
+   - Read-only role assignments, identities, network exposure, Defender recommendations, secure score controls, policy compliance, exemptions, diagnostics, alerting, logs, secrets posture, and vulnerability controls.
+   - Do not retrieve secret values or raw customer payloads.
+
+4. **Stress test the posture**
+   - Ask what attacker path remains if identity is compromised.
+   - Ask what data can be exfiltrated if an app component is compromised.
+   - Ask which alerts fire, who owns them, and what runbook executes.
+   - Ask what breaks if a deny policy or private endpoint is rolled out too broadly.
+
+5. **Prioritize remediation**
+   - Fix broad access, public exposure, secret leakage, missing logs, and unowned alerts before nice-to-have maturity work.
+   - Stage disruptive changes and require rollback or safe-deployment plans.
+
+## Output contract
+
+Return:
+
+1. Scoped workload and evidence level
+2. Verdict: pass, conditional, or blocked
+3. Top security blockers
+4. Findings by Security checklist area
+5. Safe next actions in priority order
+6. Required approvals for any mutation
+7. Open questions and assumptions
+8. Evidence labels and source notes