@raishin/vanguard-frontier-agentic 1.0.0

package/skills/azure/azure-cosmosdb-application-developer/metadata.json

@@ -0,0 +1,34 @@
+{
+  "id": "azure-cosmosdb-application-developer",
+  "name": "Azure Cosmos DB Application Developer",
+  "version": "0.1.0",
+  "type": "skill",
+  "provider": "azure",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Guide Azure Cosmos DB application development across NoSQL data modeling, partition-aware access patterns, point reads, query shape, SDK usage, transactional batch scope, and consistency-aware application behavior with explicit evidence-versus-inference handling.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/overview",
+    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/concepts",
+    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/",
+    "https://learn.microsoft.com/en-us/azure/cosmos-db/partitioning",
+    "https://learn.microsoft.com/en-us/azure/cosmos-db/modeling-data",
+    "https://learn.microsoft.com/en-us/azure/cosmos-db/consistency-levels",
+    "https://learn.microsoft.com/en-us/azure/cosmos-db/how-to-manage-consistency",
+    "https://learn.microsoft.com/en-us/azure/cosmos-db/query-metrics",
+    "https://learn.microsoft.com/en-us/azure/well-architected/service-guides/cosmos-db",
+    "https://learn.microsoft.com/en-us/azure/cosmos-db/transactional-batch",
+    "https://learn.microsoft.com/en-us/azure/cosmos-db/find-request-unit-charge"
+  ],
+  "security_notes": "Do not recommend data models, query patterns, transactional assumptions, or SDK usage that ignore partition scope, RU cost, consistency semantics, or least-privilege access boundaries.",
+  "last_verified": "2026-04-28",
+  "path": "skills/azure/azure-cosmosdb-application-developer",
+  "author": "github: Raishin"
+}

package/skills/azure/azure-cosmosdb-application-developer/references/mcp-and-evidence.md

@@ -0,0 +1,31 @@
+# MCP and evidence path
+
+Use this reference only when you need to decide how to gather evidence.
+
+## Live-first evidence rule
+
+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.
+
+## Azure MCP grounding
+
+Based on Microsoft documentation:
+
+- 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.
+
+Implication:
+
+- 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

package/skills/azure/azure-cosmosdb-application-developer/references/official-sources.md

@@ -0,0 +1,36 @@
+# Official sources
+
+Use this reference only when you need the detailed source list or need to ground a specific claim.
+
+## Azure MCP
+
+- 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/
+
+## Azure Cosmos DB
+
+- 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
+- Transactional batch in Azure Cosmos DB  
+  https://learn.microsoft.com/en-us/azure/cosmos-db/transactional-batch
+- Find request unit charge in Azure Cosmos DB  
+  https://learn.microsoft.com/en-us/azure/cosmos-db/find-request-unit-charge
+
+## 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.

package/skills/azure/azure-cosmosdb-application-developer/references/workflow-and-output.md

@@ -0,0 +1,36 @@
+# Workflow and output contract
+
+Use this reference only when you are performing the full review or implementation-guidance pass.
+
+## Workflow
+
+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.
+
+2. **Establish evidence level**
+   - Use live Azure MCP evidence when available.
+   - Otherwise use official docs plus sanitized user evidence.
+   - Explicitly label unknowns.
+
+3. **Stress checks**
+   - Check the target API/workload, dominant read/write patterns, and whether the workload is greenfield or existing.
+   - Stress-test data modeling: embed vs reference, unbounded arrays, precalculated aggregates, and document growth.
+   - Prefer point reads and partition-aware queries; challenge lazy cross-partition scans and RU-blind joins-by-application.
+   - Call out transactional batch scope, session-consistency behavior, and SDK request-charge observability.
+
+4. **Check adjacent roles the user may be missing**
+   - **Azure Cosmos DB Platform Operator** when the real issue is account/platform posture rather than code-facing design.
+   - **Azure Observability Investigator** when the next problem is tracing query latency, alerts, or telemetry gaps.
+   - **Azure AI Foundry Ops Governor** when Cosmos DB becomes part of a larger AI application governance path.
+
+## Output contract
+
+Use this structure:
+
+1. **Verdict**
+2. **Evidence level**
+3. **Key findings**
+4. **Safest next actions**
+5. **Open questions**

