Azure Cosmos DB ships first GitHub Spec Kit database extension

Microsoft’s Azure Cosmos DB team announced public preview of the first database extension for GitHub Spec Kit, giving coding agents structured guidance for Cosmos DB apps — partitioning, queries, implementation, and review.

TOOLS desk — databases are shipping agent-native specs so coding bots stop guessing at partition keys.

The path is spec-driven development. You settle what you are building, then the design, then the task list, before the code. The agent writes a document at each stage that a person can read, correct, and approve. Spec Kit’s commands, on the post, are four. Specify captures what you are building and why. Plan turns that into an architecture and a data model, which is where the database decisions get made. Tasks breaks the plan into ordered pieces of work a person can check. Implement generates the code, task by task, against that plan. The claim diagram on this filing shows five stages in a row: Spec, Plan, Tasks, Implement, Review. The post’s review is the step after the code exists. You look at the plan before you let the agent implement, and a review step checks the generated code afterward. Review is on the diagram and in that copy. It is not a fifth command name the post prints. File the path as Microsoft’s.

Why a database gets its own guidance. The post says coding agents can write much of an application’s code, but a person still has to review the decisions behind it. For a Cosmos DB app that includes the partition key, the access patterns, and the client setup. Those choices affect cost, speed, and reliability long after the code compiles. A partition key is the field Cosmos DB uses to group related items. A weak key makes the busiest lookups slow and expensive. An access pattern is how the app actually reads and writes. The client is the code that talks to the database. Without this extension, Spec Kit is database-agnostic: its database advice depends on what the model already knows and on whatever context you supply. The extension adds Cosmos DB guidance on partitioning, request-unit costs, point reads, indexing, and a client built to survive a blip. A request unit, shortened to RU, is Cosmos DB’s own unit for what a read or a write costs. A point read is fetching one item by its id and its partition key, the cheap lookup. Indexing is how the database finds items that are not that single lookup. File those focus areas as Microsoft’s. The post does not print a price.

What the extension provides, still that post. Commands that generate code for point reads, for queries that stay inside one partition and pass their values in separately, for sign-in through a managed identity, and for a client that retries cleanly. A query that passes values in separately is harder for a stray string to rewrite. A managed identity is a login the cloud issues to the app, so the code does not store a password. Separate guidance helps you choose containers and partition keys from how the app reads and writes. A container is Cosmos DB’s box of items. An advisor runs before the code is written. The post calls that the before-implement hook: it picks the relevant patterns and puts their rules into the notes the agent sees while it writes. A review runs after the code exists. The after-implement hook tells the agent to check the code against Cosmos DB guidance, fix what it finds, and check again. The post says you should still review and test the result. The extension works with GitHub Copilot, Claude Code, Codex, Cursor, and Gemini CLI, and it can sit beside other extensions. It complements the Cosmos DB Agent Kit, which the post describes as skills for everyday coding, by making that guidance available inside Spec Kit’s stages. File that list as Microsoft’s.

A team can add its own rules without forking the extension. Spec Kit presets carry naming standards, preferred library patterns, security requirements, and extra review steps. A preset can wrap the command templates, combine this extension with others, and stay in its own file so an update is easier to take. The post’s example is a platform team publishing approved regions and sign-in requirements. The documents and the code still need a person. A preset supplies shared instructions. It does not enforce the team’s policies. File that limit as Microsoft’s.

What Microsoft measured, on the checks it chose. The post compares code written with the guidance and without it, across models, languages, and how hard the task was. The checks cover setting the client’s application name, point reads that use an id and a partition key, treating a not-found reply as a missing item, queries that stay in one partition and pass their values in separately, version stamps so two writers do not silently overwrite each other, batches that succeed or fail together, sign-in without a stored key, and partition-key design. With the guidance applied, the average pass rate rose by 0.10, which the post calls about 10 percentage points, with gains in 19 of 24 test combinations, and the runs were more consistent. The largest gain was the application-name setting: plus 0.79 in pass rate. Tests of the individual commands gained plus 0.14 to plus 0.37. Models that already followed the guidance had less room to move. Microsoft also tuned which command the advisor recommends, and precision moved from 0.57 to 0.68. Precision, here, means how often the recommended command was the right one. These tests show the guidance improved the checks they ran. The post says they do not show that every command is correct in every application. File the numbers as Microsoft’s. This desk did not rerun them.

The end-to-end tests are the limit, and the post states it. When agents ran the whole workflow on their own, they often skipped the recommended Cosmos DB commands and wrote the data layer without that guidance. That finding is why the preview release the post calls v0.2.0 changed the delivery. The advisor now puts the relevant rules directly into the notes the agent sees, and both the advisor and the review are set so the agent cannot skip them. The review also tells the agent to apply fixes and check again. On the models that produced usable scores, the updated extension scored modestly higher on average than the previous version, although the uncertainty leaves room for no improvement. It landed roughly even with Spec Kit alone, and it stayed below an agent working with no Spec Kit at all, in those unattended tests. A third model produced no usable scores because the agent runtime failed. The tests did not measure what happens when a person reviews each stage. The post’s own summary is the one to keep: the clearest measured benefit so far is better conformance to the best practices they checked, when the guidance is actually supplied. The application tests helped them change how that guidance reaches the agent. They do not yet show a broader end-to-end win. File that caveat as Microsoft’s. A public preview is not a claim that the bot now gets Cosmos DB right by itself.

Do not invent a general-availability date, a price, or support for some other database. None of those are in the post. The closer describes Azure Cosmos DB as a fully managed serverless database for NoSQL and for vectors, including AI apps. NoSQL means the data is not stored as classic tables of rows. A vector is a list of numbers used to search by meaning. That closer is the product description. It is not a new engine this extension adds. Command names may change during preview. The install line stays in Sources.

Plain English for the rest of the card: coding agent = software that writes an application from instructions. Azure Cosmos DB = Microsoft’s cloud database. GitHub Spec Kit = an open framework that writes a spec, a plan, and a task list before the code. public preview = you can try it; not a finished general release. partition key = the field Cosmos DB uses to group related items. request unit / RU = Cosmos DB’s unit for what a read or a write costs. point read = one item, fetched by its id and its partition key. indexing = how the database finds items that are not that single lookup. container = Cosmos DB’s box of items. managed identity = a cloud-issued login, so the app does not store a password. preset = a team’s extra instructions, kept separate from the extension. pass rate = the share of checks that succeeded, on Microsoft’s tests. This filing is the 21 Sep public-preview post. It is not a price, and it is not a general release.

PRIMARY here: the Azure Cosmos DB blog, 21 Sep 2026, “Spec-Driven Development comes to Azure Cosmos DB: The First Database Extension for GitHub Spec Kit,” by Theo van Kraay — Tier A PRIMARY, the company’s own post, the originating record. The public preview, the first-database-extension line, the Spec-Plan-Tasks-Implement path plus the review step, the partition-key and query guidance, the before-implement advisor and the after-implement review, the compatible agents, the preset limit, the 0.10 pass-rate gain, the 19-of-24 line, the 0.79 application-name gain, the 0.57-to-0.68 precision move, the v0.2.0 delivery change, and the end-to-end caveat are the post’s. The v0.2.0 tag time on GitHub is earlier than this announcement and stays in Sources. NOT claimed: a general-availability date, a price, support for another database, that this desk installed the extension or reran the tests, that unattended agents now beat a plain coding agent end to end, a stock tip, or investment advice. Distinct from the already-filed microsoft-retrochimera, microsoft-global-ai-diffusion-q2, and microsoft-india-south-central-ai.