From business requirements
to system design.

Endpoints are nodes.
Requirements live on edges.

Group operations by system or vendor. Each operation is a node: an API endpoint, an MCP tool, or an A2A skill. Connect one operation to another to describe the workflow.

Each edge has its own required experience and priorities. Two connections to the same vendor can have different latency, freshness, or reliability requirements.

In the workbench, connect operations using their + handles. Select an edge to edit its requirements in the inspector. Export the graph as an Open Workflow Specification document to keep it with your project.

Make QoS a business decision.

Quality of service describes the experience a connection must deliver. Keep requirements separate from known facts about a provider: “respond within 500 ms” is a requirement; “this endpoint takes 15 seconds” is a fact.

Declare caching and scheduling permissions explicitly. Plug uses the requirements and facts to evaluate designs; it does not invent missing vendor guarantees or silently relax your requirements.

Give the IDE access.
Give the agent instructions.

Plug provides an MCP server that exposes the workspace design to an agentic IDE. Its generated .plug/AGENTS.md explains how to read the spec, update it after an integration change, and preserve unknown facts.

The intended experience is persistent design context in your IDE. Today, the implementation provides MCP registration and generated agent guidance; it does not automatically install a separate SKILL.md package. Add a reference to the generated guidance in the instructions your IDE actually loads.

After building and installing the local package using the setup steps below, run these commands in the project you want the agent to work on. Replace input.json with your Plug design input or exported workflow document.

npx --no-install plug spec input.json
npx --no-install plug mcp install --ide cursor

Other supported IDE values are vscode, claude, and generic. Reload your IDE’s MCP servers after registration.

plug_get_spec

Read the current workflow, requirements, and design.

plug_update_spec

Validate a change, re-analyze it, and update the workspace bundle.

plug_analyze

Evaluate a design input or workflow.

plug_explain

Read the design reasoning, proofs, and implementation tasks.

plug_index_workspace

Draft system information from the local project for review.

The agent needs to follow the project instructions and use the tools. MCP makes the design available; it does not automatically enforce every code change.

Start with one connection.

You need Node 24 and access to the source repository. If you use nvm, nvm use selects the version declared by the project. Otherwise, install Node 24 with your usual version manager.

git clone git@github.com:plugproject/plug.git
cd plug
nvm use
npm ci
npm run dev

The workbench runs at http://localhost:3000. Add your systems, connect their operations, and set the experience on each edge. Review the proposed architecture and its assumptions before implementing it.

Use Plug in another workspace

Build and package the local CLI from the Plug checkout:

npm run build
npm pack --workspace @plugproject/plug --pack-destination /tmp

Then install the resulting tarball in your application’s workspace. Use the actual file path printed by npm pack:

npm install /absolute/path/to/plug-package.tgz
npx --no-install plug ui

The packaged local workbench defaults to http://127.0.0.1:4319. Continue with MCP registration and agent guidance to connect your IDE. Public npm distribution is not yet available.

Explain why a pattern belongs.

Plug’s knowledge base describes the problems a pattern solves, the obligations it introduces, its contraindications, and its tradeoffs. The engine composes and evaluates these patterns against each connection.

For example, a retry introduces a duplication question; a queue introduces capacity and waiting-time questions. A proposed design must close detected problems and satisfy the obligations created by its components.

Useful contributions include a concrete integration case, the facts known about the systems, the experience required, and a pattern or missing obligation that the engine should consider. The canonical contracts live in schema/draft/schema.ts in the repository.

Start from the interfaces you have.

The current intake supports manual JSON/YAML, MCP tool-list metadata, and A2A Agent Cards. Workspace indexing can draft system information from OpenAPI documents, Agent Cards, package manifests, and source markers.

Review imported or indexed information before adopting it. Interface descriptions do not necessarily specify operational latency, quotas, availability, or caching permission. Those facts may still need an author.

Deeper discovery, richer indexing, and better importers are areas for contribution. The reference package lives in packages/plug.

Make the design reviewable.

The specification is a draft. Proposed changes should make the relationship between declared facts, business requirements, chosen patterns, and proof obligations clearer.

Major behavior or contract changes use the project’s specification enhancement proposal process in seps/. A useful proposal states the problem, a concrete example, the proposed contract, alternatives, and how the behavior can be verified.

About the source repository.

The repository is github.com/plugproject/plug. GitHub currently returns 404 to visitors without access, including for its README and documentation. The guide on this site is available without that access.

If you already have repository access, sign in to the matching GitHub account or use the SSH clone command in the local setup. Otherwise, you’ll need repository access from the project owner. This site does not grant access.

Distribution licensing is still being decided. For now, collaborators with repository access can raise issues and proposals there. No public package installation or public repository availability is implied.