package/skills/azure/azure-cosmosdb-performance-investigator/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: azure-cosmosdb-performance-investigator
+description: Use this skill for Azure Cosmos DB performance investigation, especially RU spikes, query latency, throttling, hot partitions, indexing inefficiency, partition-skew analysis, request-charge profiling, diagnostic-log review, and evidence-driven remediation planning.
+metadata:
+  author: github: Raishin
+  version: 0.1.0
+---
+
+# Azure Cosmos DB Performance Investigator
+
+## Purpose
+
+Investigate Azure Cosmos DB performance pathologies with evidence-first profiling instead of lazy “add more RUs” advice.
+
+This skill is for deep performance work across:
+
+- RU inefficiency and unexpected request-charge spikes,
+- query latency and scan-heavy query behavior,
+- hot partitions and partition-key skew,
+- throttling, retry inflation, and client-perceived latency,
+- indexing gaps and poor query/index alignment,
+- container, partition, and workload-level profiling,
+- diagnostic-log and metrics-backed remediation planning.
+
+## When to use
+
+Use this skill when the user asks for:
+
+- slow Azure Cosmos DB queries or workload latency,
+- high RU cost or suspicious request-charge behavior,
+- 429 throttling analysis,
+- hot partition or partition-skew investigation,
+- indexing or query-performance tuning,
+- a step-by-step Cosmos DB profiling plan.
+
+Do not use this skill as a substitute for:
+
+- initial data-model design when the main problem is greenfield schema modeling,
+- pure account/platform governance review when performance is incidental,
+- generic application debugging unrelated to Cosmos DB workload behavior,
+- vector-search-specific Mongo vCore tuning unless the user explicitly asks for that API surface.
+
+## 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.
+- Separate confirmed facts from inference. If state was not queried or shown, say so.
+- Challenge throughput-first fixes that ignore partition skew, query scans, indexing, or client retry inflation.
+- Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
+
+## References
+
+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.
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full investigation, applying stress checks, or formatting the final answer.
+- [Data profiling playbook](references/data-profiling-playbook.md) — use when you need the detailed step-by-step profiling sequence.
+- [Official sources](references/official-sources.md) — use when you need the detailed Microsoft documentation list or source notes.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the main performance pathologies observed or still unproven,
+- the safest next profiling or remediation steps,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/azure/azure-cosmosdb-performance-investigator/metadata.json

@@ -0,0 +1,33 @@
+{
+  "id": "azure-cosmosdb-performance-investigator",
+  "name": "Azure Cosmos DB Performance Investigator",
+  "version": "0.1.0",
+  "type": "skill",
+  "provider": "azure",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Investigate Azure Cosmos DB query latency, RU inefficiency, throttling, hot partitions, indexing gaps, and workload-level performance pathologies using explicit evidence, metrics, and step-by-step profiling discipline.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/overview",
+    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/concepts",
+    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/",
+    "https://learn.microsoft.com/en-us/azure/cosmos-db/troubleshoot-query-performance",
+    "https://learn.microsoft.com/en-us/azure/cosmos-db/query-metrics",
+    "https://learn.microsoft.com/en-us/azure/cosmos-db/index-metrics",
+    "https://learn.microsoft.com/en-us/azure/cosmos-db/use-metrics",
+    "https://learn.microsoft.com/en-us/azure/cosmos-db/how-to-redistribute-throughput-across-partitions",
+    "https://learn.microsoft.com/en-us/azure/cosmos-db/performance-tips-dotnet-sdk-v3",
+    "https://learn.microsoft.com/en-us/azure/well-architected/service-guides/cosmos-db"
+  ],
+  "security_notes": "Do not recommend throughput increases, repartitioning, indexing changes, or SDK tuning before separating RU cost, latency, partition skew, and query-shape evidence. Avoid speculative fixes that hide workload design defects.",
+  "last_verified": "2026-04-28",
+  "path": "skills/azure/azure-cosmosdb-performance-investigator",
+  "author": "github: Raishin"
+}

package/skills/azure/azure-cosmosdb-performance-investigator/references/data-profiling-playbook.md

