Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Descripción del creador (original en inglés)
Verify what agents actually shipped, arbitrate file collisions, refuse with structured reasons.
Estos tres nunca se combinan en una sola puntuación: las opiniones, las mediciones y la popularidad son cosas distintas.
Todavía no escribimos un resumen sencillo para este. Abajo están los datos que leímos del registro.
Elige la app de IA que usas y copia la configuración.
DISPATCH_WORKSPACENecesitas
¿Qué app usas?
Elige tu app arriba. La recordamos, así que la próxima vez el botón dirá “Instalar en …”.
Abre Claude Desktop → Settings → Developer → Edit Config y pega esto en claude_desktop_config.json
{
"mcpServers": {
"dos-kernel": {
"command": "uvx",
"args": [
"dos-kernel"
],
"env": {
"DISPATCH_WORKSPACE": "your-value"
}
}
}
}Ejecuta esto en tu terminal
claude mcp add dos-kernel --env DISPATCH_WORKSPACE=your-value -- uvx dos-kernelCompleta los valores vacíos antes de ejecutarlo.
Pégalo en .cursor/mcp.json de tu proyecto, o en ~/.cursor/mcp.json
{
"mcpServers": {
"dos-kernel": {
"command": "uvx",
"args": [
"dos-kernel"
],
"env": {
"DISPATCH_WORKSPACE": "your-value"
}
}
}
}Tu navegador te pide permiso para abrir la app; luego la app muestra la configuración y te pide confirmar. Los valores de las claves quedan vacíos para que los completes tú.
Pégalo en .vscode/mcp.json de tu proyecto
{
"servers": {
"dos-kernel": {
"type": "stdio",
"command": "uvx",
"args": [
"dos-kernel"
],
"env": {
"DISPATCH_WORKSPACE": "your-value"
}
}
}
}Tu navegador te pide permiso para abrir la app; luego la app muestra la configuración y te pide confirmar. Los valores de las claves quedan vacíos para que los completes tú.
Este se ejecuta en tu computadora, y ChatGPT solo puede conectarse a servidores en internet. Elige otra app.
Tu elección se guarda en una cookie en este dispositivo; no necesitas cuenta.
DISPATCH_WORKSPACE envEsta configuración se genera a partir de la ficha del creador en el registro. Si el README dice otra cosa, sigue el README.
Se ejecuta en tu computadora; la lista de herramientas aparece en tu app de IA después de instalarlo.
Revisamos información que cualquiera puede ver; no hemos leído el código. Las revisiones que no aplican no se cuentan. · Revisado el 6 nov 2026
El nombre en el registro se verificó con la cuenta de GitHub anthony-chaudhary, dueña del repo
Todavía no hemos leído este repo en GitHub
Todavía no hemos leído este repo en GitHub
Este se ejecuta en tu computadora; no hay endpoint en internet
Se ejecuta en tu computadora y usa ajustes locales en su lugar
Se ejecuta en tu computadora; solo podemos leer listas de herramientas de endpoints en internet
Comparado con todos los servidores activos de esta categoría en el registro. Las estrellas solo cuentan cuando quien lo publica es dueño del repo.
Superó 1 de 1 revisiones básicas aplicables. No hemos leído el código. Antes de agregar una clave o un token, revisa qué acceso pide el servidor y usa una clave que tenga solo los permisos que necesitas.
El registro no indica ninguna clave obligatoria, aunque algunos servidores te piden iniciar sesión la primera vez que los usas.
Se ejecuta en tu computadora. Tu app de IA lo inicia cuando hace falta, y los datos no pasan por los servidores del creador (a menos que el propio servidor llame a un servicio en línea).
El repo de GitHub cambió por última vez –, y la última versión (0.30.0) llegó al registro hace 4 meses.
Las apps compatibles con MCP, como Claude Desktop, Claude Code, Cursor y VS Code. También necesitas Python (uv) en tu computadora.
En la misma categoría: Spec Driven Development, Remote Desktop Commander, Fomu MCP
Servidores de la misma categoría hechos por otros creadores, ordenados por estrellas.
Cómo leer una tarjeta:★ Estrellas de GitHubiTres pilares: reseñas · revisiones · usoiActualizado = fecha en que se publicó la última versión en el registroi
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.
Kenya government form guides: checklists, draft letters, eCitizen, Huduma, timelines. Sample data.
Copiado tal cual del repo del creador. PopNx MCP no lo ha revisado ni lo respalda. Se quitaron HTML, imágenes y scripts. Los enlaces llevan fuera de este sitio.
### 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
Solo se muestra el principio; lee el resto en el repo