@raishin/vanguard-frontier-agentic 2.7.1 → 2.9.0

package/skills/azure/azure-subscription-resource-organization/references/mcp-and-evidence.md

@@ -1,32 +1,21 @@
-# MCP and Evidence Path
+# MCP and evidence path
 
-## Official Azure MCP Linkage
+Use this reference when deciding how to ground `azure-subscription-resource-organization` guidance.
 
-Use official Azure MCP tools only if they are actually available in the active client.
+## Evidence order
 
-Preferred evidence path:
+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.
 
-- `subscription` for current subscription inventory and placement context.
-- `group` for resource-group inventory and workload grouping inside a subscription.
-- `group` only if the active client exposes an official group-related Azure capability; do not assume this means management-group mutation support.
+## Boundaries
 
-Important constraint:
+- 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.
 
-- The official Azure MCP documentation identified for this repo clearly documents subscription and resource-group tools. It does **not** prove that every client exposes management-group tools. If management-group inspection is unavailable, switch to documentation mode plus sanitized user-provided hierarchy evidence.
+## Required phrasing
 
-## Platform-Agnostic Execution
-
-This skill must work on macOS, Windows, Linux, and MCP-only clients.
-
-- Prefer Azure MCP evidence first when available.
-- When examples need commands or checks, keep them abstract with `<placeholders>` unless the user’s active platform and toolchain are known.
-- Do not anchor the workflow to Azure CLI, PowerShell, Terraform, or portal-only steps unless the user asks for that execution path next.
-
-## Documentation Fallback When Live Data Is Unavailable
-
-Live Azure evidence beats documentation for current-state questions. If live MCP data is unavailable, denied, incomplete, or unsafe to query:
-
-- Fall back to the Microsoft Learn references listed above.
-- Ask for sanitized hierarchy diagrams, subscription inventories, policy-assignment views, naming standards, or ownership maps if current-state proof matters.
-- Label conclusions as `live evidence`, `documentation-based`, `user-provided sanitized evidence`, or `inference`.
-- Do not pretend Microsoft Learn proves the user’s actual hierarchy, subscription sprawl, policy inheritance, or team ownership reality.
+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-subscription-resource-organization/references/official-sources.md

@@ -1,14 +1,26 @@
-# Official Sources
+# Official sources
 
-## References
+Use this reference when grounding current Azure behavior for `azure-subscription-resource-organization`.
 
-Ground conclusions only in these official Microsoft documentation paths and live Azure evidence when available:
+## Microsoft Learn sources
 
-- [Azure landing zone design areas](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-areas) — top-level design-area map and relationship to landing-zone structure.
-- [Azure landing zones overview](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/) — platform landing zones versus application landing zones and reference-architecture framing.
-- [Resource organization design area](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/resource-org) — management-group design, subscription design, naming, tagging, and scaling considerations.
-- [Management groups design guidance](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/resource-org-management-groups) — management-group depth, inheritance, and hierarchy recommendations.
-- [Governance design area](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/governance) — policy, compliance, and operating-model consequences of scope choices.
-- [Azure MCP tools inventory](https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/) — official Azure MCP namespace discovery and shared parameter behavior.
-- [Azure MCP subscription tools](https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/subscription) — official subscription inspection capability when available.
-- [Azure MCP resource-group tools](https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/resource-group) — official resource-group inspection capability when available.
+- https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/resource-org
+- https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/resource-org-management-groups
+- https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/resource-org-subscriptions
+- https://learn.microsoft.com/azure/cloud-adoption-framework/ready/azure-setup-guide/organize-resources
+- https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/management-application-environments
+- https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/governance
+- https://learn.microsoft.com/training/modules/design-governance/
+- https://learn.microsoft.com/azure/governance/management-groups/overview
+- https://learn.microsoft.com/azure/cloud-adoption-framework/ready/azure-best-practices/resource-tagging
+- https://learn.microsoft.com/azure/azure-resource-manager/management/tag-policies
+
+## 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-subscription-resource-organization/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-subscription-resource-organization`.
+
+## 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-subscription-resource-organization/references/subscription-resource-organization-operations.md

