From db-cosmosdb
Use when scaffolding or reviewing Azure Cosmos DB project layout — container definition files, custom migration layout, model organization, and partition key documentation
How this skill is triggered — by the user, by Claude, or both
Slash command
/db-cosmosdb:cosmosdb-project-structureThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
```
database/
├── containers/
│ ├── orders.json # Container definition (partition key, indexing policy, TTL)
│ ├── customers.json
│ └── leases.json # Change feed lease container
├── models/
│ ├── Order.cs # Document model with type discriminator
│ ├── OrderItem.cs
│ ├── Customer.cs
│ └── BaseDocument.cs # Base class with id, type, schemaVersion, _etag
├── migrations/
│ ├── 001_AddStatusField.cs
│ ├── 002_AddCompositeIndex.cs
│ └── MigrationRunner.cs
├── stored-procedures/
│ ├── bulkCreateItems.js
│ └── updateOrderStatus.js
├── udfs/
│ └── calculateDiscount.js
├── triggers/
│ ├── pre/
│ │ └── validateOrder.js
│ └── post/
│ └── updateAggregates.js
├── seed/
│ ├── lookup/
│ │ └── orderStatuses.json
│ └── dev/
│ └── sampleOrders.json
├── tests/
│ ├── OrderRepository.Tests.cs
│ └── MigrationRunner.Tests.cs
├── infrastructure/
│ ├── cosmos-account.bicep # Or Terraform
│ └── indexing-policies/
│ ├── orders-policy.json
│ └── customers-policy.json
└── docs/
└── partition-key-decisions.md # Document partition key rationale
containers/type discriminator and schemaVersion for safe migrationsmigrations/ for versioned data migrations (not schema — Cosmos DB is schemaless)stored-procedures/, udfs/, triggers/ for server-side code (JavaScript)infrastructure/ for IaC definitions (Bicep or Terraform)docs/partition-key-decisions.md — REQUIRED: document why each partition key was chosenseed/lookup/ for reference dataseed/dev/ for development-only sample dataid, type, schemaVersion, createdAt, _etagnpx claudepluginhub gagandeepp/software-agent-teams --plugin db-cosmosdbGuides completion of development work by verifying tests, detecting environment, and presenting structured options for merge, PR, or cleanup.
Enforces test-driven development: write failing test first, then minimal code to pass. Use when implementing features or bugfixes.
Guides creation and editing of skills using test-driven development with pressure scenarios and subagents to verify agent compliance.