@raishin/vanguard-frontier-agentic 2.8.0 → 2.10.0

package/skills/azure/azure-cosmosdb-platform-operator/references/cosmosdb-platform-operations.md

@@ -0,0 +1,62 @@
+# Cosmos DB platform operations
+
+## What people get wrong
+
+- They treat account-level multi-region settings as proof the application fails over safely.
+- They ignore SDK preferred-region configuration, private DNS, and remaining-region throughput when reviewing regional resiliency.
+- They change consistency, failover priority, or throughput during stress without knowing the blast radius.
+- They view backup as an availability feature instead of a data-recovery feature.
+- They approve partitioning from a diagram instead of measured access patterns and distribution.
+
+## Officially grounded service shape
+
+Microsoft Learn describes Cosmos DB as an account containing databases and containers, with containers as logical units of distribution and scalability. Reliability features include zone redundancy, multi-region replication, several consistency levels, service-managed or customer-managed failover, SDK resiliency behavior, and continuous or periodic backup. The reliability guide also warns against control-plane changes on affected regions during outage scenarios and calls out private endpoint DNS considerations after failover.
+
+## Non-negotiable design rules
+
+1. Identify API type, write model, regions, consistency, backup, and throughput mode before giving a platform verdict.
+2. Treat partitioning and throughput as workload-coupled, not platform-only decisions.
+3. Verify SDK region preference and retry behavior for multi-region availability.
+4. For private endpoints, design regional endpoints and DNS resolution deliberately.
+5. Size remaining regions for failover load before claiming regional resilience.
+6. Use backup/restore for data corruption/deletion scenarios; use multi-region and failover for availability scenarios.
+7. Require diagnostics, Resource Health, Service Health, alerts, and DR runbooks.
+
+## Minimal safe implementation flow
+
+1. Inventory account topology: API, regions, write model, consistency, backup, throughput, network access, and private endpoints.
+2. Review workload shape: partition key, hot partition risk, RU headroom, critical operations, and consistency needs.
+3. Review reliability: zone redundancy, failover mode, preferred regions, capacity under region loss, and DR drills.
+4. Review network: private endpoints, DNS zones, hub/spoke forwarding, firewall, and client routing.
+5. Review operations: metrics, logs, alerts, backup restore testing, and owner/runbook evidence.
+6. Rank blockers and reversible remediations.
+7. Require explicit approval before any control-plane mutation.
+
+## High-risk assumptions to kill
+
+- Multi-region account configuration does not prove application failover unless SDK preferred regions, retries, conflict handling, and remaining-region capacity are verified.
+- Private endpoints can break regional resilience if DNS zones, VNet links, forwarding, and local regional endpoint paths are not designed deliberately.
+- Strong, bounded staleness, session, and eventual consistency have different availability, RPO, and throughput implications; do not treat consistency as a cosmetic setting.
+- Control-plane changes during an affected-region outage can delay recovery; do not mutate write region, consistency, throughput, networking, or failover priorities casually.
+- Backup protects data recovery scenarios; it is not a substitute for live availability, failover routing, or tested application DR.
+
+## Safe command/code verification targets
+
+- Inspect IaC for account regions, zone redundancy, failover priorities, write-region model, consistency, backup mode, throughput mode, and private endpoint resources.
+- Review application configuration for SDK preferred regions, excluded regions, retry diagnostics, conflict resolution, and multi-write support where applicable.
+- Check network templates for one-region-per-DNS-zone patterns, private DNS links, forwarding rules, firewall dependencies, and client resolution paths.
+- Verify monitoring code or dashboards cover normalized RU, 429s, region availability, Resource Health, Service Health, backup status, and restore-test evidence.
+- Confirm every proposed account mutation has an approval gate, rollback plan, and explicit outage-state caveat.
+
+## Safe verification targets
+
+- Account regions, write region or multi-write state, failover priorities, and service-managed/forced failover process.
+- Consistency level and documented RPO/availability implications.
+- Throughput mode and normalized RU headroom by partition key range.
+- Private endpoint count, DNS zones, VNet links, forwarding, and client resolution path.
+- Backup mode, retention, restore test, and data-corruption response plan.
+- SDK preferred regions, retry, partition-level circuit breaker or equivalent availability settings.
+
+## When to push back
+
+Push back on production signoff without failover evidence, private endpoint DNS proof, capacity-under-failure math, SDK routing proof, backup restore tests, or partition distribution evidence.

package/skills/azure/azure-cosmosdb-platform-operator/references/mcp-and-evidence.md