@@ -0,0 +1,69 @@
+# Azure Subscription Resource Organization 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 resource groups as the main isolation boundary for production environments.
+- Building a flat subscription estate then hoping tags fix governance later.
+- Moving subscriptions without understanding inherited policy and RBAC impact.
+- Mixing platform shared services and workload resources without owner boundaries.
+- Ignoring quotas, regions, naming, tagging, and lifecycle when designing hierarchy.
+
+## Officially grounded service shape
+
+- Microsoft Learn evidence says Azure resources can be organized at management group, subscription, resource group, and resource levels.
+- Resource organization decisions are foundational for naming, tagging, subscription design, and management group design.
+- Management groups manage policies, access, and compliance across subscriptions at scale; subscriptions act as policy and management boundaries and scale units.
+- Landing-zone guidance separates platform/management deployments from workload or application resources and recommends planning for scale, multiple regions, governance, and ownership.
+
+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
+
+- Choose hierarchy from governance, ownership, compliance, network, cost, and scale requirements, not aesthetics.
+- Use subscriptions as isolation, policy, management, and scale boundaries where environment or workload separation is needed.
+- Use resource groups for shared lifecycle, not as a substitute for subscription isolation.
+- Document policy/RBAC inheritance and exemption strategy before moving subscriptions.
+- Require naming, tagging, budget, and owner model for every proposed boundary.
+
+## Minimal safe implementation flow
+
+- Scope organization goal, current hierarchy, workloads, environments, regions, owners, compliance, and platform services.
+- Map management groups, subscriptions, resource groups, policies, RBAC, budgets, tags, and quotas.
+- Identify weak boundaries, inheritance surprises, and migration risks.
+- Propose minimal target-state changes with staged moves and rollback/communication plan.
+- Return target hierarchy, rationale, blockers, verification checks, and governance debt.
+
+## High-risk assumptions to kill
+
+- Tags can replace hierarchy; tags help reporting and policy targeting, but they are not first-class isolation boundaries.
+- Resource groups can isolate production from nonproduction; they share subscription-level policy, quota, billing, and many blast-radius concerns.
+- A flat hierarchy is simpler; it usually defers governance debt until policy, RBAC, and compliance inheritance become painful.
+- Subscription moves are administrative cleanup; they can change inherited policy, RBAC, budgets, compliance reporting, and operational ownership.
+- A landing-zone diagram proves suitability; current quotas, regions, ownership, and workload lifecycle still need evidence.
+
+## Safe command/code verification targets
+
+- Inventory management groups, subscriptions, resource groups, inherited policies, role assignments, tags, budgets, and quotas with read-only queries.
+- Compare proposed boundaries to workload lifecycle, owner, environment, compliance, network, and cost-accountability requirements.
+- Check management-group depth, parentage, and subscription placement constraints before proposing hierarchy moves.
+- Validate naming and tagging standards against Microsoft Learn guidance and existing policy enforcement.
+- Label hierarchy inventory as sampled current-state evidence; documentation alone does not prove the estate is organized correctly.
+
+## Safe verification targets
+
+- Management group purpose and inherited controls are documented.
+- Subscription placement matches workload/environment/platform boundary.
+- Resource groups contain resources with shared lifecycle and ownership.
+- Policy, RBAC, budget, tag, naming, and quota implications are known.
+- Subscription moves or hierarchy changes have validation and rollback/communication plan.
+
+## When to push back
+
+- The user wants one subscription or flat hierarchy for convenience.
+- A resource group is used to isolate production from non-production without policy/RBAC proof.
+- The proposed move ignores inherited deny policies or RBAC.
+- Ownership and cost accountability are undefined.

package/skills/azure/azure-subscription-resource-organization/references/workflow-and-output.md

@@ -1,95 +1,41 @@
-# Workflow and Output Contract
+# Workflow and output contract
 
-## Safe Workflow
+Use this reference for full execution of `azure-subscription-resource-organization`.
 
