GitHub
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
作者提供的说明(英文原文)
Committed, machine-readable codebase context and code map that tells agents where to look.
这三项永远不会合并成一个分数:意见、测量和人气是不同的东西。
我们还没有为它写通俗的介绍。下面是我们从注册中心读取到的事实。
选择你使用的 AI 应用,然后复制设置。
你需要
你用的是哪个应用?
在上方选择你的应用。我们会记住它,下次按钮会显示“安装到 …”。
打开 Claude Desktop → Settings → Developer → Edit Config,把下面的内容粘贴到 claude_desktop_config.json
{
"mcpServers": {
"prelude": {
"command": "npx",
"args": [
"-y",
"prelude-context",
"serve"
]
}
}
}在终端中运行这条命令
claude mcp add prelude -- npx -y prelude-context serve粘贴到项目中的 .cursor/mcp.json,或 ~/.cursor/mcp.json
{
"mcpServers": {
"prelude": {
"command": "npx",
"args": [
"-y",
"prelude-context",
"serve"
]
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
粘贴到项目中的 .vscode/mcp.json
{
"servers": {
"prelude": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"prelude-context",
"serve"
]
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
这个服务器在你的电脑上运行,而 ChatGPT 只能连接互联网上的服务器。请选择其他应用。
你的选择通过 Cookie 保存在这台设备上,无需账户。
这些设置是根据作者在注册中心的条目生成的。如果 README 的写法不同,请以 README 为准。
它在你的电脑上运行;安装后,工具列表会显示在你的 AI 应用中。
我们检查的是任何人都能看到的信息;我们没有阅读代码。不适用的检查项不计入总数。 · 检查于 2026年11月7日
注册名称已通过 GitHub 账户 adjective-rob 验证,该账户拥有此仓库
我们还没有从 GitHub 读取这个仓库
我们还没有从 GitHub 读取这个仓库
它在你的电脑上运行,没有互联网端点
在你的电脑上运行,改用本地设置
它在你的电脑上运行;我们只能读取互联网端点的工具列表
与注册中心里这个分类中所有活跃的服务器比较。只有当发布者拥有该仓库时,星标数才计入。
它在 1 项适用的基础检查中通过了 1 项。我们没有阅读代码。在添加密钥或令牌之前,请先看看这个服务器要求哪些权限,并使用只具备所需权限的密钥。
注册中心没有列出必需的密钥,不过有些服务器会在首次使用时要求你登录。
它在你的电脑上运行。你的 AI 应用会在需要时启动它,数据不会经过作者的服务器(除非它自己调用在线服务)。
GitHub 仓库最后更新于–,最新版本(1.11.0)于33天前进入注册中心。
支持 MCP 的应用,例如 Claude Desktop、Claude Code、Cursor 和 VS Code。你的电脑上还需要有 Node.js。
同一分类中有:GitHub, Desktop Commander, Cloudflare MCP
同一分类中其他作者的服务器,按星标数排序。
如何看卡片:★ GitHub 星标i三大支柱:评价 · 检查 · 使用情况i更新 = 最新版本发布到注册中心的时间i
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
MCP server for terminal commands, file operations, and process management
Cloudflare MCP servers
按原文从作者的仓库复制。PopNx MCP 没有审查或背书其内容。HTML、图片和脚本已被移除。链接会离开本站。
Project memory and a code map for AI agents: where to look, why the code is the way it is, and what a change will touch.
An agent with grep can find where a word appears. It cannot find out why the code is shaped the way it is, which tests cover a file, how many other files depend on it, or what the last session learned. That knowledge isn't in the source.
Prelude keeps it in the repo. It scans the project once and writes a small set of JSON files to .context/: the stack, the architecture, the constraints, the decisions, and a code map of every module, its exports, and what imports what. You commit those files, and agents add to them as they work. Every later session starts from them, through an MCP server, a generated CLAUDE.md / AGENTS.md, or plain stdout.
No embeddings, no server to host, no network calls. Regex heuristics over TypeScript/JavaScript, Python, Go, and Rust.
cd your-project
npx prelude-context init # writes .context/
Or install it, which gives you the prelude command used in the rest of this README:
npm install -g prelude-context
prelude init
Then give it a task phrase:
prelude locate preserve manual edits during update --limit 2
1. src/core/merger.ts · src/core (Core business logic) · score 32
exports: MergeResult, MergeChange, ContextMerger, trackMapFields why: decision: Manual edits are sacred, content preserve×25, manual×31, edit×9, update×6, matches all terms impact: imported by 4 files · tests: tests/map-merge.test.ts, tests/mcp-server.test.ts, tests/merge-preserve.test.ts decisions: Manual edits are sacred
One call returns the files to read, why each was picked, what depends on them, the tests to run afterwards, and the recorded decision that constrains the change. That is real output from this repository, which keeps its own .context/ committed. Browse it to see what Prelude writes.
Requires Node.js >= 20.19.
your-project/
└── .context/ ├── project.json what the project is ├── stack.json language, runtime, frameworks, tooling ├── architecture.json type, patterns, directories, entry points, routes ├── constraints.json rules and preferences ├── decisions.json architecture decisions and their rationale ├── map.json modules, exports, import graph, hub files ├── changelog.md project timeline └── .prelude/ state: which fields were inferred, which you edited
Commit .context/. Gitignore .context/*.session.json.
prelude compact prints the whole thing as one dense line per section, sized for a system prompt (a few hundred tokens for this repo):
[project] prelude-context | The open standard for expressing and maintaining machine-readable context about a codebase
[stack] TypeScript/JavaScript Node.js >=20.19.0 | pnpm | testing: Vitest [arch] type=cli | patterns: Utility modules | entry: bin/prelude.ts | dirs: bin (Executable entry points), src/commands (Command handlers), src/core (Core business logic), src/mcp (MCP server), ... [decisions] Manual edits are sacred (accepted); Regex heuristics, not AST parsers (accepted); Schemas are the contract (accepted); ... [map] hubs: src/utils/fs.ts(25), src/runtime/context.ts(20), src/schema/index.ts(18), ... | src/core (Core business logic): state-manager.ts, infer.ts, map-scanner.ts +15 | ...
| Question | Where Prelude gets the answer |
|---|---|
| Why is this code the way it is? | decisions.json: decisions and rationale, recorded by you or by an agent with prelude_record_decision |
| What depends on this file? | map.json: the resolved import graph, importer counts, hub files |
| Which tests cover it? | map.json: the test files that import it |
| What did the last session learn about this module? | Module notes, written with prelude annotate or prelude_annotate_module and never overwritten |
| What must I not do here? | constraints.json |
| How does this repo talk to that one? | relatedProjects in project.json, served across repos in workspace mode |
prelude locate attaches the first four to every file it returns. On a freshly initialised project the decisions and notes are empty; the import graph and tests are there from the first run, and the rest accumulates as people and agents record it.
locate find files?bench/locate-bench.ts replays a repository's git history: each commit subject is a query, the files that commit changed are the answer, and the repo is checked out at the parent commit so nothing sees the change itself. The baseline is a grep for each query term over the same files, ranked by distinct terms matched. Share of queries with a correct file in the top 8:
| Repo | Source files | Ranked grep | prelude locate |
|---|---|---|---|
| cobra (Go) | 37 | 95% | 96% |
| flask (Python) | 82 | 83% | 86% |
| hono (TypeScript) | 361 | 88% | 97% |
| ripgrep (Rust) | 100 | 64% | 79% |
| typer (Python) | 629 | 76% | 74% |
| express (JavaScript) | 147 | 87% | 90% |
| Average | 82% | 87% |
The top result is correct 48% of the time, against 39% for grep. Up to 100 commits per repo. The scoring weights were chosen using these same six repositories, so treat the numbers as in-sample; run the script on your own repo to check (see CONTRIBUTING.md). File-finding is the baseline here, not the point: the table above is.
Keep them. Prelude generates both (prelude export --format claude-md, --format agents-md) and can bootstrap from one you already have (prelude init --from-claude-md). The difference is what sits underneath:
prelude diff --check exits 1 when the committed context no longer matches the code, so CI catches the drift.prelude locate turns a task phrase into a short list of files with the reason each was picked, the tests that cover it, and the decisions that apply. A prose file can't do that.prelude update refreshes the first kind and never touches the second.Prelude runs as an MCP server over stdio.
From a project that has a .context/ directory, register the server with Claude Code:
claude mcp add prelude-context -- npx -y prelude-context serve
For any other client, the server command is npx -y prelude-context serve --root /path/to/project:
{
"mcpServers": { "prelude-context": { "command": "npx", "args": ["-y", "prelude-context", "serve", "--root", "/path/to/project"] } } }
prelude mcp-config --client claude-code | cursor | codex | claude-desktop prints the exact snippet for your machine and client. The read tools are annotated read-only, so clients that honour tool annotations can run them without asking.
| Tool | What the agent gets |
|---|---|
prelude_compact | The token-budgeted overview (about 800 tokens by default), including the [map] line |
prelude_locate | The files most relevant to a task phrase, each with reasons, importer count, covering tests, applicable decisions, and notes |
prelude_map | Hubs and modules, one module in detail, or one file's exports and importers |
prelude_query | Context filtered by topic, directory scope, or type |
prelude_record_decision | Appends a decision to decisions.json so later sessions inherit it |
prelude_annotate_module | Corrects a module's purpose or adds notes in map.json; never overwritten by update |
prelude_status | Which context files exist |
Resources: prelude://context/full, prelude://context/compact, prelude://context/map, and prelude://context/{type} for a single file.
Register each codebase once, register Prelude once in your agent harness, and every session can see all of your projects: what each one is, how they relate, and where to look inside any of them.
# once per repo
cd ~/code/backend && prelude init && prelude workspace add . cd ~/code/frontend && prelude init && prelude workspace add .
prelude mcp-config --workspace --client claude-code
In workspace mode every tool takes an optional project, and three more tools appear:
| Agent call | What it gets back |
|---|---|
prelude_projects | One block per project: purpose, stack, entry points, API surface, hub files, related projects |
prelude_locate(query="billing checkout") | Searches every project when project is omitted |
prelude_link_projects(from="frontend", to="backend", relation="consumes", contract="REST /api/v1, JWT bearer") | Records the relationship in frontend's project.json |
prelude_workspace_refresh | Rebuilds the workspace index |
prelude workspace list | index | status | remove manage the registry at ~/.prelude/ (override with PRELUDE_HOME).
The GitHub Action has two modes. Guard (check: "true") runs prelude diff --check and fails the job when the committed .context/ has drifted from the code. Update (the default) runs prelude update and opens a pull request when .context/ changed. Use both: guard pull requests, update on main.
# .github/workflows/prelude.yml
name: Prelude Context on: pull_request: push: branches: [main] paths: [package.json, pyproject.toml, Cargo.toml, go.mod, "src/**"]
jobs: check: if: github.event_name == 'pull_request' runs-on: ubuntu-latest steps:
只显示了开头部分;其余内容请在仓库中阅读