@@ -0,0 +1,194 @@
+# Data profiling playbook
+
+Use this reference when the user needs a detailed, step-by-step Cosmos DB performance investigation path.
+
+## Goal
+
+Determine whether the workload problem is caused primarily by:
+
+- bad query shape,
+- index mismatch,
+- partition-key skew,
+- insufficient or badly distributed throughput,
+- cross-region or client-side latency,
+- retry amplification,
+- poor workload access patterns,
+- or multiple issues at once.
+
+## Step 1: Define the symptom precisely
+
+Capture exactly which of these is true:
+
+1. RU charge is too high.
+2. Query latency is too high.
+3. 429 throttling is frequent.
+4. One partition or one workload slice is much worse than others.
+5. The issue is intermittent rather than constant.
+
+If the user only says “Cosmos is slow,” push back and force narrower symptom definition.
+
+## Step 2: Fix the observation window
+
+Before analysis, anchor the time range.
+
+Recommended windows:
+
+- **1 hour** for a sharp incident or deploy regression
+- **24 hours** for day-pattern investigation
+- **7 days** for partition-skew or periodic workload behavior
+
+Do not compare unrelated windows.
+
+## Step 3: Establish workload scope
+
+Identify:
+
+- account
+- database
+n- container
+- API type
+- top queries or endpoints
+- whether the issue is read-heavy, write-heavy, or mixed
+
+If the user cannot identify the hot path, say the conclusion will remain weaker.
+
+## Step 4: Measure request charge first
+
+For code-facing workloads, collect request charge from the SDK or response headers.
+
+Why:
+
+- RU cost is the fastest way to distinguish inefficient operations from mere latency complaints.
+- A stable high request charge suggests query/data/index issues.
+- A low request charge with high latency suggests retries, distance, contention, or client behavior.
+
+Collect examples for:
+
+- representative point read
+- representative query
+- representative write or batch operation
+
+## Step 5: Get query metrics
+
+For each expensive or slow query:
+
+1. collect query metrics
+2. compare **Retrieved Document Count** vs **Output Document Count**
+3. flag scan-heavy behavior when retrieved greatly exceeds output
+
+Interpretation:
+
+- **Retrieved much higher than output** → likely index miss or scan-heavy predicate/function behavior
+- **Retrieved approximately equal to output** with high RU → maybe wide result sets, cross-partition cost, or costly ordering/filter combinations
+- **RU acceptable but latency high** → move to proximity, retries, concurrency, and buffering checks
+
+## Step 6: Check index metrics only when troubleshooting
+
+Use index metrics when query behavior is suspicious and the indexing path is unclear.
+
+Look for:
+
+- utilized indexed paths
+- recommended indexed paths
+- evidence that the current indexing policy does not support the query efficiently
+
+Do not blindly expand indexing on every field without considering write cost.
+
+## Step 7: Test for hot partitions
+
+Use portal insights or equivalent telemetry to inspect:
+
+- **Normalized RU Consumption (%) By PartitionKeyRangeID**
+
+Interpretation:
+
+- one or a few ranges consistently near saturation while others are low strongly suggests skew
+- even usage with high overall pressure suggests general underprovisioning or globally inefficient workload design
+
+## Step 8: Move from physical skew to logical key offenders
+
+If hot partitions are suspected:
+
+1. enable and inspect diagnostic logs if available
+2. use partition-key RU consumption data to identify the top logical partition keys
+3. review at least several days when possible, not just one bursty hour
+
+This is where “add more RUs” often fails. If a few keys dominate, throughput growth can mask the problem without fixing it.
+
+## Step 9: Profile query shape versus access pattern
+
+Ask or verify:
+
+- should this be a point read instead of a query?
+- is the partition key included where it should be?
+- is the query filtering on properties that align with the partition strategy?
+- is ORDER BY combined with filters in a way the index supports?
+- is the application doing repeated small round trips that should be consolidated?
+
+Common anti-patterns:
+
+- using queries where a point read would do
+- cross-partition fan-out for tenant-local data
+- filtering on secondary properties without an index strategy
+- embedding data that grows without bound and inflates read/write cost
+
+## Step 10: Separate server-side from client-side latency
+
+If RU looks acceptable but latency is still poor, check:
+
+- region proximity between app and Cosmos DB account
+- throttling retries inflating end-to-end time
+- MaxConcurrency for parallel queries
+- MaxBufferedItemCount / prefetch behavior
+- client connection reuse / SDK posture
+
+Do not blame the database alone without this separation.
+
+## Step 11: Profile storage and index footprint
+
+Inspect storage insights when available:
+
+- data usage
+- index usage
+- document usage
+
+Use this to spot cases where index footprint is high relative to value or where document shape is inflating costs.
+
+## Step 12: Classify the root cause before prescribing remediation
+
+Use one or more of these buckets:
+
+1. **Query/index mismatch**
+2. **Partition-key skew / hot partitions**
+3. **General underprovisioning**
+4. **Client-side latency / retries / distance**
+5. **Data-model inefficiency**
+6. **Mixed causes**
+
+If evidence is incomplete, say so.
+
+## Step 13: Recommend bounded remediations
+
+Good remediation examples:
+
+- capture request charge for the top 3 slow queries before changing throughput
+- enable query metrics on one hot query and compare retrieved vs output counts
+- inspect normalized RU consumption by partition key range for 7 days
+- review whether a hot query should become a point read
+- test one indexing-policy adjustment against one proven expensive query
+
+Bad remediation examples:
+
+- “just increase RUs”
+- “just repartition everything”
+- “turn on every index”
+- “switch consistency” without naming the application tradeoff
+
+## Step 14: Decide when to hand off to another role
+
+Hand off or recommend adjacent roles when:
+
+- the platform posture itself is the main issue → **Azure Cosmos DB Platform Operator**
+- the data model / query code is the main issue → **Azure Cosmos DB Application Developer**
+- alerting / visibility is the main issue → **Azure Observability Investigator**
+- ongoing RU waste and budget posture dominate → **Azure Cost Optimization Governor**