-1. **Classify the estate**
-   - greenfield or brownfield,
-   - single subscription or multi-subscription,
-   - centralized platform model or team-local sprawl,
-   - regulated or lightly governed.
-2. **Identify the real boundary decision**
-   - management group,
-   - subscription,
-   - resource group,
-   - or no new boundary because the existing one is already correct.
-3. **Map ownership before structure**
-   - platform team,
-   - security/governance team,
-   - networking/shared-services team,
-   - workload or application teams,
-   - billing/FinOps accountability.
-4. **Test hierarchy intent**
-   - inheritance target for policy and RBAC,
-   - separation needed for compliance, residency, or operational autonomy,
-   - subscription democratization needs,
-   - shared-services placement,
-   - exception-handling model.
-5. **Stress subscription placement**
-   - platform landing zones versus application landing zones,
-   - shared connectivity, identity, management, and security services,
-   - blast radius of putting unrelated workloads together,
-   - cost and quota implications,
-   - lifecycle mismatch across teams.
-6. **Stress resource-group usage**
-   - lifecycle affinity,
-   - access boundary assumptions,
-   - whether the team is trying to use resource groups to solve a subscription or governance problem they cannot safely solve.
-7. **Return a go/no-go structure verdict**
-   - what should stay,
-   - what should move,
-   - what should not be split yet,
-   - and which governance or operations dependencies block the reorganization.
+## Workflow
 
-## Role-Specific Stress Checks
+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.
 
-- Reject “one big subscription is simpler” when multiple teams, environments, workloads, or control boundaries clearly differ.
-- Reject “just mirror the org chart” as a management-group strategy. Organizational charts change faster than good governance boundaries.
-- Reject designs that use resource groups as fake tenancy, fake billing isolation, or fake compliance boundaries.
-- Challenge any platform model that mixes shared connectivity, identity, monitoring, or security controls into arbitrary workload subscriptions without a reason.
-- Call out when management-group placement creates policy or RBAC inheritance that the operating model cannot actually support.
-- Challenge subscription splits that create excessive operational friction without a real governance, ownership, quota, or blast-radius benefit.
-- Force explicit ownership for platform subscriptions; if nobody owns them, the design is incomplete.
+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.
 
-## Output Template
+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.
 
-```markdown
-# Azure Resource Organization Review: <scope>
+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.
 
-## Verdict
-- Status: READY / READY WITH RISKS / NOT READY
-- Primary boundary decision:
-- Biggest organizational risk:
-- Evidence level: live evidence / documentation-based / user-provided sanitized evidence / inference
+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.
 
-## Current or proposed structure
-- Tenant/platform context:
-- Management-group shape:
-- Subscription model:
-- Resource-group pattern:
-- Platform owners:
-- Workload owners:
+## Output contract
 
-## Findings
-| Area | Finding | Severity | Evidence | Recommendation | Owner |
-|---|---|---|---|---|---|
+Return:
 
-## Boundary decisions
-| Decision | Best boundary | Why | Governance impact | Operations impact |
-|---|---|---|---|---|
-
-## Safe next actions
-1.
-2.
-3.
-
-## Assumptions and unknowns
--
-```
-
-## Red Flags
-
-- The request asks for management-group hierarchy advice without naming who owns governance, policy, or shared services.
-- The design assumes resource groups provide the same isolation as subscriptions.
-- The proposed split or consolidation ignores policy inheritance, quota boundaries, or billing accountability.
-- The answer claims confidence about the current hierarchy without live evidence or sanitized user proof.
-- The plan moves subscriptions for “tidiness” without a governance, operations, security, or ownership reason.
+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-cost-optimization-review/SKILL.md

@@ -3,97 +3,41 @@ name: azure-waf-cost-optimization-review
 description: "Review Azure workload cost posture against the Well-Architected Framework Cost Optimization pillar: cost modeling, rightsizing, reservations, hybrid benefit, storage lifecycle, and idle resource elimination."
 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: finops
 ---
 
-# Azure WAF Cost Optimization Review
+# Azure WAF Cost Optimization
 
-The Azure Well-Architected Framework Cost Optimization pillar focuses on designing workloads that maximize the value delivered while minimizing unnecessary Azure spending.
+## Purpose
 
-## 5 Cost Optimization Design Principles
+Act as a ruthless Azure reviewer for azure waf cost optimization work. Stop broad, vague, or unverified recommendations before they become production risk.
 
