Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Description from the maker (original English)
Verify what agents actually shipped, arbitrate file collisions, refuse with structured reasons.
These three are never merged into one score: opinions, measurements and popularity are different things.
We have not written a plain-language summary for this one yet. Below are the facts we read from the registry.
Pick the AI app you use, then copy the settings.
DISPATCH_WORKSPACEYou need
Which app do you use?
Pick your app above. We remember it, so next time the button says “Install in …”.
Open Claude Desktop → Settings → Developer → Edit Config, and paste this into claude_desktop_config.json
{
"mcpServers": {
"dos-kernel": {
"command": "uvx",
"args": [
"dos-kernel"
],
"env": {
"DISPATCH_WORKSPACE": "your-value"
}
}
}
}Run this in your terminal
claude mcp add dos-kernel --env DISPATCH_WORKSPACE=your-value -- uvx dos-kernelFill in the empty values before running it.
Paste into .cursor/mcp.json in your project, or ~/.cursor/mcp.json
{
"mcpServers": {
"dos-kernel": {
"command": "uvx",
"args": [
"dos-kernel"
],
"env": {
"DISPATCH_WORKSPACE": "your-value"
}
}
}
}Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
Paste into .vscode/mcp.json in your project
{
"servers": {
"dos-kernel": {
"type": "stdio",
"command": "uvx",
"args": [
"dos-kernel"
],
"env": {
"DISPATCH_WORKSPACE": "your-value"
}
}
}
}Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
This one runs on your computer, and ChatGPT can only connect to servers on the internet. Pick another app.
Your choice stays on this device in a cookie; no account needed.
DISPATCH_WORKSPACE envThese settings are generated from the maker’s registry entry. If the README says otherwise, follow the README.
Runs on your computer; the tool list appears in your AI app after you install it.
We check information anyone can see; we have not read the code. Checks that do not apply are left out of the count. · Checked Nov 7, 2026
The registry name was verified with the GitHub account anthony-chaudhary, which owns the repo
We have not read this repo from GitHub yet
We have not read this repo from GitHub yet
This one runs on your computer; there is no internet endpoint
Runs on your computer and uses local settings instead
Runs on your computer; we can only read tool lists from internet endpoints
Compared with every active server in this category in the registry. Stars count only when the publisher owns the repo.
It passed 1 of 1 applicable basic checks. We have not read the code. Before adding a key or token, see what access the server asks for and use a key with only the permissions you need.
The registry does not list a required key, though some servers ask you to sign in on first use.
It runs on your computer. Your AI app starts it when needed, and data does not pass through the maker’s servers (unless it calls an online service itself).
The GitHub repo last changed –, and the latest version (0.30.0) reached the registry 4 months ago.
Apps that support MCP, such as Claude Desktop, Claude Code, Cursor and VS Code. You also need Python (uv) on your computer.
In the same category: Spec Driven Development, Remote Desktop Commander, Detailing Manager
Servers in the same category from other makers, sorted by stars.
Reading a card:★ GitHub starsiThree pillars: reviews · checks · usageiUpdated = latest version published to the registryi
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
Connect your auto detailing studio's tasks, cars, clients and revenue to Claude or ChatGPT.
Copied from the maker’s repo as written. PopNx MCP has not reviewed or endorsed it. HTML, images and scripts are removed. Links lead off this site.
### Catch your AI agents when they lie about what they shipped.
📊 See it run on real repos: the [scoreboard](https://anthony-chaudhary.github.io/dos-kernel/scoreboard/)
scores 15 popular AI-built repos (roborev, open-interpreter, crewAI, autogen, …)
— how much agents wrote, which ones, and whether each commit's claim is backed
by its own diff. Score yours:
dos commit-audit --sweep --workspace . BASE..HEAD.
The whole pitch in one recording: the agent claims two features shipped; git backs one. dos verify answers from the commits, the lie exits 1 , and a gate on that exit code refuses the false "done". Every line is the real CLI's verbatim output — scripts/build_caught_lie_cast.py re-records it whenever the output changes.
Run a fleet of agents on one repo. The left loop just feels like progress; the right one you can steer. The only difference is a verdict DOS reads from the real world — here, git — never the agent's word.
An AI agent will tell you it finished. DOS checks the real world instead of taking its word — and the nearest piece of the real world is your git history. An agent says it shipped the login endpoint; did it? Run one command, dos verify, and it answers from the artifacts the work left behind, not from what the agent typed: a commit backs the claim → SHIPPED, exit 0; nothing landed → NOT_SHIPPED, exit 1. The agent's story never enters into it. (Git is just the first witness DOS reads; the file tree, the clock, a CI status, a test environment's own state are others — anything the agent didn't author.)
dos verify AUTH AUTH1 # → SHIPPED AUTH AUTH1 e62f74d (exit 0)
dos verify AUTH AUTH2 # → NOT_SHIPPED AUTH AUTH2 (exit 1)
That's the smallest version. It scales up, too: point a dozen agents at one repo — in CI, in a fleet, racing on the same files — and DOS also tells you which ones are stepping on each other, which one is spinning in circles, and which claim of "done" is real. Every answer comes from the artifacts (git, the file tree, the clock), never the narration. It works on a plain git repo with zero config and gets smarter the more you tell it, and the only thing you ever install is one small Python package.
DOS is a Python package you install into the existing git repo where your agents work. You do not need to clone or fork the DOS source unless you plan to develop DOS itself.
cd path/to/your-repo
pip install dos-kernel dos init --hooks auto # detects the agent runtime(s) already in this repo dos doctor # shows exactly what this workspace is using
From then on, your agent cannot tell you "done" unless the work actually landed, two agents cannot silently overwrite each other's files, and a run that stalls gets flagged instead of quietly spinning. dos init prints the config and hook entries it wrote; removing those generated entries undoes the setup. If no runtime is detected, it says so and lists the explicit choices — it never guesses.
| What you want | Start here |
|---|---|
| Use DOS in my repo | Install the package, then run dos init --hooks auto in that repo (the setup above). |
| See the 60-second demo | Run uvx --from dos-kernel dos quickstart; it creates and removes a throwaway repo. |
| Read or change DOS itself | Clone this repository and use the contributor install; most users do not need the source clone. |
v0.30.0 · 5,600+ tests · CI: Python 3.11–3.13 on Linux + a Windows 3.13 smoke run · the only runtime dependency is PyYAML · MIT.
🧭 Where to go next: the why & evidence (plain-words story, the 20-lines-of-bash answer, what's proven),
wire it into your stack (MCP · hooks · install), the
syscall + CLI reference, or, reading this as an AI agent?, AGENTS.md — build/test/check in three lines. The full map is the router just below.
🔤 Five words the rest of this page leans on. A plan is a named goal
(
AUTH); a phase is one shippable step of it (AUTH1); a lane is the
slice of the file tree one agent may touch; the oracle is the part of DOS
that reads the evidence and rules; a stamp is the mark a shipped phase
leaves in a commit subject (
AUTH1: …) — the thing the oracle greps for.
That's the whole vocabulary.
A coding agent does work, then tells you how it went. Usually the story is true; sometimes it's the cheerful *"all work completed!"* from a worker that shipped nothing. With one agent you catch that yourself by re-reading its output — a real tax you already pay. Run twenty at once and that tax stops being payable: nobody reads everything, each worker grades its own homework, and the unchecked problems pile up quietly until the codebase *sorta* works and nobody can safely change it. DOS is the referee that never reads the story — it reads what happened (the commit, the file, the clock) and hands you a verdict no narration can move. It costs about an afternoon, has one runtime dependency, and stays in its lane: it tells you *what happened*, never whether the code is *good* — quality stays with your tests and reviews. (The full plain-words version.)
Every number here is scored against a fact the agent can't fake (a test environment's DB state, git history). A DOS gate caught 15 "I shipped it" lies in 258 tasks across two models with zero false alarms; the same referee stopped 6 of 8 silent collisions on one shared record; quitting doomed runs at the right moment saved ~11% of fleet compute with 0 of 1,634 winners wrongly killed; and the reward-set admission label lifted acceptance precision 60% → 100% by purging poison a self-graded collector keeps. The methodology, the two money-moment figures, and the projected-vs-bet honesty gradient are in [what's proven and what's still a bet](https://github.com/anthony-chaudhary/dos-kernel/blob/master/docs/guide/why-a-referee.md#whats-proven-and-whats-still-a-bet).
This page keeps the hook, the demo, and the failure it fixes. Everything deeper lives on a focused page — find the question you arrived with and jump:
| You're asking… | Go to |
|---|---|
| *"What is this in plain words, and why should my team care? Is it real?"* | Why a referee — the plain-words story, the 20-lines-of-bash / Temporal answers, and the full proven/bet evidence |
| *"Show me it working, fast."* | Optional demo, just below — one command in a throwaway repo |
| *"I already run agents — how do I wire the verdict into my stack?"* | Wire it in — MCP, runtime hooks, the exit-code tier, fleet frameworks, and the install matrix |
| *"What's the full command / syscall surface?"* | The syscall ABI & CLI reference — every verb, the three live screens, the verdict journal |
| *"I run a fleet every day — how do I watch it, triage it, debug it?"* | Operating a fleet + Debug a stuck fleet |
| *"How do I bend it to my org without forking it?"* | Extending it — the seven axes, the docs index, the playbooks |
| *"What is actually proven, and can I re-run it?"* | For researchers — claims → invariants → reproduction |
| *"I'm an AI agent orienting in this repo."* | [AGENTS.md](https://github.com/anthony-chaudhary/dos-kernel/blob/master/AGENTS.md) — what DOS is in three lines, build/test/check, the ~5 files worth reading |
| *"What surfaces are stable and what's the deprecation window?"* | [docs/STABILITY.md](https://github.com/anthony-chaudhary/dos-kernel/blob/master/docs/STABILITY.md) — the compatibility promise, what the version number means, and what will never break |
Got a terminal? This runs the whole thing in a throwaway repo — one command scaffolds it, makes a real commit, verifies it, and cleans up after itself:
pip install dos-kernel # PyYAML is the only runtime dep
dos quickstart # → SHIPPED AUTH AUTH1 … then NOT_SHIPPED AUTH AUTH2
One SHIPPED, one NOT_SHIPPED: the first is a claim git can back, the second is a claim nothing landed for. That contrast
Only the beginning is shown; read the rest in the repo