package/skills/azure/azure-cosmosdb-performance-investigator/references/mcp-and-evidence.md

@@ -0,0 +1,38 @@
+# MCP and evidence path
+
+Use this reference only when you need to decide how to gather Cosmos DB performance evidence.
+
+## Live-first evidence rule
+
+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.
+
+## Azure MCP grounding
+
+Based on Microsoft documentation:
+
+- 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.
+
+Implication:
+
+- 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 metrics, sanitized Data Explorer screenshots, sanitized query metrics, or diagnostic-log output
+2. **user-provided sanitized evidence** — redacted SDK traces, query text, request-charge samples, portal screenshots, IaC snippets, logs
+3. **documentation-based** — Microsoft Learn and official Azure MCP documentation
+4. **inference** — conclusions derived from patterns but not directly proven by evidence
+
+## Performance-specific caution points
+
+- A 429 spike does not automatically prove underprovisioning; it can also indicate skew, bursts, or bad query shape.
+- Acceptable RU charge does not prove acceptable latency.
+- High latency does not automatically prove server-side slowness; region distance, retries, and client configuration matter.
+- Index metrics are for troubleshooting; do not turn them into always-on ritual without cause.

package/skills/azure/azure-cosmosdb-performance-investigator/references/official-sources.md

@@ -0,0 +1,37 @@
+# Official sources
+
+Use this reference only when you need the detailed source list or need to ground a specific claim.
+
+## Azure MCP
+
+- 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/
+
+## Azure Cosmos DB performance and profiling
+
+- Troubleshoot query issues when using Azure Cosmos DB  
+  https://learn.microsoft.com/en-us/azure/cosmos-db/troubleshoot-query-performance
+- Tuning query performance with Azure Cosmos DB  
+  https://learn.microsoft.com/en-us/azure/cosmos-db/query-metrics
+- Indexing metrics in Azure Cosmos DB  
+  https://learn.microsoft.com/en-us/azure/cosmos-db/index-metrics
+- Monitor and debug with insights in Azure Cosmos DB  
+  https://learn.microsoft.com/en-us/azure/cosmos-db/use-metrics
+- Redistribute throughput across partitions in Azure Cosmos DB  
+  https://learn.microsoft.com/en-us/azure/cosmos-db/how-to-redistribute-throughput-across-partitions
+- Performance tips for Azure Cosmos DB and .NET  
+  https://learn.microsoft.com/en-us/azure/cosmos-db/performance-tips-dotnet-sdk-v3
+- Partitioning and horizontal scaling in Azure Cosmos DB  
+  https://learn.microsoft.com/en-us/azure/cosmos-db/partitioning
+- Architecture best practices for Azure Cosmos DB for NoSQL  
+  https://learn.microsoft.com/en-us/azure/well-architected/service-guides/cosmos-db
+
+## Grounded insights used by this skill
+
+- Request charge, query metrics, and partition-level metrics are more trustworthy than intuition.
+- High RU and high latency are not the same failure mode.
+- Hot-partition diagnosis needs partition-range and logical-key evidence, not just aggregate throttling counts.

package/skills/azure/azure-cosmosdb-performance-investigator/references/workflow-and-output.md