-1. **Develop a cost model** — model costs before deployment; estimate spend based on requirements; track cost KPIs
-2. **Design with a cost-efficiency mindset** — favor managed services, consumption-based pricing, and right-sized resources
-3. **Design for usage optimization** — enable auto-scaling; schedule workloads; use spot/low-priority VMs for fault-tolerant jobs
-4. **Design for rate optimization** — commit to consistent usage via Azure Reservations and Savings Plans; leverage hybrid benefits
-5. **Monitor and optimize over time** — track spend continuously; act on cost recommendations; retire underutilized resources
+## Lean operating rules
 
-## Azure Cost Tools
+- 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.
 
-- **Microsoft Cost Management + Billing** — cost analysis, budgets, cost alerts, export to storage for Parquet/Athena analysis
-- **Azure Advisor** — cost recommendations: resize/shutdown VMs, buy reservations, delete unused disks
-- **Azure Monitor + cost alerts** — alert on budget thresholds
-- **Azure Pricing Calculator** — pre-deployment cost estimation
-- **Azure Cost Management Exports** — raw billing data to Azure Storage for Power BI / Excel analysis
-- **Azure Carbon Optimization** (preview) — sustainability tracking for carbon footprint reporting
+## References
 
-## Cost Optimization Areas
+Load these only when needed:
 