@@ -1,31 +1,27 @@
-# MCP and evidence path
+# MCP and evidence path for Cosmos DB platform operations
 
-Use this reference only when you need to decide how to gather evidence.
+Use Microsoft Learn documentation through the user's configured documentation MCP as the first grounding path for Azure service behavior. This file defines evidence boundaries; it must not imply that documentation proves the user's tenant, subscriptions, RBAC, quotas, billing agreement, deployed resources, or production readiness.
 
-## Live-first evidence rule
+## Evidence ladder
 
-1. Prefer live Azure MCP capability evidence when the active client exposes Azure tools.
-2. Treat the runtime-exposed tool inventory as truth.
-3. If Cosmos DB tooling is not exposed live, say so and switch to documentation-based guidance instead of pretending the namespace exists.
+1. `docs_only`: Microsoft Learn documentation and official architecture guidance. Use for documented behavior, caveats, and safe review criteria.
+2. `sampled_read_only`: configured-environment evidence from read-only tools, if available and explicitly scoped. Use only for the sampled resource/time window.
+3. `user_supplied`: sanitized outputs, IaC, diagrams, billing summaries, or metrics provided by the user. Treat as unverified unless independently checked.
+4. `mutation_ready`: documentation plus current-state evidence plus explicit approval, blast-radius statement, and rollback path.
 
-## Azure MCP grounding
+## Rules
 
-Based on Microsoft documentation:
+- Do not expose environment-specific implementation details in committed docs or user-facing guidance.
+- Do not ask for credentials, tokens, tenant identifiers, subscription identifiers, billing account identifiers, connection strings, private keys, customer data, or raw secrets.
+- If current-state evidence was not sampled, say `not sampled`; do not imply it.
+- If evidence is representative or partial, say so. A sample does not prove broad regional availability, billing accuracy, policy compliance, or production readiness.
+- Prefer read-only evidence before mutation planning. Stop for approval before write operations.
 
-- Azure MCP supports a documented `cosmos` namespace in namespace mode.
-- Microsoft recommends **consolidated mode** for AI agents because it reduces tool count and improves usability.
-- Namespace filtering means a client may expose only a subset of Azure tools.
+## Final-answer evidence language
 
-Implication:
+Use phrases like:
 
-- Do not assume that `cosmos` is available in the current runtime just because Microsoft documents it.
-- If live MCP discovery is unclear, inspect or ask for the available Azure tool inventory before making namespace-specific claims.
-
-## Evidence hierarchy
-
-Use this order:
-
-1. **live evidence** — Azure MCP output, sanitized screenshots, sanitized metrics, sanitized query results, or user-provided config excerpts
-2. **user-provided sanitized evidence** — redacted portal output, SDK code, IaC snippets, logs, or query text
-3. **documentation-based** — Microsoft Learn and official Azure MCP documentation
-4. **inference** — conclusions derived from patterns but not directly proven by evidence
+- "Based on Microsoft Learn documentation..."
+- "Configured-environment evidence was not sampled in this review."
+- "The following is an inference from the provided configuration, not proven live state."
+- "This recommendation is mutation-ready only after explicit approval and rollback review."

package/skills/azure/azure-cosmosdb-platform-operator/references/official-sources.md

@@ -1,34 +1,23 @@
-# Official sources
+# Official sources for Azure Cosmos DB Platform Operator
 
-Use this reference only when you need the detailed source list or need to ground a specific claim.
+Use Microsoft Learn documentation through the user's configured documentation MCP before making Cosmos DB platform claims. Documentation proves documented service behavior; it does not prove the user's account configuration, regions, throughput, private DNS, backups, or workload readiness.
 
-## Azure MCP
+## Primary Microsoft Learn sources
 
