Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
作者提供的说明(英文原文)
Context exoskeleton for AI development: reduce token usage and context occupancy.
这三项永远不会合并成一个分数:意见、测量和人气是不同的东西。
我们还没有为它写通俗的介绍。下面是我们从注册中心读取到的事实。
选择你使用的 AI 应用,然后复制设置。
CONTEXTOS_PROJECT_ROOT你需要
你用的是哪个应用?
在上方选择你的应用。我们会记住它,下次按钮会显示“安装到 …”。
打开 Claude Desktop → Settings → Developer → Edit Config,把下面的内容粘贴到 claude_desktop_config.json
{
"mcpServers": {
"contextos": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"CONTEXTOS_PROJECT_ROOT",
"ghcr.io/yubinbin32-ops/contextos:3.0.3"
],
"env": {
"CONTEXTOS_PROJECT_ROOT": "your-value"
}
}
}
}在终端中运行这条命令
claude mcp add contextos --env CONTEXTOS_PROJECT_ROOT=your-value -- docker run -i --rm -e CONTEXTOS_PROJECT_ROOT ghcr.io/yubinbin32-ops/contextos:3.0.3运行前请先填写空着的值。
粘贴到项目中的 .cursor/mcp.json,或 ~/.cursor/mcp.json
{
"mcpServers": {
"contextos": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"CONTEXTOS_PROJECT_ROOT",
"ghcr.io/yubinbin32-ops/contextos:3.0.3"
],
"env": {
"CONTEXTOS_PROJECT_ROOT": "your-value"
}
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
粘贴到项目中的 .vscode/mcp.json
{
"servers": {
"contextos": {
"type": "stdio",
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"CONTEXTOS_PROJECT_ROOT",
"ghcr.io/yubinbin32-ops/contextos:3.0.3"
],
"env": {
"CONTEXTOS_PROJECT_ROOT": "your-value"
}
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
这个服务器在你的电脑上运行,而 ChatGPT 只能连接互联网上的服务器。请选择其他应用。
你的选择通过 Cookie 保存在这台设备上,无需账户。
CONTEXTOS_PROJECT_ROOT env这些设置是根据作者在注册中心的条目生成的。如果 README 的写法不同,请以 README 为准。
它在你的电脑上运行;安装后,工具列表会显示在你的 AI 应用中。
我们检查的是任何人都能看到的信息;我们没有阅读代码。不适用的检查项不计入总数。 · 检查于 2026年11月7日
注册名称已通过 GitHub 账户 yubinbin32-ops 验证,该账户拥有此仓库
我们还没有从 GitHub 读取这个仓库
我们还没有从 GitHub 读取这个仓库
它在你的电脑上运行,没有互联网端点
在你的电脑上运行,改用本地设置
它在你的电脑上运行;我们只能读取互联网端点的工具列表
与注册中心里这个分类中所有活跃的服务器比较。只有当发布者拥有该仓库时,星标数才计入。
它在 1 项适用的基础检查中通过了 1 项。我们没有阅读代码。在添加密钥或令牌之前,请先看看这个服务器要求哪些权限,并使用只具备所需权限的密钥。
注册中心没有列出必需的密钥,不过有些服务器会在首次使用时要求你登录。
它在你的电脑上运行。你的 AI 应用会在需要时启动它,数据不会经过作者的服务器(除非它自己调用在线服务)。
GitHub 仓库最后更新于–,最新版本(3.0.3)于30天前进入注册中心。
支持 MCP 的应用,例如 Claude Desktop、Claude Code、Cursor 和 VS Code。你的电脑上还需要有 Docker。
同一分类中有:Spec Driven Development, Remote Desktop Commander, Zendesk
同一分类中其他作者的服务器,按星标数排序。
如何看卡片:★ GitHub 星标i三大支柱:评价 · 检查 · 使用情况i更新 = 最新版本发布到注册中心的时间i
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.
Zendesk MCP Pack — tickets, users, organizations via OAuth.
按原文从作者的仓库复制。PopNx MCP 没有审查或背书其内容。HTML、图片和脚本已被移除。链接会离开本站。
ContextOS The context exoskeleton for AI development. Optimize the full development lifecycle. Reduce repeated token use and keep context focused.
Local MCP runtime · Precise evidence · Persistent receipts · Live architecture
中文 · Install with AI · Measured results · Desktop App
ContextOS is a local development runtime between an AI coding agent and your repository. It keeps source evidence, command logs, plans, architecture, and verification receipts outside the main conversation, then returns the pieces needed for the next decision.
OS supports the entire AI development lifecycle: understand the project, plan, inspect evidence, execute, implement, verify, review, and resume. Precise reads, reusable commands, pipelines, Blocks, Chains, persistent plans, Micro, and CLI all serve the same purpose: reduce unnecessary token consumption and context occupancy while keeping development grounded in inspectable project state.
Your existing coding assistant stays in charge. OS supplies the execution and memory layer beneath it, including bounded API Micro assistance and isolated CLI implementation when a task benefits from delegation.
In a recorded real development task, the full OS + Micro + CLI workflow reduced peak main-thread context by 63.8% and main-thread cumulative raw tokens by 77.4% compared with native tools. See the task, comparison, and limits below.
A small question often triggers a large file read. A failed test fills the conversation with logs. The agent revisits the same code, repeats a command, and spends its attention reconstructing decisions made earlier. Multi-file implementation then shares the same context window as planning and review.
The result is familiar: a crowded conversation, repeated explanations, uncertain project state, and less room for the next useful decision. A larger context window postpones the problem; development needs a way to carry this work across tools and sessions.
You → Main agent: plan, scope, architecture, review
│ └─ ContextOS: evidence, commands, changes, persistent state ├─ API Micro: bounded discovery, summaries, small checks ├─ CLI worker: isolated implementation → report → integration └─ Desktop App: architecture, plans, checkpoints, settings
Evidence and logs are saved locally. Workers read task evidence in their own contexts and return compact reports. Changes pass through OS so file ownership, verification, and the project graph stay connected. A fresh session can recover the plan and receipts instead of reconstructing the entire transcript.
| Capability | How it works | What it achieves |
|---|---|---|
| Evidence · `ask` | Inspect exact paths, line ranges, and AST symbols; recover earlier evidence by result ID and check source versions. | Read the relevant implementation and reuse valid evidence instead of repeatedly loading whole files. |
| Commands · `command` | Execute once, persist stdout/stderr and exit status, then retrieve a focused section by command ID. | Keep build noise outside the main context and recover the useful failure without rerunning the process. |
| Batches · `pipeline` | Combine known steps in serial or parallel execution, with per-step results and continuation. | Reduce tool round trips; group independent reads and checks in one call. |
| Architecture · Block | Bind curated source files to architecture units with boundaries, state, and verification evidence. | Make ownership visible and keep implementation changes connected to the architecture. |
| Architecture · Chain | Connect Blocks into project paths and record their relationships and progress. | See which capabilities depend on each other and follow a feature across module boundaries. |
| Changes · `change` / `integrate` | Apply scoped changes through OS or merge a worker's isolated diff, with verification receipts. | Review actual changes and keep architecture state current during implementation. |
| Small assistant · `micro` | A configured API model performs bounded retrieval, summarization, diagnosis, or a small edit and returns a compact report. | Move routine tool loops into a lower-cost assistant context; keep the main agent available for judgement. |
| Implementation · `agent` | A configured CLI adapter runs a task in an isolated workspace, supports background collection, and returns changes, checks, and blockers. | Move complex implementation out of the main conversation and integrate a reviewable result. |
| Continuity · plans, tasks, sessions | Persist intent, progress, rules, decisions, and receipts in the project's OS state. | Resume real project work across conversations and inspect progress in the App. |
Micro and CLI help when the task contract is clear. A small deterministic read can use OS directly; a broad implementation belongs to a CLI worker. Delegation has overhead, so OS makes its execution and results inspectable.
The recorded comparison started from commit 0dd6431. Fresh host conversations and isolated worktrees received the same real feature: plan dependency add/remove/list, persistence, validation of unknown targets, duplicates, self-reference and cycles, MCP routing, and tests across domain, application, storage, and MCP layers. Historical measurement record.
| Workflow | Peak main-thread context | Reduction vs native | Main-thread raw tokens | Tests passed |
|---|---|---|---|---|
| Native tools | 234,174 | baseline | 8,016,375 | 778 / 778 |
| OS + API Micro | 145,694 | 37.8% | 4,993,135 | 778 / 778 |
| OS + API Micro + CLI | 84,681 | 63.8% | 1,809,566 | 781 / 781 |
What “60% less context” means here: peak input to a main-agent request fell from 234,174 to 84,681 tokens. It describes this measured task, rather than a promise for every repository or the combined tokens of every worker.
Full token usage, specified equivalent USD costs, and the OS-only control
Raw tokens are cumulative input plus output; peak context is the largest single main-agent input. Cached input is included in input, so uncached = input − cached. Reasoning tokens are included in output and are not counted or charged twice.
The specified comparison uses equivalent tokens = main raw + (Micro raw + CLI raw) / 7:
| Arm / workflow | Main raw | Micro raw | CLI raw | Observed total raw | Equivalent tokens | Reduction vs native |
|---|---|---|---|---|---|---|
| A · Native | 8,016,375 | 0 | 0 | 8,016,375 | 8,016,375 | baseline |
| B · OS only, no assistant | 6,119,582 | 0 | 0 | 6,119,582 | 6,119,582 | 23.7% |
| C · OS + Micro | 4,993,135 | 734,551 | 0 | 5,727,686 | 5,098,070.9 | 36.4% |
| D · OS + Micro + CLI | 1,809,566 | 3,258,709† | 4,393,118 | 9,461,393† | 2,902,684.1† | 63.8%† |
For USD, the user-specified comparison rates per million tokens are $2 for uncached input, $0.10 for cached input, and $10 for output:
base USD = (uncached input × 2 + cached input × 0.1 + output × 10) / 1,000,000
equivalent USD = main base USD + (Micro base USD + CLI base USD) / 7
| Arm | Role | Input | Cached input | Uncached input | Output | Base USD | Divisor | Equivalent USD |
|---|---|---|---|---|---|---|---|---|
| A | Main | 7,971,486 | 7,773,056 | 198,430 | 44,889 | $1.6230556 | 1 | $1.6230556 |
| B | Main | 6,073,014 | 5,945,216 | 127,798 | 46,568 | $1.3157976 | 1 | $1.3157976 |
| C | Main | 4,952,753 | 4,710,016 | 242,737 | 40,382 | $1.3602956 | 1 | $1.3602956 |
| C | Micro | 720,163 | 636,800 | 83,363 | 14,388 | $0.3742860 | 7 | $0.053469428571 |
| D | Main | 1,788,852 | 1,746,560 | 42,292 | 20,714 | $0.4663800 | 1 | $0.4663800 |
| D | Micro | 3,211,208† | 3,007,232† | 203,976† | 47,501† | $1.1836852† | 7 | $0.169097885714† |
| D | CLI | 4,355,283 | 4,214,016 | 141,267 | 37,835 | $1.0822856 | 7 | $0.154612228571 |
| Workflow | Total equivalent USD | Reduction vs native |
|---|---|---|
| Native | $1.623055600000 | baseline |
| OS only | $1.315797600000 | 18.9% |
| OS + Micro | $1.413765028571 | 12.9% |
| OS + Micro + CLI | $0.790090114286† | 51.3%† |
These are equivalent consumption and costs under the specified model, not actual provider invoices or verified provider rates. The assistant divisor of 7 is a chosen comparison assumption. All main sessions reported the deepseek-v4.1-flash alias with max reasoning effort and a custom provider; Micro C/D retained the same session lastModel, and D CLI reported the same alias/custom provider. This does not independently verify the underlying backend model.
Main usage is deduplicated by provider response ID and matches terminal cumulative totals. C Micro has 2 receipts and provider usage for all 26/26 started requests. D CLI has 51 unique cumulative states whose last-usage sum matches its terminal total. † D Micro has 5 receipts, 129 started requests and 128 usage-bearing responses. One continuation timeout request has unknown usage. D totals and the 51.3% cost reduction are observed subtotals; the missing request is not assigned zero. Original Micro reasoning fields are unavailable and remain unknown.
The full workflow used more observed total raw tokens than native tools while reducing peak main context. OS-only reached 184,507 peak tokens (−21.2%) and lower equivalent USD than OS + Micro in this run. This is one feature's historical single-run comparison; results vary with task, model, caching and delegation.
Inspect the frozen evidence and methodology, original usage fields and coverage, role costs CSV, and four-arm totals CSV. Recompute and check the published file hashes with:
python3 docs/benchmarks/plan-dependencies/recalculate.py --check
The desktop App projects the same OS state that agents use: Blocks, Chains, plans, checkpoints, rules, and knowledge. Its white canvas, restrained color, and precise connections make a large project readable.
Read the whole system at a glance. Follow a Chain through its Blocks, inspect the selected capability, and see implementation and verification progress alongside the graph.
Trace a feature and inspect its evidence
Follow impact across modules. A highlighted Chain connects integration, packaging, and verification work.
![A passed checkpoint with its receipt r
只显示了开头部分;其余内容请在仓库中阅读