-### Compute
-- Right-size VMs using Azure Advisor; use Burstable VMs (B-series) for dev/test
-- Spot VMs — up to 90% off list price for interruptible workloads (CI/CD, ML training, batch)
-- Azure Batch Spot nodes — bursty HPC at spot pricing
-- Auto-shutdown dev VMs outside business hours via Azure DevTest Labs or scheduled stop
+- [Azure WAF Cost Optimization Operations](references/waf-cost-optimization-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.
 
-### Reservations and Savings Plans
-- **1yr/3yr Azure Reservations** — VMs, SQL, Cosmos DB, App Service, AKS nodes; committed capacity discount
-- **Azure Savings Plans for Compute** — covers VMs, VMSS, AKS, App Service, Functions across regions, SKU families, and sizes; no instance flexibility restrictions
+## Response minimum
 
-### Azure Hybrid Benefit
-- **Windows Server** — up to 40% off VM pricing using existing Software Assurance licenses
-- **SQL Server** — up to 55% off Azure SQL Database and SQL Managed Instance
-- **Dev/Test pricing** — reduced rates for Visual Studio subscribers on eligible services
+Return, at minimum:
 
-### Storage
-- **Azure Blob lifecycle management** — tiered transition: Hot → Cool → Cold → Archive based on last access time
-- **Storage Reserved Capacity** — commit to blob storage capacity for up to 3 years
-- LRS vs GRS vs GZRS selection — match redundancy to actual DR requirements; avoid over-replication
-
-### Networking
-- Azure Front Door vs Application Gateway vs Load Balancer cost tradeoffs
-- ExpressRoute vs VPN Gateway pricing model differences
-- Egress data transfer costs — VNet peering is free; egress to internet is billed per GB
-
-### Governance
-- Management Group + Subscription tagging policy — enforce required tags via Azure Policy deny
-- Cost allocation tags — chargeback/showback reporting by team, application, environment, cost-center
-- Azure Policy to enforce allowed VM SKUs — prevent accidental high-cost SKU deployment
-
-## Assessment Questions
-
-- How do you model and predict cloud costs for your workload?
-- How do you ensure resources are correctly sized for the workload?
-- How do you use Azure pricing models (reservations, savings plans, spot) to reduce costs?
-- How do you monitor and act on cost anomalies?
-- How do you retire unused or underutilized resources?
-- How do you allocate costs to teams or business units?
-- How do you evaluate the cost impact of architectural decisions?
-
-## Validation Checklist
-
-- [ ] Azure Cost Management budgets configured per subscription with email alerts at 80% and 100%
-- [ ] 100% of resources tagged with required tags (env, team, app, cost-center) via Azure Policy
-- [ ] Azure Advisor cost recommendations reviewed and actioned monthly
-- [ ] Azure Reservations or Savings Plans covering ≥70% of steady-state compute (VMs, AKS nodes, SQL)
-- [ ] Azure Hybrid Benefit enabled for eligible Windows Server and SQL Server workloads
-- [ ] Spot VMs or Azure Batch Spot nodes used for CI/CD, ML training, and dev/test workloads
-- [ ] Blob Storage lifecycle policies active for all storage accounts with data older than 30 days
-- [ ] Unused resources identified and decommissioned monthly: unattached disks, unused public IPs, empty resource groups, stopped VMs >7 days
-- [ ] Dev/test VMs auto-shutdown scheduled outside business hours
-- [ ] Cost allocation report generated monthly for chargeback/showback
-
-## Response Shape
-
-Cost visibility and tooling assessment → tagging compliance → reservation/savings plan coverage → rightsizing opportunities → hybrid benefit and spot adoption → storage lifecycle → idle resource inventory → prioritized savings actions
-
-## Official Documentation
-
-- https://learn.microsoft.com/azure/well-architected/cost-optimization/
-- https://learn.microsoft.com/azure/cost-management-billing/
-
-## Security Notes
-
-Read-only advisory. Do not cancel Reservations, delete resources, or modify billing configurations without explicit approval and resource inventory confirmation.
+- 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-cost-optimization-review/metadata.json

@@ -3,16 +3,28 @@
   "name": "Azure WAF Cost Optimization Review",
   "type": "skill",
   "provider": "azure",
-  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
-  "summary": "Review Azure workload cost posture against the Well-Architected Framework Cost Optimization pillar: cost modeling, rightsizing, reservations, hybrid benefit, storage lifecycle, and idle resource elimination.",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Azure workload cost posture against the Well-Architected Framework Cost Optimization pillar: cost model, budgets, cost drivers, usage optimization, rate optimization, Advisor recommendations, reservations, savings plans, hybrid benefit, and idle resource elimination.",
   "source_type": "original",
   "official_docs": [
     "https://learn.microsoft.com/azure/well-architected/cost-optimization/",
-    "https://learn.microsoft.com/azure/cost-management-billing/"
+    "https://learn.microsoft.com/azure/well-architected/cost-optimization/principles",
+    "https://learn.microsoft.com/azure/well-architected/cost-optimization/cost-model",
+    "https://learn.microsoft.com/azure/well-architected/cost-optimization/get-best-rates",
+    "https://learn.microsoft.com/azure/cost-management-billing/costs/overview-cost-management",
+    "https://learn.microsoft.com/azure/advisor/advisor-workbook-cost-optimization",
+    "https://learn.microsoft.com/azure/advisor/advisor-how-to-calculate-total-cost-savings"
   ],
-  "security_notes": "Read-only advisory. Do not cancel Reservations, delete resources, or modify billing configurations without explicit approval and resource inventory confirmation.",
-  "last_verified": "2026-05-09",
+  "security_notes": "Read-only advisory by default. Do not delete resources, cancel commitments, modify billing configuration, buy reservations or savings plans, or alter budgets without explicit approval, owner confirmation, and current inventory evidence.",
+  "last_verified": "2026-06-05",
   "path": "skills/azure/azure-waf-cost-optimization-review",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.2"
 }

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