@@ -0,0 +1,46 @@
+# Workflow and output contract
+
+Use this reference only when you are performing the full performance investigation.
+
+## Workflow
+
+1. **Scope the target**
+   - Confirm API/workload if known: NoSQL, Mongo, Cassandra, Gremlin, Table, or unknown.
+   - Confirm whether the symptom is RU cost, latency, throttling, partition skew, or mixed.
+   - Confirm whether the issue is one query, one container, one service, or a broader workload.
+
+2. **Establish evidence level**
+   - Use live Azure MCP evidence when available.
+   - Otherwise use official docs plus sanitized user evidence.
+   - Explicitly label unknowns.
+
+3. **Separate the failure modes before prescribing fixes**
+   - RU inefficiency
+   - latency despite acceptable RU
+   - 429 throttling and retry amplification
+   - hot partition / physical partition skew
+   - indexing mismatch or query scan behavior
+   - client-side concurrency / buffering / proximity issues
+
+4. **Prefer measurement over guesswork**
+   - request charge
+   - query metrics
+   - index metrics when troubleshooting
+   - normalized RU consumption by partition key range
+   - diagnostic logs for partition-level RU consumers
+
+5. **Check adjacent roles the user may be missing**
+   - **Azure Cosmos DB Platform Operator** when the root issue becomes throughput posture, account-level configuration, or broader platform controls.
+   - **Azure Cosmos DB Application Developer** when the dominant defect is data model, access pattern, or code-side query design.
+   - **Azure Observability Investigator** when the next problem is telemetry pipeline, alerts, or broader operational visibility.
+   - **Azure Cost Optimization Governor** when the recurring question becomes budget, autoscale governance, or cost-control posture.
+
+## Output contract
+
+Use this structure:
+
+1. **Verdict**
+2. **Evidence level**
+3. **Key findings**
+4. **Safest next actions**
+5. **Open questions**

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

@@ -0,0 +1,54 @@
+---
+name: azure-cosmosdb-platform-operator
+description: Use this skill for Azure Cosmos DB platform operations and design review, especially accounts, databases, containers, partition-key design, throughput and RU posture, consistency choices, indexing, throttling, multi-region replication, private connectivity, and Cosmos DB MCP-guided discovery.
+metadata:
+  author: github: Raishin
+  version: 0.1.0
+---
+
+# Azure Cosmos DB Platform Operator
+
+## Purpose
+
+Review and guide Azure Cosmos DB platform posture without hand-wavy assumptions about partitioning, consistency, throughput, or multi-region behavior.
+
+## When to use
+
+Use this skill when the user asks for:
+
+- Azure Cosmos DB account, database, or container operational review,
+- partition-key, consistency, throughput, or indexing decisions,
+- RU cost, throttling, hot partition, or multi-region tradeoff analysis,
+- private endpoint, failover, or platform control-plane posture questions,
+- Cosmos DB MCP-backed discovery or evidence gathering.
+
+Do not use this skill as a substitute for:
+
+- application code implementation details unless they directly affect platform posture,
+- generic landing-zone or network architecture when Cosmos DB is incidental,
+- RBAC-only analysis when the real problem is identity governance rather than database platform design,
+- vector-search-specific Mongo vCore implementation unless the user explicitly asks for that API surface.
+
+## 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.
+- Separate confirmed facts from inference. If state was not queried or shown, say so.
+- Challenge broad scope, vague partition keys, and RU-blind advice.
+- Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
+
+## References
+
+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.
+- [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.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the main design or operational risks,
+- the safest next actions,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/azure/azure-cosmosdb-platform-operator/metadata.json

@@ -0,0 +1,33 @@
+{
+  "id": "azure-cosmosdb-platform-operator",
+  "name": "Azure Cosmos DB Platform Operator",
+  "version": "0.1.0",
+  "type": "skill",
+  "provider": "azure",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review and operate Azure Cosmos DB platform posture across accounts, databases, containers, partitioning, throughput, consistency, indexing, throttling, multi-region tradeoffs, and operational guardrails with explicit evidence-versus-inference handling.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/overview",
+    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/concepts",
+    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/",
+    "https://learn.microsoft.com/en-us/azure/cosmos-db/partitioning",
+    "https://learn.microsoft.com/en-us/azure/cosmos-db/modeling-data",
+    "https://learn.microsoft.com/en-us/azure/cosmos-db/consistency-levels",
+    "https://learn.microsoft.com/en-us/azure/cosmos-db/how-to-manage-consistency",
+    "https://learn.microsoft.com/en-us/azure/cosmos-db/query-metrics",
+    "https://learn.microsoft.com/en-us/azure/well-architected/service-guides/cosmos-db",
+    "https://learn.microsoft.com/en-us/azure/cosmos-db/hierarchical-partition-keys"
+  ],
+  "security_notes": "Do not approve a partition key, indexing posture, consistency change, or cross-partition query strategy without checking workload shape, RU impact, transactional scope, and least-privilege access implications.",
+  "last_verified": "2026-04-28",
+  "path": "skills/azure/azure-cosmosdb-platform-operator",
+  "author": "github: Raishin"
+}