Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Beschreibung vom Entwickler (englisches Original)
One list every AI tool you use can write to — scoped per project, local-first, self-hostable.
Diese drei werden nie zu einer Punktzahl zusammengefasst: Meinungen, Messungen und Beliebtheit sind verschiedene Dinge.
Für diesen Server haben wir noch keine Zusammenfassung in einfacher Sprache geschrieben. Unten stehen die Fakten, die wir aus der Registry gelesen haben.
Wähle die KI-App, die du nutzt, und kopiere die Einstellungen.
Du brauchst
Welche App nutzt du?
Wähle oben deine App. Wir merken sie uns, damit der Button beim nächsten Mal „In … installieren“ anzeigt.
Öffne Claude Desktop → Settings → Developer → Edit Config und füge dies in claude_desktop_config.json ein
{
"mcpServers": {
"docket": {
"command": "npx",
"args": [
"-y",
"@pasichdev/docket"
]
}
}
}Führe das in deinem Terminal aus
claude mcp add docket -- npx -y @pasichdev/docketIn .cursor/mcp.json in deinem Projekt oder in ~/.cursor/mcp.json einfügen
{
"mcpServers": {
"docket": {
"command": "npx",
"args": [
"-y",
"@pasichdev/docket"
]
}
}
}Dein Browser fragt, ob er die App öffnen darf, dann zeigt die App die Einstellungen und bittet dich um Bestätigung. Schlüsselwerte bleiben leer, damit du sie selbst einträgst.
In .vscode/mcp.json in deinem Projekt einfügen
{
"servers": {
"docket": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@pasichdev/docket"
]
}
}
}Dein Browser fragt, ob er die App öffnen darf, dann zeigt die App die Einstellungen und bittet dich um Bestätigung. Schlüsselwerte bleiben leer, damit du sie selbst einträgst.
Dieser Server läuft auf deinem Computer, und ChatGPT kann sich nur mit Servern im Internet verbinden. Wähle eine andere App.
Deine Auswahl bleibt in einem Cookie auf diesem Gerät; kein Konto nötig.
Diese Einstellungen werden aus dem Registry-Eintrag des Entwicklers erzeugt. Wenn in der README etwas anderes steht, folge der README.
Läuft auf deinem Computer; die Tool-Liste erscheint nach der Installation in deiner KI-App.
Wir prüfen Informationen, die jeder sehen kann; den Code haben wir nicht gelesen. Checks, die nicht zutreffen, werden nicht mitgezählt. · Geprüft am 6. Nov. 2026
Der Registry-Name wurde mit dem GitHub-Konto pasichDev bestätigt, dem das Repo gehört
Dieses Repo haben wir noch nicht von GitHub gelesen
Dieses Repo haben wir noch nicht von GitHub gelesen
Dieser Server läuft auf deinem Computer; es gibt keinen Endpunkt im Internet
Läuft auf deinem Computer und nutzt stattdessen lokale Einstellungen
Läuft auf deinem Computer; Tool-Listen können wir nur von Endpunkten im Internet lesen
Verglichen mit allen aktiven Servern dieser Kategorie in der Registry. Sterne zählen nur, wenn dem Herausgeber das Repo gehört.
Er hat 1 von 1 zutreffenden Basischecks bestanden. Den Code haben wir nicht gelesen. Bevor du einen Schlüssel oder Token hinzufügst, sieh nach, welche Zugriffe der Server verlangt, und nutze einen Schlüssel, der nur die Berechtigungen hat, die du brauchst.
Die Registry nennt keinen erforderlichen Schlüssel, manche Server bitten dich aber bei der ersten Nutzung, dich anzumelden.
Er läuft auf deinem Computer. Deine KI-App startet ihn bei Bedarf, und die Daten laufen nicht über die Server des Entwicklers (außer der Server ruft selbst einen Onlinedienst auf).
Das GitHub-Repo wurde zuletzt – geändert, und die neueste Version (3.1.0) kam vor 33 Tagen in die Registry.
Apps, die MCP unterstützen, etwa Claude Desktop, Claude Code, Cursor und VS Code. Außerdem brauchst du Node.js auf deinem Computer.
In derselben Kategorie: Spec Driven Development, Remote Desktop Commander, Fomu MCP
Server derselben Kategorie von anderen Entwicklern, sortiert nach Sternen.
So liest du eine Karte:★ GitHub-SterneiDrei Säulen: Bewertungen · Checks · NutzungiAktualisiert = neueste Version in der Registry veröffentlichti
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.
Unverändert aus dem Repo des Entwicklers übernommen. PopNx MCP hat den Inhalt weder geprüft noch empfiehlt es ihn. HTML, Bilder und Skripte wurden entfernt. Links führen von dieser Website weg.
One list every AI tool you use can write to — Claude Code, Codex, Cursor, Warp — across every project, before the work is worth a ticket. Local-first, self-hostable, no SaaS account.
Watch the one-minute demo · download the mp4
You need: Node.js 18+ and at least one MCP host — Claude Code, Codex, Cursor, Windsurf, Claude Desktop, Zed or Warp.
npx -y @pasichdev/docket setup
That configures every host it finds on this machine and ends by telling you which ones. Then restart your agent and ask it *"add a todo: buy milk"* — it shows up at http://localhost:8787, a dashboard that started by itself the moment the agent connected.
Only want Claude Code, and nothing written anywhere else? claude mcp add docket -- npx -y @pasichdev/docket does just that part. Other hosts: Supported hosts.
Optional: see what's open in a project when a session starts
npm install -g @pasichdev/docket # the hook runs a command, so it needs one on PATH
docket hook install # then: docket hook doctor
hook install works without the global install too — it pins the command to this exact copy of docket and tells you it did — but the short form survives moving or reinstalling, and npx leaves nothing on PATH.
A thought that shows up mid-session is worth capturing but not worth the ceremony: a Notion template, a GitLab issue format, a ticket id you have to invent. So today it evaporates. Docket is the layer underneath all of that — work lands here at the speed an agent can type, from any tool, in any project, and graduates to Notion/GitLab/Obsidian when it's earned it.
Nobody else occupies this space, and it isn't an accident: Anthropic will not integrate Claude Code with Cursor, and Cursor will not integrate with Codex. Every vendor optimises its own closed loop. The space *between* the tools is structurally nobody's.
Docket files every item under the project it was captured in, automatically — resolved from the git remote of wherever the agent is running. You never type it, and no agent has to remember to.
~/work/backend claude-code, codex ─┐
~/side/tracker claude-code ─┼──▶ docket ──▶ one list, three scopes ~/side/notes codex, warp ─┘
todo_list in ~/work/backend shows that project's open items, not all three projects' — compact, one line each.Using the git *remote* rather than the path means the same repo cloned to ~/src/backend on a laptop and /work/backend on a desktop is one workspace — which matters precisely because sync exists. Full resolution order and the .docket.json override: [`docs/workspaces.md`](docs/workspaces.md).
Regenerate these with node docs/assets/demo-seed.mjs — it builds the workspace they show, so they stay a picture of the real dashboard rather than a staged one.
Read this before you upgrade if you have existing items.
3.0 migrates your store from data format v7 to v8 on first run, automatically. The migration itself is safe and is not the risk. Downgrading afterwards is.
docket 2.3.1 writes the store from its own v7 shape: it has never heard of the fields v8 adds, so its very first write after a reinstall silently strips them from every item. Nothing errors, and a later re-upgrade hands out fresh sequence numbers that no longer mean what your paired devices think they mean. 2.3.1 is published and cannot be patched, so 3.0 defends the only way it can — by keeping a copy of your pre-migration store:
~/.docket/todos.v7-pre-upgrade.enc
It is written once, before the first v8 write, and never overwritten. The upgrade prints its path on the run that creates it.
To go back to 2.x, restore it first:
docket restore --from-v7 # puts the v7 store back; moves the v8 one aside
npm install -g @pasichdev/docket@2.3.1
In that order. restore --from-v7 deletes nothing — your v8 store is renamed aside, so you can come forward again later.
If you would rather have a portable copy as well, docket backup ./pre-v3.backup before upgrading gives you one that includes your identity and paired peers.
Docket is deliberately not where work lives forever. It's where work lands *first*, before anyone knows whether it deserves a ticket. Most of it doesn't and gets closed by hand; the rest graduates.
sourceUrl is the bridge in both directions. Set it whenever an item maps to something with a URL — a GitLab issue, a Notion page, an Obsidian share link, a Slack thread, a GitHub PR — and the card carries a clickable link straight back to it.
*Why not just use GitHub Issues?* Because an issue costs a title you have to
phrase for an audience, a repo you have to pick, and labels you have to
maintain — and because your Cursor session can't write one for you while
you're mid-thought in a different project. Docket costs one sentence, from
whichever tool you already have open. When the item turns out to matter, it
becomes an issue, and
sourceUrlremembers where it went.
Any MCP host works — the tools are identical everywhere:
{
"mcpServers": { "docket": { "command": "npx", "args": ["-y", "@pasichdev/docket"] } } }
| Host | Config file |
|---|---|
| Claude Code | claude mcp add docket -- npx -y @pasichdev/docket |
| Claude Desktop | ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) / %APPDATA%\Claude\claude_desktop_config.json (Windows) |
| Cursor | .cursor/mcp.json or Global MCP settings |
| Windsurf | ~/.codeium/windsurf/mcp_config.json |
| Codex | ~/.codex/config.toml (mcp_servers) |
| Zed | ~/.config/zed/settings.json — uses context_servers, see below |
Zed's config shape is slightly different
{
"context_servers": { "docket": { "command": { "env": {}, "path": "npx", "args": ["-y", "@pasichdev/docket"] } } } }
</details>
Claude Code additionally gets a `SessionStart` hook, and only that one:
docket hook install # writes .claude/settings.json (--global for user-wide)
docket hook doctor # proves it fires, and reports measured latency docket hook uninstall # removes only the entries docket owns
When a session starts it injects the items open in that project — compact, at most 7, under 120 tokens. Nothing at all when the project has nothing open. Its whole job is continuity: you come back to a terminal and the thread is already there.
Don't want it? export DOCKET_HOOKS=off disables it immediately, without editing any config or uninstalling anything. docket hook doctor measures the real round trip and says so if it is slow enough to notice.
It fails open, always. Server not running, request timed out, malformed response, DOCKET_HOOKS=off — every one of those exits 0 and prints nothing. A tool that degrades your session when the tool itself is broken gets uninstalled, at which point it helps nobody. docket hook doctor runs the configured command for real and reports what a session would actually see, so a hook that never fires is visible rather than merely silent.
No PreToolUse, no blocking, no other hosts — the hook's only job in this release is continuity, not enforcement.
The tools work everywhere; the *guidance* ships as a Claude Code plugin. For any other agent, copy skills/docket/SKILL.md (everything below the --- frontmatter) into whichever file your agent reads — AGENTS.md for Codex, .cursor/rules/docket.mdc for Cursor, .windsurfrules for Windsurf, CLAUDE.md for Claude Desktop, or Warp's custom-instructions setting.
/plugin marketplace add pasichDev/docket
/plugin install docket@docket
| Tool | Description |
|---|---|
todo_add(title, description?, list?, category?, priority?, dueDate?, sourceUrl?, workspace?) | Capture an item. Filed under the current project automatically. |
todo_list(filter?, list?, category?, agent?, session?, inProgress?, workspace?, verbose?, limit?, offset?) | Scoped to the current project and compact by default. workspace:"*" for everything. |
todo_edit(id, ...) | Edit any subset of fields by id. Pass "" to clear an optional field. |
todo_claim(id) / todo_release(id) | Mark an item in progress, or drop the claim. Auto-expires after 15 minutes. |
todo_complete(id) | Mark done (also clears any claim). |
todo_history(id) | Full change log for one item. |
todo_delete(id) | Permanently remove an item. |
todo_version() / todo_check_update() | Data-format version; read-only npm version check. |
digest_publish(title, summary, sections?, metrics?, highlights?, sources?, windowFrom?, windowTo?) | Save a digest an agent compiled from your GitLab/GitHub/Notion/git — see Digests. |
digest_list(limit?) / digest_get(id) / digest_delete(id) | Recent digests, one in full, remove one (everywhere it synced). |
digest_take(item) | Hand item 7 (or D-7K2F9A/7) to the calling agent: its brief, plus a docket task claimed in its name. |
digest_seen() | Items the user marked seen, so the next digest leaves them out. |
Full field and workflow reference: skills/docket/SKILL.md.
Ask your agent *"make a digest"* (or *"зроби дайджест"*). The docket:digest skill reads your merge requests, pull requests, Notion tickets, local commits and docket items, checks every status at the source, and publishes the result — which becomes the dashboard's home page: what needs you, what shipped, what is in review, what is stuck, each item linked back to where it lives and one click away from becoming a task.
Docket never holds a GitLab, GitHub or Notion credential: the agent reads them with the CLIs and MCP servers it already has, and Docket only keeps what it wrote — on this machine in L
Nur der Anfang wird gezeigt; den Rest findest du im Repo