@@ -0,0 +1,21 @@
+# MCP and evidence path
+
+Use this reference when deciding how to ground `azure-waf-cost-optimization-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-cost-optimization-review/references/official-sources.md

@@ -0,0 +1,24 @@
+# Official sources
+
+Use this reference when grounding current Azure behavior for `azure-waf-cost-optimization-review`.
+
+## Microsoft Learn sources
+
+- https://learn.microsoft.com/azure/well-architected/cost-optimization/principles
+- https://learn.microsoft.com/azure/well-architected/cost-optimization/cost-model
+- https://learn.microsoft.com/azure/well-architected/cost-optimization/get-best-rates
+- https://learn.microsoft.com/azure/cost-management-billing/costs/overview-cost-management
+- https://learn.microsoft.com/azure/advisor/advisor-workbook-cost-optimization
+- https://learn.microsoft.com/azure/advisor/advisor-how-to-calculate-total-cost-savings
+- https://learn.microsoft.com/azure/well-architected/cost-optimization/checklist
+- https://learn.microsoft.com/azure/cost-management-billing/costs/tutorial-acm-opt-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.
+
+## 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-cost-optimization-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-cost-optimization-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-cost-optimization-review/references/waf-cost-optimization-operations.md

@@ -0,0 +1,69 @@
+# Azure WAF Cost Optimization 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
+
+- Starting with reservations or savings plans before rightsizing and shutdown analysis.
+- Treating Advisor savings as guaranteed savings.
+- Ignoring reliability, security, observability, backup, and data-transfer costs in the cost model.
+- Deleting idle-looking resources without owner and dependency confirmation.
+- Optimizing unit price while breaking SLOs or compliance requirements.
+
+## Officially grounded service shape
+
+- Microsoft Learn evidence says a cost model estimates initial cost, run rates, and ongoing costs; it is foundational for forecasting and budget planning.
+- Cost modeling must account for workload components, requirements, supporting services, billing model, licensing, reliability costs, operational costs, business metrics, budgets, forecasts, and model maintenance.
+- Microsoft Cost Management, Azure Advisor, reservations, savings plans, Azure Hybrid Benefit, budgets, forecasts, pricing calculator, and tag inheritance are Azure facilitation mechanisms.
+- Advisor recommendations should be sequenced: rightsizing/shutdown first, then reservations, then savings plans; forecasted savings can vary and are not guaranteed.
+
+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
+
+- Build or validate the cost model before optimization claims.
+- Separate usage optimization from rate optimization.
+- Confirm owner, dependency, and business criticality before deleting or shutting down resources.
+- Rightsize and remove waste before buying commitments.
+- Label savings as forecast, estimate, or sampled evidence, not guaranteed outcome.
+
+## Minimal safe implementation flow
+
+- Scope workload, business metric, billing boundary, time window, environments, and optimization goal.
+- Collect cost model, budgets, Advisor recommendations, utilization, tags, commitments, licensing, and owner evidence.
+- Classify opportunities by idle waste, rightsizing, storage lifecycle, data transfer, reservations, savings plans, hybrid benefit, and architecture tradeoffs.
+- Prioritize reversible changes and quantify forecast confidence.
+- Return savings candidates, risk, approval requirements, verification checks, and follow-up measurements.
+
+## High-risk assumptions to kill
+
+- Lowest cost is the goal; Well-Architected cost optimization requires business-aligned tradeoffs, not reckless cheapness.
+- Advisor savings are bankable; Microsoft positions them as recommendations and forecast opportunities, not guaranteed outcomes.
+- Reservations or savings plans fix waste; commitments can lock in bad sizing if rightsizing and shutdown analysis happen later.
+- Idle-looking resources are safe to delete; owner, dependency, recovery, compliance, and business-calendar evidence must come first.
+- Cost reports prove optimization; they need utilization, commitment, tagging, and workload-criticality context.
+
+## Safe command/code verification targets
+
+- Pull read-only Cost Management, budget, Advisor, tag, and utilization evidence for the scoped workload and time window.
+- Separate usage cleanup candidates from rate optimization candidates before proposing commitments.
+- Validate each deletion, shutdown, SKU change, or scaling change against owner confirmation, dependency mapping, and rollback.
+- Check whether reliability, security, backup, logging, data transfer, and support costs are included in the cost model.
+- Label savings as estimate, forecast, sampled evidence, or unverified; never call them guaranteed.
+
+## Safe verification targets
+
+- Cost model includes direct, supporting, reliability, operational, licensing, and data transfer costs.
+- Budgets and alerts exist for the workload boundary.
+- Advisor or sampled utilization evidence supports rightsizing/shutdown candidates.
+- Reservations/savings plans are considered only after usage cleanup.
+- Owners approve any resource deletion, commitment purchase, or billing change.
+
+## When to push back
+
+- The user wants to delete resources based only on cost list output.
+- Savings are presented as guaranteed without usage and rate evidence.
+- A commitment purchase is proposed before rightsizing.
+- Cost reduction would violate reliability, security, or compliance requirements.