-- Azure MCP overview
-  https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/overview
-- Azure MCP concepts
-  https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/concepts
-- Azure MCP tools overview
-  https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/
+| Source | Review implication |
+| --- | --- |
+| [Reliability in Azure Cosmos DB](https://learn.microsoft.com/en-us/azure/reliability/reliability-cosmos-db) | Ground zone redundancy, multi-region, failover, backup, SDK resiliency, RPO, and control-plane outage caveats. |
+| [Architecture best practices for Azure Cosmos DB](https://learn.microsoft.com/en-us/azure/well-architected/service-guides/cosmos-db) | Use for Well-Architected reliability, security, cost, operational excellence, and performance tradeoffs. |
+| [Partitioning and horizontal scaling](https://learn.microsoft.com/en-us/azure/cosmos-db/partitioning) | Use for partition-key, logical partition, physical partition, and scale-risk review. |
+| [Hierarchical partition keys](https://learn.microsoft.com/en-us/azure/cosmos-db/hierarchical-partition-keys) | Use when tenant/user/item or similar hierarchy is proposed; verify workload fit and limits. |
+| [Consistency levels](https://learn.microsoft.com/en-us/azure/cosmos-db/consistency-levels) | Use for availability, latency, throughput, and correctness tradeoffs. |
+| [Request Units](https://learn.microsoft.com/en-us/azure/cosmos-db/request-units) | Use for provisioned throughput, multi-region throughput, and consistency effects. |
+| [Failover considerations for private endpoints](https://learn.microsoft.com/en-us/azure/cosmos-db/failover-considerations-for-private-endpoints) | Use for regional private endpoint, private DNS, and failover routing checks. |
+| [Online backup and restore](https://learn.microsoft.com/en-us/azure/cosmos-db/online-backup-and-restore) | Use to distinguish data corruption recovery from availability features. |
 
-## Azure Cosmos DB
+## Source-grounding rules
 
-- Partitioning and horizontal scaling in Azure Cosmos DB
-  https://learn.microsoft.com/en-us/azure/cosmos-db/partitioning
-- Data modeling in Azure Cosmos DB for NoSQL
-  https://learn.microsoft.com/en-us/azure/cosmos-db/modeling-data
-- Consistency levels in Azure Cosmos DB
-  https://learn.microsoft.com/en-us/azure/cosmos-db/consistency-levels
-- Manage consistency levels in Azure Cosmos DB
-  https://learn.microsoft.com/en-us/azure/cosmos-db/how-to-manage-consistency
-- Tuning query performance with Azure Cosmos DB
-  https://learn.microsoft.com/en-us/azure/cosmos-db/query-metrics
-- Architecture best practices for Azure Cosmos DB for NoSQL
-  https://learn.microsoft.com/en-us/azure/well-architected/service-guides/cosmos-db
-- Hierarchical partition keys
-  https://learn.microsoft.com/en-us/azure/cosmos-db/hierarchical-partition-keys
-
-## Grounded insights used by this skill
-
-- Do not trust generic NoSQL advice unless it matches Azure Cosmos DB partitioning and consistency behavior.
-- Runtime-exposed Azure MCP tools are truth; documentation does not prove current client exposure.
+- Do not approve multi-region readiness without SDK region preference, failover mode, capacity, private DNS, and DR drill evidence.
+- Do not approve consistency changes without application correctness and throughput impact review.
+- Do not approve partition or throughput changes from docs alone; require workload evidence.
+- Treat preview features and failover modes as explicit caveats, not default recommendations.

package/skills/azure/azure-cosmosdb-platform-operator/references/safety-checklist.md

@@ -0,0 +1,33 @@
+# Safety checklist for Azure Cosmos DB Platform Operator
+
+## Non-negotiable gates
+
+- Never ask for account keys, connection strings, full documents, customer data, tenant identifiers, subscription identifiers, or database dumps.
+- Do not approve production posture without evidence for regions, consistency, throughput mode, partitioning, backups, private networking, alerts, and failover drills.
+- Do not perform or recommend account control-plane changes during an affected-region outage unless Microsoft guidance explicitly supports the action.
+- Require explicit approval before changing consistency, regions, failover priority, multi-write, throughput, indexing, backup policy, private endpoints, firewall, or network settings.
+- Treat SDK configuration as part of platform reliability; account settings alone do not prove application failover.
+
+## High-risk assumptions to kill
+
+- "Multi-region means no downtime." SDK routing, capacity in remaining regions, consistency, and app failover still matter.
+- "Service-managed failover is fast enough." Microsoft Learn notes it can take significant time; forced failover may be needed for faster write recovery.
+- "Private endpoint works after failover automatically." Regional private endpoints and DNS forwarding need explicit design.
+- "Strong consistency is always safest." It changes availability and throughput tradeoffs.
+- "Backups are the DR plan." Backups protect against corruption/deletion; they are not a substitute for availability architecture.
+
+## Evidence labels
+
+- `docs_only`: Microsoft Learn guidance only.
+- `sampled_read_only`: account, metric, or network evidence was sampled safely.
+- `config_review`: IaC or sanitized account configuration was reviewed but not proven live.
+- `dr_drill_proven`: failover or restore behavior was tested and evidence exists.
+- `mutation_ready`: blast radius, approval, and rollback are documented.
+
+## Minimum safe evidence
+
+- API type, account tier, regions, write model, failover mode, consistency, and backup policy.
+- Throughput mode, hot partition indicators, RU headroom, and capacity during region loss.
+- Partition key strategy and hierarchical partition key fit if used.
+- Private endpoint layout, private DNS zones, hub/spoke forwarding, and application regional routing.
+- Resource Health, Service Health, metrics, diagnostic logs, alerts, and DR runbook ownership.

package/skills/azure/azure-cosmosdb-platform-operator/references/workflow-and-output.md

@@ -1,37 +1,39 @@
-# Workflow and output contract
+# Workflow and output contract for Azure Cosmos DB Platform Operator
 
-Use this reference only when you are performing the full review or implementation-guidance pass.
+## Minimal safe workflow
 
-## Workflow
+1. Classify the request: readiness review, region/failover design, throughput review, consistency review, partition review, network review, or mutation approval.
+2. Ground the answer in Microsoft Learn through the user's configured documentation MCP.
+3. Identify account scope without exposing sensitive identifiers: API, regions, write model, consistency, throughput, backup, and network posture.
+4. Separate documentation evidence from sampled read-only evidence, config review, and inference.
+5. Stress test: partitioning, RU headroom, failover behavior, SDK region routing, private DNS, backups, diagnostics, and operational ownership.
+6. Produce a verdict with blockers, safe next actions, and open questions.
+7. For mutations, stop for explicit approval after blast-radius and rollback review.
 
-1. **Scope the target**
-   - Confirm API/workload if known: NoSQL, Mongo, Cassandra, Gremlin, Table, or unknown.
-   - Confirm whether the user needs this role specifically, not an adjacent Azure role.
-   - Confirm whether the question is about an existing workload or a new design.
+## Output contract
 
-2. **Establish evidence level**
-   - Use live Azure MCP evidence when available.
-   - Otherwise use official docs plus sanitized user evidence.
-   - Explicitly label unknowns.
+```markdown
+## Verdict
+<go | conditional-go | no-go | docs-only advisory>
 
-3. **Stress checks**
-   - Check account, region, API surface, and whether the question is about an existing workload or a new design.
-   - Stress-test partition-key choice, logical-partition growth, hot-partition risk, and query alignment.
-   - Check throughput model, RU consumption, throttling behavior, indexing posture, and multi-region tradeoffs.
-   - Call out adjacent roles when the dominant problem is RBAC, networking, observability, or cost governance.
+## Evidence level
+- Documentation: <sources used>
+- Current-state evidence: <sampled_read_only | config_review | not sampled>
 
-4. **Check adjacent roles the user may be missing**
-   - **Azure RBAC Review** when the real issue is overbroad account or data-plane access.
-   - **Azure Network Topology Review** when private endpoints, DNS, routing, or egress control dominate the problem.
-   - **Azure Observability Investigator** when the question becomes metrics, alerts, logs, or telemetry gaps.
-   - **Azure Cost Optimization Governor** when the issue is sustained RU waste or poor autoscale governance.
+## Findings
+1. <finding> — Evidence: <docs_only|sampled_read_only|config_review|inference>
 
-## Output contract
+## Reliability and recovery posture
+- Regions/failover: <known/gap>
+- Backup/restore: <known/gap>
+
+## Blockers
+- <production blocker>
+
+## Safe next actions
+- <least-risk action>
+```
 
-Use this structure:
+## Pushback triggers
 
-1. **Verdict**
-2. **Evidence level**
-3. **Key findings**
-4. **Safest next actions**
-5. **Open questions**
+Push back on region changes during outages, untested failover claims, private endpoint DNS hand-waving, consistency changes with no correctness rationale, or throughput changes that ignore partition and workload evidence.

package/skills/azure/azure-cost-estimation-review/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: azure-cost-estimation-review
-description: Review Azure cost estimates, pricing calculator assumptions, SKU and region choices, environment sizing realism, and uncertainty handling using official Microsoft cost-management and Azure MCP pricing documentation only.
+description: Review Azure cost estimates, pricing calculator assumptions, SKU and region choices, environment sizing realism, and uncertainty handling using official Microsoft cost-management and pricing documentation only.
 allowed-tools: Read Grep Glob
 metadata:
   author: github: Raishin
-  version: 0.1.0
-  updated: "2026-05-05"
+  version: 0.1.3
+  updated: "2026-06-05"
   category: finops
 ---
 
@@ -16,10 +16,10 @@ metadata:
 Act as a ruthless Azure cost estimation reviewer. Your job is to stop fake precision, weak sizing assumptions, region/SKU guesswork, and production-budget fantasies before they turn into a bad Azure bill or a misleading business case.
 
 Default access posture:
-- Prefer detected official Azure MCP pricing capabilities when available.
+- Prefer Microsoft Learn documentation through the user's configured documentation MCP; use sampled pricing evidence only when the active client exposes a relevant read-only path.
 - Otherwise work from official Microsoft documentation and user-provided sanitized assumptions.
 - Never ask the user to paste secrets, negotiated price sheets, private contracts, raw billing exports, credentials, tokens, or customer-identifying billing data into chat.
-- Do not hard-code MCP server names, subscriptions, billing accounts, management groups, regions, SKUs, currencies, or environment names.
+- Do not hard-code environment-specific identifiers, billing scopes, regions, SKUs, currencies, or environment names.
 
 ## Trigger Situations
 
@@ -34,7 +34,7 @@ Use this skill when the user asks to:
 
 ## Lean operating rules
 
-- Prefer live Azure or Microsoft evidence first when the active client exposes it; otherwise fall back to official documentation and sanitized user evidence.
+- Prefer Microsoft Learn documentation through the user's configured documentation MCP, then sampled read-only Azure evidence when the active client exposes it, then sanitized user evidence.
 - Separate confirmed facts from inference. If state was not queried or shown, say so.
 - Challenge broad access, broad scope, destructive changes, and hand-wavy production claims.
 - Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
@@ -43,7 +43,9 @@ Use this skill when the user asks to:
 
 Load these only when needed:
 
-- [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing live Azure evidence, confirming Microsoft MCP capability, or switching to documentation mode.
+- [Operations guide](references/cost-estimation-review.md) — use for service-specific pitfalls, design rules, verification targets, and pushback criteria.
+- [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing documentation-based evidence, sampled read-only Azure evidence, or sanitized user evidence.
+- [Safety checklist](references/safety-checklist.md) — use for evidence labels, risk gates, mutation boundaries, approval rules, credential boundaries, and current-state caveats.
 - [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, applying stress checks, or formatting the final answer.
 - [Official sources](references/official-sources.md) — use when you need the detailed Microsoft documentation list or source notes.
 

package/skills/azure/azure-cost-estimation-review/metadata.json

@@ -19,12 +19,14 @@
     "https://learn.microsoft.com/en-us/azure/cost-management-billing/",
     "https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/governance",
     "https://learn.microsoft.com/en-us/azure/cost-management-billing/savings-plan/manage-savings-plan",
-    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/",
-    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/azure-pricing"
+    "https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/overview-cost-management",
+    "https://learn.microsoft.com/en-us/azure/cost-management-billing/manage/cost-management-automation-scenarios",
+    "https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/cost-mgt-best-practices",
+    "https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/plan/estimate-total-cost-of-ownership"
   ],
-  "security_notes": "Do not present calculator output as invoice truth, do not hide missing sizing assumptions, and do not imply unsupported Azure MCP pricing or billing capabilities. Treat negotiated pricing, discount posture, and future utilization as explicit uncertainty unless verified.",
-  "last_verified": "2026-04-27",
+  "security_notes": "Do not present calculator output as invoice truth, do not hide missing sizing assumptions, and do not imply unsupported configured Azure evidence pricing or billing capabilities. Treat negotiated pricing, discount posture, and future utilization as explicit uncertainty unless verified.",
+  "last_verified": "2026-06-05",
   "path": "skills/azure/azure-cost-estimation-review",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.3"
 }

package/skills/azure/azure-cost-estimation-review/references/cost-estimation-review.md

@@ -0,0 +1,62 @@
+# Azure cost estimation review
+
+## What people get wrong
+
+- They treat the Azure pricing calculator as an invoice simulator. It is an estimation tool driven by selected configuration and usage quantities.
+- They forget support plans, backups, monitoring data, private endpoints, NAT, egress, DR capacity, and nonproduction environments.
+- They use 730-hour defaults for workloads that scale, sleep, burst, or run seasonally.
+- They apply reservations or savings plans before proving stable utilization.
+- They ignore negotiated pricing and agreement-specific data sources while presenting retail math as exact.
+
+## Officially grounded service shape
+
+Microsoft Learn describes the Azure pricing calculator as a way to turn anticipated usage into an estimated cost. Calculator pricing is sourced from Azure Retail Prices API data, while signed-in experiences can reflect negotiated agreement prices where access allows. Cost Management guidance frames estimation as part of a lifecycle: plan, gain visibility, assign accountability, optimize, and iterate.
+
+## Non-negotiable design rules
+
+1. Build estimates from architecture, not wishful monthly totals.
+2. Label pricing basis: retail, negotiated, historical actual, or unknown.
+3. Include all environments and shared services.
+4. Include data transfer, logs, backups, security, support, and operational overhead where applicable.
+5. Use scenarios: baseline, peak, failover/DR, and growth.
+6. Treat discounts and commitments as conditional until utilization stability is proven.
+7. Preserve uncertainty; do not collapse unknowns into false precision.
+
+## Minimal safe implementation flow
+
+1. Inventory every service, SKU, region, tier, quantity, and usage driver.
+2. Map workload patterns: hours, requests, storage growth, retention, egress, and peak factors.
+3. Add production, nonproduction, DR, shared, and observability cost lines.
+4. Identify pricing source and whether negotiated rates are verified.
+5. Create low/expected/peak scenarios and a separate commitment-discount scenario.
+6. Compare estimate against budget and identify high-cost architectural decisions.
+7. Document unknowns and evidence needed to improve confidence.
+
+## High-risk assumptions to kill
+
+- Calculator output is not invoice truth; it depends on selected configuration, usage quantities, pricing basis, and whether negotiated rates were actually available.
+- A monthly total without architecture bill of materials hides the services most likely to blow the budget: logs, backups, bandwidth, DR, support, and shared networking.
+- Retail pricing is not agreement pricing, and negotiated pricing should not be claimed unless authenticated evidence or sanctioned price sheets support it.
+- Reservation or savings-plan scenarios are not savings unless stable utilization and commitment risk are proven.
+- Nonproduction and failover environments are not free unless shutdown, scaling, retention, and capacity assumptions are explicitly modeled.
+
+## Safe command/code verification targets
+
+- Inspect estimate exports, calculator links, or IaC-derived bill-of-materials for named service configurations, regions, SKUs, quantities, and usage drivers.
+- Check scripts or spreadsheets for hard-coded 730-hour assumptions, missing egress/log/backup/support lines, and unlabeled retail-versus-negotiated pricing.
+- Verify scenarios include low, expected, peak, growth, DR/failover, and commitment-discount variants rather than one fake-precise number.
+- Review any API-backed pricing lookup for currency, region, meter, date, and source labeling.
+- Require estimate notes to list unknowns, owner decisions, and evidence needed before budget approval.
+
+## Safe verification targets
+
+- Calculator export or estimate link with named configurations.
+- SKU, region, and quantity assumptions for each service.
+- Usage drivers: hours, transactions, GB/month, retention, egress, replica count, and backup frequency.
+- Pricing basis and date of rate evidence.
+- Support plan, reservations, savings plans, hybrid benefit, and commitment utilization assumptions.
+- Historical actuals if estimating an existing workload.
+
+## When to push back
+
+Push back on one-line monthly totals, retail rates presented as negotiated rates, missing DR/nonproduction/logging costs, discount claims with no utilization evidence, or estimates with no architecture bill of materials.

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

@@ -1,31 +1,27 @@
-# MCP and Evidence Path
+# MCP and evidence path for Azure cost estimation review
 
-## Official Azure MCP Linkage
+Use Microsoft Learn documentation through the user's configured documentation MCP as the first grounding path for Azure service behavior. This file defines evidence boundaries; it must not imply that documentation proves the user's tenant, subscriptions, RBAC, quotas, billing agreement, deployed resources, or production readiness.
 
-Use official Azure MCP servers as configured in the active runtime. Do not hard-code the server name; users may register the official Azure MCP server under any label. Detect by exposed tool capability and package identity hints, not by fixed server naming.
+## Evidence ladder
 
-Preferred official Azure MCP capability for this role:
+1. `docs_only`: Microsoft Learn documentation and official architecture guidance. Use for documented behavior, caveats, and safe review criteria.
+2. `sampled_read_only`: configured-environment evidence from read-only tools, if available and explicitly scoped. Use only for the sampled resource/time window.
+3. `user_supplied`: sanitized outputs, IaC, diagrams, billing summaries, or metrics provided by the user. Treat as unverified unless independently checked.
+4. `mutation_ready`: documentation plus current-state evidence plus explicit approval, blast-radius statement, and rollback path.
 
-- `pricing` for retail pricing lookups, region/SKU comparisons, and template-backed cost estimation.
+## Rules
 
-Secondary official context:
+- Do not expose environment-specific implementation details in committed docs or user-facing guidance.
+- Do not ask for credentials, tokens, tenant identifiers, subscription identifiers, billing account identifiers, connection strings, private keys, customer data, or raw secrets.
+- If current-state evidence was not sampled, say `not sampled`; do not imply it.
+- If evidence is representative or partial, say so. A sample does not prove broad regional availability, billing accuracy, policy compliance, or production readiness.
+- Prefer read-only evidence before mutation planning. Stop for approval before write operations.
 
-- broader Azure MCP tools inventory only to confirm documented capability existence, not to invent cost-analysis or billing behavior beyond the official docs.
+## Final-answer evidence language
 
-If the expected Azure MCP pricing capability is missing or ambiguous, ask only which configured MCP server exposes the official Azure pricing tools. Do not ask for secrets, contract pricing, subscription dumps, credentials, or tokens.
+Use phrases like:
 
-Do not invent unsupported MCP tools. If a live need exceeds confirmed Azure MCP capability, switch to documentation mode and say so.
-
-## Platform-Agnostic Execution
-
-This skill must work on macOS, Windows, Linux, browser-first clients, and MCP-only clients. Prefer Azure MCP pricing evidence when available. When portal checks, pricing calculator workflows, CLI, PowerShell, Bicep, or ARM examples are useful, show neutral command or workflow shape with `<placeholders>` and adapt only after the user's active platform is known.
-
-## Documentation Fallback When Live Data Is Unavailable
-
-Live Azure MCP pricing data beats documentation. If live data is unavailable, incomplete, denied, or unsafe to query, switch to documentation/reference mode:
-
-- Use Microsoft Learn pricing-calculator and cost-management documentation for estimate behavior, scope limits, and planning guidance.
-- Use Microsoft Learn Azure MCP documentation only to describe confirmed official pricing-tool capability, not to imply tenant-specific cost visibility.
-- Ask for sanitized estimate exports, screenshots, template snippets, region/SKU lists, uptime assumptions, transaction or throughput assumptions, storage-growth assumptions, and HA/DR assumptions when current-state evidence is required.
-- Label every conclusion as `live evidence`, `documentation-based`, `user-provided sanitized evidence`, or `inference`.
-- Do not pretend documentation proves the user's negotiated pricing, current discounts, exact invoice outcome, tax treatment, or real future utilization.
+- "Based on Microsoft Learn documentation..."
+- "Configured-environment evidence was not sampled in this review."
+- "The following is an inference from the provided configuration, not proven live state."
+- "This recommendation is mutation-ready only after explicit approval and rollback review."

package/skills/azure/azure-cost-estimation-review/references/official-sources.md

@@ -1,23 +1,22 @@
-# Official Sources
+# Official sources for Azure Cost Estimation Review
 
-## References
+Use Microsoft Learn documentation through the user's configured documentation MCP before critiquing Azure estimates. Documentation and calculators support planning; they do not prove invoice truth, negotiated rates, future utilization, or missing architecture components.
 
-Load these only when needed, following progressive disclosure:
+## Primary Microsoft Learn sources
 
-- [Plan to manage Azure costs](https://learn.microsoft.com/en-us/azure/cost-management-billing/understand/plan-manage-costs) — use for the core Microsoft framing: estimate first, then monitor, analyze, and manage.
-- [Estimate costs with the Azure pricing calculator](https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/pricing-calculator) — use for calculator behavior, inputs, saved estimates, agreement-price caveats, and estimate-sharing limits.
-- [Cost Management + Billing documentation](https://learn.microsoft.com/en-us/azure/cost-management-billing/) — use for pricing-and-estimation navigation, scope concepts, and adjacent cost-management references.
-- [Azure landing zone governance design area](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/governance) — use when the estimate must be tied to ownership, scope, policy, and governance accountability.
-- [Manage savings plans](https://learn.microsoft.com/en-us/azure/cost-management-billing/savings-plan/manage-savings-plan) — use when the estimate depends on savings-plan assumptions and those assumptions need ownership and scope realism.
-- [Azure MCP Server tools inventory](https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/) — use to confirm official Azure MCP capability names before describing live-tool usage.
-- [Azure pricing tools for the Azure MCP Server](https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/azure-pricing) — use when official Azure MCP pricing evidence is available for retail pricing, billing questions, or template-based estimate support.
+| Source | Review implication |
+| --- | --- |
+| [Estimate costs with the Azure pricing calculator](https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/pricing-calculator) | Use for calculator mechanics, product configuration, usage quantities, pricing plans, exports, and negotiated-price caveats. |
+| [Plan to manage Azure costs](https://learn.microsoft.com/en-us/azure/cost-management-billing/understand/plan-manage-costs) | Use for estimation before adding services, price sheets, portal estimates, and planning limitations. |
+| [How to optimize your cloud investment with Cost Management](https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/cost-mgt-best-practices) | Use for planning, visibility, accountability, exports, budgets, APIs, and optimization lifecycle. |
+| [Plan your Azure environment for cost estimation](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/plan/estimate-total-cost-of-ownership) | Use for architecture-driven estimates, operational costs, and reevaluation when projections deviate. |
+| [Azure Retail Prices API](https://learn.microsoft.com/en-us/rest/api/cost-management/retail-prices/azure-retail-prices) | Use for programmatic retail pricing source; distinguish from negotiated billing rates. |
+| [Azure reservations](https://learn.microsoft.com/en-us/azure/cost-management-billing/reservations/save-compute-costs-reservations) | Use when estimates include one-year or three-year commitments. |
+| [Azure savings plans for compute](https://learn.microsoft.com/en-us/azure/cost-management-billing/savings-plan/savings-plan-overview) | Use when estimates include hourly compute commitments. |
 
-## Official Sources
+## Source-grounding rules
 
-- Microsoft Learn — Plan to manage Azure costs: https://learn.microsoft.com/en-us/azure/cost-management-billing/understand/plan-manage-costs
-- Microsoft Learn — Estimate costs with the Azure pricing calculator: https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/pricing-calculator
-- Microsoft Learn — Cost Management + Billing documentation: https://learn.microsoft.com/en-us/azure/cost-management-billing/
-- Microsoft Learn — Azure landing zone governance design area: https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/governance
-- Microsoft Learn — Manage savings plans: https://learn.microsoft.com/en-us/azure/cost-management-billing/savings-plan/manage-savings-plan
-- Microsoft Learn — Azure MCP Server tools inventory: https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/
-- Microsoft Learn — Azure pricing tools for the Azure MCP Server: https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/azure-pricing
+- Do not present calculator estimates as invoices.
+- Do not assume negotiated pricing unless the user provides safe proof or a configured read-only evidence sample verifies it.
+- Do not hide support, bandwidth, logging, backup, security, DR, NAT, private endpoint, or operational labor omissions.
+- Keep usage assumptions explicit and challenge one-month flat 730-hour defaults when workload patterns differ.

package/skills/azure/azure-cost-estimation-review/references/safety-checklist.md

@@ -0,0 +1,33 @@
+# Safety checklist for Azure Cost Estimation Review
+
+## Non-negotiable gates
+
+- Never ask for billing account identifiers, enrollment numbers, invoices, tenant identifiers, subscription identifiers, customer names, or screenshots containing sensitive billing data.
+- Do not claim exact future spend from calculator or retail API data.
+- Do not apply savings plans, reservations, or hybrid benefits unless utilization stability and eligibility are proven.
+- Do not ignore data transfer, support, logs, backups, monitoring, security services, private networking, and DR replicas.
+- Require explicit uncertainty labels for usage growth, regional price changes, negotiated rates, commitment coverage, and utilization.
+
+## High-risk assumptions to kill
+
+- "The calculator total is the budget." It is an estimate from configuration and usage assumptions.
+- "Retail price is our price." Negotiated and agreement-specific rates may differ.
+- "Reservations always save money." They can waste money if usage, region, or SKU changes.
+- "Nonproduction costs are negligible." Logs, databases, NAT, endpoints, and always-on plans can dominate.
+- "One architecture scenario is enough." Estimates need baseline, peak, DR, and growth cases.
+
+## Evidence labels
+
+- `docs_only`: pricing/estimation guidance only.
+- `estimate_review`: calculator export or architecture estimate reviewed.
+- `usage_informed`: historical usage or measured load informed the estimate.
+- `rate_verified`: negotiated or agreement-specific rate evidence was safely verified.
+- `commitment_ready`: utilization stability and commitment coverage are proven enough to consider reservations or savings plans.
+
+## Minimum safe evidence
+
+- Architecture bill of materials, regions, SKUs, tiers, quantities, hours, storage, data transfer, logs, backup, and support assumptions.
+- Environment split: production, staging, dev/test, DR, and shared services.
+- Workload pattern: baseline, peak, growth, seasonality, and shutdown assumptions.
+- Pricing basis: retail, calculator, price sheet, negotiated, or unknown.
+- Commitment assumptions: reservation, savings plan, hybrid benefit, term, scope, and utilization proof.