Pluribus

Pluribus

[](https://www.npmjs.com/package/pluribus-context) [](https://www.npmjs.com/package/pluribus-context) [](https://github.com/caioribeiroclw-pixel/pluribus/actions/workflows/ci.yml) [](https://x.com/RibeiroCaioCLW) [](LICENSE)

> Privacy-safe context receipts for AI coding agents — plus audits/sync for the instruction files they actually load.

Pluribus (pluribus-context on npm, pluribus on the command line) is a CLI for agent context evidence. It helps teams answer: what instruction file, skill, MCP/tool schema, memory/RAG result, compaction, pruning step, or generated rule actually crossed an agent boundary — without logging raw prompts, source code, tool output, paths, transcripts, secrets, or customer data.

The original sync workflow is still useful: Pluribus can keep project instructions, conventions, constraints, and team context in one versioned pluribus.md source of truth, then generate native files for Claude Code, Cursor, GitHub Copilot, OpenClaw, Windsurf, Continue, Zed, and Bob. The sharper wedge is evidence: read-only audits and receipts show where context keeps fidelity, downgrades to a generic fallback, duplicates, stays deferred, hydrates, gets pruned, or rolls back after failed compaction.

It is not a persistent memory layer, retrieval system, agent orchestrator, enterprise ContextOps platform, or agent-merging framework. Think evidence for context boundaries: CLAUDE.md, .cursorrules, copilot-instructions.md, AGENTS.md, MCP Tool Search, Agent Skills, RAG/code-search, pruning, and compaction — with privacy-safe receipts instead of raw content dumps.

Pluribus sits beside context layers rather than replacing them: memory suites, Skill/plugin marketplaces, path-scoped rules engines, RAG/search tools, MCP servers, hooks, and orchestration harnesses can all inject context. Pluribus' job is to prove what crossed the agent boundary. A useful receipt should separate installed, visible, loaded, invoked, and unused_or_stale so a team can tell the difference between "this context exists somewhere" and "this context actually governed the run."

See the core workflow in 30 seconds: open the browser-only context sync demo, edit one rule, preview CLAUDE.md, AGENTS.md, or .cursorrules, and inspect the source/output hashes. It makes the boundary explicit: generation is proven; runtime load remains unknown until the client supplies evidence.

Field evidence: the public evidence ledger separates maintainer-shipped outcomes, independently reviewed contributions, and directory distribution across trace privacy, handoff continuity, skill use, runtime authority, freshness, and mutation safety. It says exactly what each result proves—and does not call it Pluribus adoption.

Reviewer shortcut: evaluating Pluribus for a list, newsletter, package roundup, or tool directory? Use the [Community Review Packet](docs/community-review-packet.md) for copy-paste directory submission fields, safety/removability notes, feedback links, and disposable 60-second smoke tests. If “receipt” language feels overloaded, start with the [Boundary Receipt Gallery](docs/boundary-receipt-gallery.html), which groups public examples by the exact boundary they prove: MCP traffic evidence, MCP tool identity, stale rule authority, instruction load safety, long-session resume state, parallel-session ownership, and memory/RAG authority. The deeper [Context-boundary receipt taxonomy](docs/context-boundary-receipt-taxonomy.md) explains the model: Pluribus is about explicit boundaries like source→rendered output, search→loaded context, transform→forwarded context, harness→model run, and agent output→durable state — not generic session summaries or memory databases. If you are comparing Pluribus with cross-harness runtimes, MCP memory servers, Claude Code Skills, Cursor/Codex workflows, durable workspaces, RAG-over-notes, or “agent OS” projects, start with [Agent runtimes vs context receipts](docs/runtime-vs-receipts.md): runtimes manage what can happen; receipts prove what context actually crossed the boundary. If you are comparing plugins, Skills registries, config-sync tools, MCP setups, or Claude→Codex worker flows, start with the [Agent surface proof chain](docs/agent-surface-proof-chain.md) to separate install diffs, sync manifests, apply ledgers, surface state, selection traces, context-boundary spans, and handoff envelopes. If Git is your agent collaboration substrate, use the [agent change manifest](docs/agent-change-manifest.md) to keep Git as the byte ledger while adding a privacy-safe sidecar for agent intent, loaded authority, checks, omissions, commit trailers, and stale-if rules. If a config doctor or migration script canonicalizes scattered agent rules into AGENTS.md, CLAUDE.md, .cursorrules, Copilot instructions, Skills, hooks, or settings, use the [config treatment receipt](docs/config-treatment-receipts.md) to prove which targets actually loaded the treated authority, which private payloads stayed out, and when the drift gate must re-run. If you only run one command for the cross-tool audit, try npx --yes pluribus-context@latest audit --json --fidelity-report to see native discovery surfaces, generic fallbacks, load evidence, duplicate-load selection evidence, manual activation requirements, effective context scope, and semantic differences. For the agent-observability wedge, start with [context-budget receipts](docs/context-budget-receipts.md): privacy-safe evidence for what MCP schemas, skills, memory, subagents, CLI help, retrieval chunks, pruning runs, or compaction summaries crossed an agent boundary. It now explicitly covers the "Tool Search fixed MCP bloat" objection: the receipt proves which lane stayed deferred, which tool was expanded, and whether schemas leaked through messages/bootstrap anyway. If you are building /hygiene, /doctor, memory cleanup, MCP lazy-loading, or rules-pruning UX, use [context hygiene receipts](docs/context-hygiene-receipts.md) and the [copyable example](examples/context-hygiene-receipts/) to audit loaded sources, candidate removals, safety negative controls, rollback, and review gates before cleanup starts. For a 60-second MCP traffic proof, run npm exec --yes --package github:caioribeiroclw-pixel/pluribus -- pluribus demo mcp-traffic-receipt --json; it validates a redacted receipt for capability agreement, tool-call status, hung calls, replay evidence, and privacy defaults without raw JSON-RPC payloads. If a package sandbox or MCP server scanner generated behavior evidence, run npm exec --yes --package github:caioribeiroclw-pixel/pluribus -- pluribus demo package-behavior-receipt --json; it checks target hash, sandbox policy, behavior counts, artifact hashes, verdict, and privacy defaults without feeding raw syscalls/env/secrets to the model. If Claude Code behavior is surprising after CLAUDE.md, output styles, Skills, hooks, subagents, plugins, or MCP changed, run pluribus demo claude-extension-source-map --json; it proves which extension layers were active and source-labeled without dumping raw prompts/schemas/secrets. If a live memory server, RAG index, or repo knowledge graph answers where/how something works before an edit, run npm exec --yes --package github:caioribeiroclw-pixel/pluribus -- pluribus demo memory-answer-receipt --json; it proves snapshot freshness, cited refs, private omissions, authority level, verification path, and stale-if rules without dumping raw memory or source files. For runtime discovery specifically, use pluribus demo tool-surface-diff --json to validate discovered → activated → withheld/blocked MCP tools without raw schemas/prompts/results. If you are coming from Claude Code, GraphRAG, or memory tooling where retrieval succeeds but the agent ignores it, try the [context attention receipt example](examples/context-attention-receipts/) to prove required context was delivered, acknowledged, and cited before edits. If MCP server catalogs are burning context before the task needs them, try the [task-scoped MCP config receipt demo](examples/task-scoped-mcp-config/) to generate a minimal --mcp-config plus a receipt for selected vs withheld servers. If a lazy MCP gateway hides hundreds of tools behind search/call meta-tools, try the [MCP tool identity map receipt](examples/mcp-tool-identity-map/) to prove which server/profile and tool-definition hash actually crossed from hidden inventory into the model-visible alias and tool call. If a Claude Code Skill or paste-cleaning CLI claims big token savings, try the [semantic anchor preservation receipt demo](examples/semantic-anchor-receipts/) to prove the cleaned paste kept headings, API signatures, version notes, and security constraints. If a long Claude Code session, compaction, or topic switch makes CLAUDE.md feel stale, try the [CLAUDE.md read receipt example](examples/claude-md-read-receipts/) to prove which index/topic files were reloaded before the next edit. If your durable CLAUDE.md / AGENTS.md rules themselves may be stale after months of repo changes, try the [stale rule authority sweep](examples/stale-rule-authority-sweep/) to require live evidence, expiry/revisit conditions, and demotion rules before an agent obeys them. If hidden Unicode, bidi marks, homoglyphs, inline expansions, or generated Skills can make a reviewed rule file differ from what the agent actually ingests, try the [instruction load-boundary receipt](examples/instruction-load-boundary-receipts/) to prove visible-text hash, agent-read hash, byte ranges, active-instruction severity, and explicit review gates before loading. If Claude Code, Codex, or an API-backed agent starts timing out, drifting on tool choice, or producing bad patch formats while the status page is unclear, try the [provider degradation canary receipt example](examples/provider-degradation-canaries/) to decide whether writes should continue, fallback, or pause. If memory/GraphRAG/handover tools return useful facts but you need to prove which facts were allowed to become authority, try the [memory provenance + authority-home receipt demo](examples/memory-provenance-authority-receipts/) and [short guide](docs/memory-provenance-authority-receipts.md). If a skill registry, leaderboard, approval gate, review, handoff, or memory answer needs a reusable claim/evidence/verdict object, use the [evidence-attestation Agent Skill](skills/evidence-attestation/) and its local checker. If you want broader context-boundary recipes as copyable skills, use the [context-receipts Agent Skill recipe](skills/context-receipts/). npm latest may lag behind the GitHub release; the review packet documents a GitHub-release smoke fallback for release-lag windows.

---

The Problem

You use Claude, Copilot, Cursor, Windsurf, Continue, Zed, Bob, ChatGPT, and whatever ships next Tuesday.

Each one has its own way of understanding your project:

• CLAUDE.md for Claude Code
• copilot-instructions.md for GitHub Copilot
• .cursorrules for Cursor
• AGENTS.md for OpenClaw
• .windsurf/rules/pluribus.md for Windsurf Cascade
• .continue/rules/pluribus.md for Continue
• .rules for Zed
• .bob/rules/pluribus.md for Bob
• .clinerules for Cline
• .roo/rules/pluribus.md for Roo Code
• .amazonq/rules/pluribus.md for Amazon Q Developer
• .junie/AGENTS.md for JetBrains Junie
• WARP.md for Warp
• GEMINI.md for Gemini CLI

You end up maintaining 5+ files that say roughly the same thing — your project's architecture, conventions, tech stack, who you are, what matters. Copy-paste across files. They drift. They rot. You forget to update one. Your AI gives you wrong answers because it's reading stale context.

This is a multiplying problem. Every new AI tool = another context file = more maintenance = more drift.

The Vision

Pluribus is a universal format for intentional context in AI-assisted development.

Write your project context once, in pluribus.md. Keep it as a single file for small projects, or compose shared team/org Markdown with # @import when the context needs to be reused.

your-project/
├── pluribus.md                  # source of truth
└── shared/
    ├── team-context.md          # optional imported conventions
    └── security-constraints.md  # optional imported guardrails

Then preview or sync:

npx --yes pluribus-context@latest sync --dry-run
npx --yes pluribus-context@latest sync

And it generates the right files for each tool:

• CLAUDE.md ← for Claude Code
• .github/copilot-instructions.md ← for Copilot
• .cursorrules ← for Cursor
• AGENTS.md ← for OpenClaw
• .windsurf/rules/pluribus.md ← for Windsurf Cascade
• .continue/rules/pluribus.md ← for Continue
• .rules ← for Zed
• .bob/rules/pluribus.md ← for Bob
• .clinerules ← for Cline
• .roo/rules/pluribus.md ← for Roo Code
• .amazonq/rules/pluribus.md ← for Amazon Q Developer
• .junie/AGENTS.md ← for JetBrains Junie
• WARP.md ← for Warp
• GEMINI.md ← for Gemini CLI

One source of truth. Zero drift.

Why .md?

• It's human-readable — you can review it, version it, PR it
• It's universal — every tool already parses markdown
• It's composable — import shared contexts across projects
• It's versionable — git diff your AI context like you diff your code
• It's simple — no YAML schemas, minimal JSON only when you opt into locked remote imports

Getting Started

Pick the safe first command

If your repo already has AI context files such as CLAUDE.md, .cursorrules, Copilot instructions, or AGENTS.md, start with the read-only audit:

npx --yes pluribus-context@latest audit

It does not write files. Without pluribus.md, it lists existing AI context surfaces so you can decide what to migrate. With pluribus.md, it reports generated files that are missing or drifted.

If you are starting from scratch, preview the source-of-truth scaffold first, then create it when it looks right:

# Preview only; does not write files:
npx --yes pluribus-context@latest init --dry-run

# Write pluribus.md when the preview looks right:
npx --yes pluribus-context@latest init

What Pluribus writes

Pluribus is intentionally narrow about filesystem changes:

• audit, validate, and sync --dry-run are read-only.
• init writes pluribus.md only. If that file already exists, it refuses to overwrite it.
• sync writes only the configured/generated AI context files such as CLAUDE.md, .cursorrules, .github/copilot-instructions.md, AGENTS.md, Windsurf/Continue rules, Zed .rules, and Bob .bob/rules/pluribus.md.
• Generated files include a Generated by Pluribus ... do not edit manually header so drift is easy to spot in review.
• Remote imports only touch pluribus.lock.json and .pluribus/cache/remote/ when you explicitly pass --update-imports.

When in doubt, run npx --yes pluribus-context@latest audit or npx --yes pluribus-context@latest sync --dry-run first.

Install, uninstall, and network behavior

# Install globally if you prefer a persistent `pluribus` command
npm install -g pluribus-context@latest
pluribus --help

# Remove the global CLI later
npm uninstall -g pluribus-context

npm latest may lag behind the latest GitHub release. If you are reviewing a GitHub release before npm latest catches up, run that release directly without a global install:

npm exec --yes --package github:caioribeiroclw-pixel/pluribus#v0.3.26 -- pluribus --version
npm exec --yes --package github:caioribeiroclw-pixel/pluribus#v0.3.26 -- pluribus help

For local development:

git clone https://github.com/caioribeiroclw-pixel/pluribus.git
cd pluribus
npm link

# Remove the local global link later
npm unlink -g pluribus-context

…

## Source & license

This open-source MCP server is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [caioribeiroclw-pixel](https://github.com/caioribeiroclw-pixel)
- **Source:** [caioribeiroclw-pixel/pluribus](https://github.com/caioribeiroclw-pixel/pluribus)
- **License:** MIT
- **Homepage:** https://caioribeiroclw-pixel.github.io/pluribus/context-sync-demo.html

Install and usage instructions live in the source repository linked above.