@raishin/vanguard-frontier-agentic 2.8.0 → 2.9.0

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

@@ -0,0 +1,41 @@
+# Workflow and output contract
+
+Use this reference for full execution of `azure-waf-cost-optimization-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-reliability-review/SKILL.md

@@ -3,104 +3,41 @@ name: azure-waf-reliability-review
 description: "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."
 allowed-tools: Read Grep Glob
 metadata:
-  author: "github: Raishin"
-  version: "0.1.0"
-  updated: "2026-05-09"
+  author: github: Raishin
+  version: 0.1.2
+  updated: "2026-06-05"
   category: resilience
 ---
 
-# Azure WAF Reliability Review
+# Azure WAF Reliability
 
-The Azure Well-Architected Framework Reliability pillar covers designing, building, and operating workloads that are resilient to failures, meet availability targets, and recover gracefully from disruptions.
+## Purpose
 
-## 5 Reliability Design Principles
+Act as a ruthless Azure reviewer for azure waf reliability work. Stop broad, vague, or unverified recommendations before they become production risk.
 
-1. **Design for business requirements** — translate business requirements into measurable reliability targets; define RTO, RPO, availability SLOs
-2. **Design for resilience** — ensure the workload survives fault conditions without complete outage; design for partial failure
-3. **Design for recovery** — assume failures will happen; implement automated recovery; test recovery procedures regularly
-4. **Design for operations** — build operations into the design; implement health modeling; use automated deployments
-5. **Keep it simple** — avoid design complexity that introduces reliability risks; use managed services to reduce operational burden
+## Lean operating rules
 
-## Azure Reliability Service Areas
+- Prefer Microsoft Learn documentation through the user's configured documentation MCP, then sampled read-only Azure evidence when available, then sanitized user evidence.
+- Separate confirmed facts from inference. If state was not queried or shown, say so.
+- Challenge broad access, broad scope, destructive changes, billing-impacting actions, 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.
 
-### Availability Zones
-- Zone-redundant services: ZRS Storage, Zone-redundant Azure SQL, AKS across zones
-- Zonal deployments: pin to specific zone for latency-sensitive workloads
-- Regional services: single-zone, not HA — use only for non-critical or dev/test workloads
+## References
 
-### Fault Tolerance
-- Azure Load Balancer (L4) — regional traffic distribution
-- Azure Application Gateway (L7) — zone-redundant HTTP/S load balancing with WAF
-- Azure Traffic Manager (DNS) — cross-region failover and weighted routing
-- Azure Front Door — global anycast with automatic failover
+Load these only when needed:
 
-### Scalability
-- VMSS (Virtual Machine Scale Sets) — VM-based horizontal scaling
-- Azure Kubernetes Service (KEDA, HPA) — pod and node autoscaling
-- Azure App Service autoscale — rule-based and metric-based scaling
-- Azure Functions consumption plan — event-driven serverless scaling
+- [Azure WAF Reliability Operations](references/waf-reliability-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.
 
-### Data Resilience
-- Azure SQL Business Critical — 2 readable secondaries, zone-redundant by default
-- Cosmos DB — multi-region writes, configurable consistency (strong/bounded-staleness)
-- Azure Storage GRS/GZRS — geo-redundant and geo-zone-redundant replication
-- Azure Backup — VM, SQL, and file share backup with retention policies
-- Azure Site Recovery (ASR) — VM replication and orchestrated failover
+## Response minimum
 
-### Health Modeling
-- Azure Monitor — metrics, logs, and alerting platform
-- Application Insights — distributed tracing, availability tests, failure analysis
-- Azure Service Health alerts — planned maintenance, outage notifications, advisories
-- Resource Health API — per-resource health signal for automated remediation
+Return, at minimum:
 
-### Chaos Engineering
-- Azure Chaos Studio — inject faults: VM availability zone failure, AKS pod failure, network latency, dependency unavailability
-
-### Deployment Safety
-- App Service deployment slots — blue/green with slot swap and auto-swap
-- Azure Deployment Environments — consistent, governed environment templates
-- Traffic Manager weighted routing — canary deployment with percentage-based traffic split
-
-## Azure SLA Key Facts
-
-- Availability Zones: **99.99%** SLA for VMs when using ≥2 VMs across ≥2 AZs
-- Azure SQL Business Critical + zones: **99.995%**
-- Cosmos DB multi-region writes: **99.999%**
-- Single VM with Premium SSD: **99.9%** — NOT suitable for production HA
-- Traffic Manager: **99.99%**
-
-## Assessment Questions
-
-- What are the availability and reliability targets for the workload?
-- How do you ensure the workload can operate during a zone or region outage?
-- How do you implement health monitoring and proactive alerting?
-- How do you manage dependencies and limit blast radius of failures?
-- How do you test resilience and validate recovery procedures?
-- How do you design for graceful degradation under load or partial failure?
-- How do you implement safe deployment practices to minimize rollback risk?
-
-## Validation Checklist
-
-- [ ] SLOs defined with measurable SLIs monitored via Azure Monitor
-- [ ] All stateful services (VMs, databases) deployed across ≥2 Availability Zones
-- [ ] Azure Service Health alerts configured for all services in use
-- [ ] Autoscaling enabled for stateless compute (VMSS, App Service, AKS node pools)
-- [ ] Azure SQL or Cosmos DB multi-region replication configured for mission-critical data
-- [ ] Azure Backup or ASR configured for VMs, SQL databases, and critical storage
-- [ ] Deployment slots or Traffic Manager canary routing used for production deployments
-- [ ] Azure Chaos Studio experiments conducted to validate AZ failure recovery
-- [ ] Circuit breaker and retry patterns implemented for external service calls
-- [ ] RTO/RPO targets documented and validated via DR drill in the last 12 months
-
-## Response Shape
-
-Availability targets review → AZ/region topology → health monitoring → failure tolerance → data resilience → deployment safety → chaos testing status → recommendations → open risks
-
-## Official Documentation
-
-- https://learn.microsoft.com/azure/well-architected/reliability/
-- https://learn.microsoft.com/azure/reliability/availability-zones-overview
-
-## Security Notes
-
-Read-only advisory. Do not modify autoscaling policies, backup schedules, or Azure Site Recovery 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-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.