agent-config: unify skills and governance rules across AI tools, with a self-hosted read-only MCP endpoint

agent-config distributes a set of skills, rules, commands, guidelines and personas via npm and projects them into the native configuration of every supported AI tool, following the Agent Skills open standard; the same governance content can also be served as an MCP endpoint from your own Cloudflare Worker. It is not an agent runtime: the agent loop, LLM dispatch and tool orchestration stay with the host tool. It solves a very concrete problem — one set of skills and governance rules, without configuring each tool separately.

Who it's for

• For developers and teams who switch between multiple AI tools and want skills and governance rules to stay consistent: the content layer can be projected into the native configuration of host tools such as Claude Code, Augment, Cursor, Cline, Windsurf, Gemini CLI and Copilot — maintain once, use across tools.
• For individuals and teams who need a self-hosted MCP endpoint: governance content is served from your own Cloudflare Worker, and any MCP client — Claude Desktop, Claude Code, Cursor, Zed, Continue, hosted agents and more — reaches it over HTTP, so you don't maintain a separate copy in every client.
• Not for using it as an agent runtime: it doesn't run an agent loop, nor does it take over LLM dispatch or tool orchestration; if you want a service that executes tasks and dispatches models for you, those capabilities live in the host tool.
• Not for those expecting a turnkey local service: the built-in local stdio server requires a local checkout and is not install-and-go.
• Prerequisite: Node ≥ 18; system requirements beyond that are not given in the evidence and remain unconfirmed.

Your first attempt in 3 minutes

There is exactly one main path: the official canonical install command, plus one check of the global directories.

1. Prerequisite: Node ≥ 18 is installed on your machine.
2. Run the official canonical command in a terminal: npx @event4u/agent-config init.
3. Before running it, be clear about the side effects: init writes global directories only — ~/.event4u/agent-config/, ~/.claude/, ~/.cursor/ and so on; it does not write project files, and project scope is maintainer-only. This is a local state write, not a remote commit; the evidence does not describe how to undo or roll back, so if you are unsure about the impact, back up these directories first.
4. Success signals: once the command finishes, the global directories above contain written content, and the projected skills, rules, commands, guidelines and personas appear in the native configuration of supported tools. To check the scope first, look directly at the files in these global directories.

The server route is only a secondary note: after you deploy your own Cloudflare Worker, the governance content can be reached by clients as an MCP endpoint. The evidence confirms the capability, but gives no deploy commands or configuration snippets, so the concrete steps remain unconfirmed; this is a remote configuration action — don't treat it as a required step of the quick start. On first contact, prefer the small read-only tools (such as memory_lookup and list_*): read-only only means no write operations are performed; it doesn't mean there are no other risks, and you can't infer from it that nothing touches the network or reads local data.

Use cases

Case 1: let Claude Code and Cursor share the same set of skills and rules. Keeping two tools' configurations separate tends to drift. On a machine with Node ≥ 18, run npx @event4u/agent-config init and let it write the content layer into the global directories. Expected results within the evidence: ~/.event4u/agent-config/, ~/.claude/, ~/.cursor/ and the like get written, the content follows the Agent Skills open standard, and files inside your projects stay untouched; from then on, both tools read the same set of skills and rules from their native configuration. Per the official description, the projection targets every supported tool, not just the two used as examples here. When to take this path: when skills and rules in the two tools have evolved separately and no longer agree, and you want one set of content to be authoritative. Limitation: it only solves content distribution and won't execute any skill inside your tools for you.

Case 2: self-host a read-only MCP governance endpoint. The team wants several clients to read unified governance content over HTTP without installing anything on each machine. Serve it from your Cloudflare Worker as an MCP endpoint: the governance content is exposed as MCP prompts and resources — skills, commands, rules, guidelines, contexts — along with the read-only tools memory_lookup, chat_history_read and list_*; MCP clients such as Claude Desktop, Claude Code, Cursor, Zed, Continue and hosted agents can reach it over HTTP. Observable results: once a client connects, the governance content shows up in its prompts and resources lists, and the read-only tools above can be called. Expect this as well: the Worker does not execute the ~112 Python scripts (linters, audits, task ci, work-engine hooks); those require a local install per the Quickstart. The evidence gives no Worker deployment steps — what can be confirmed ends at the official statement that the capability exists.

Usage boundaries

• Read/write nature: the Worker side is read-only — governance content is provided as prompts and resources, and the tools are limited to small read-only ones such as memory_lookup, chat_history_read and list_*; no write tool is documented officially. init is a local write, scoped to global directories only, and never touches project repositories. Read-only tools only prove that no write operations are performed; whether they reach the network or read local data is not stated in the evidence.
• Side effects and confirmation points: init writes to ~/.event4u/agent-config/, ~/.claude/, ~/.cursor/ and more; project scope is maintainer-only, which means a normal install changes nothing in any of your project repositories. The evidence does not describe automatic undo or rollback, nor does it list the exact files written.
• Officially stated limits: the Worker does not execute the ~112 Python scripts (linters, audits, task ci, work-engine hooks) — a local install per the Quickstart is required; the built-in local stdio server is in the Glama MCP Registry for discovery only and requires a local checkout (see ADR-067).
• Route check: to distribute content into your tools, use init; to read governance content over MCP, use the Worker; to run the Python scripts, do a local install per the Quickstart and run them there.
• Still unconfirmed: the Worker's deploy commands and configuration snippets, the concrete connection configuration for each client, and the full system requirements beyond Node ≥ 18. The evidence doesn't cover these — before you start, defer to the official repository.