Plenec for Claude Code

Plenec is your company brain. This plugin connects Claude Code to it, so a coding session can read what the team already decided and write back what it learns.

What you can do with it

• Ask why it's built this way. Search Architecture Decision Records and knowledge items in your workspace, and get grounded, cited answers instead of guesses.
• File and resolve bugs without leaving the terminal — including the root cause, which is embedded so future similar bugs match against it.
• Track features and tasks. Look up a short key like ATR-T88, see what's waiting on you across every workspace, or get a project at a glance.
• Capture what you learned as a knowledge page. Decisions, requirements, and action items are extracted and linked to the right feature automatically.

Install

/plugin marketplace add atroo/claude-plugins
/plugin install plenec@atroo

Installing the plugin registers the Plenec MCP server for you — there is no separate claude mcp add step. Sign in once:

claude mcp login plenec

or run /mcp inside a session and pick plenec. Your browser opens, you sign in at login.atroo.de, and Claude Code stores the session. No API key or token to copy.

On a machine with no browser (SSH, a headless Linux box), add --no-browser and paste the redirect URL back at the prompt.

You need a Plenec account — see plenec.com for the product and how to get one.

Getting started

Ask Claude what workspaces you have:

Which Plenec workspaces can I see?

Then anything grounded in your team's history:

Why did we pick Neo4j for the knowledge graph?

What's waiting on me right now?

File a bug: the Safari login callback drops the session cookie.

Binding a repository to a workspace

If a repository always belongs to one workspace, bind it once and Claude stops asking:

/plenec:bind

That writes .plenec.json at the repository root:

{ "workspaceId": "2bb0e82b-...", "workspaceName": "atroo" }

Commit it and everyone who clones the repository shares the binding. From the next session on, Plenec tools are scoped to that workspace automatically.

A binding only narrows scope. Access is authorized on the server, so it cannot reach a workspace you could not already reach, and the file is read as an identifier only — nothing in it is treated as an instruction.

Pinning a workspace

If you work in one workspace almost always, you can bind this connection to it and skip the workspace question. Point the server URL at the workspace-scoped form:

{
  "mcpServers": {
    "plenec": {
      "type": "http",
      "url": "https://mcp.plenec.com/ws/<workspaceId>/mcp"
    }
  }
}

Tools then take no workspaceId argument.

Specifying what to build

Two structured documents, one level apart. A PRD says what one capability must do and why; its requirements become that feature's ratified specification, and what a plan is later measured against. A VISION says what the product those capabilities belong to is for; its outcomes become what the roadmap is judged against. A workspace usually runs one product, but it can hold several — Claude asks which one a vision is about rather than guessing.

Write a PRD for the bulk export feature.

Help me write our product vision.

Claude guides the conversation section by section, asking rather than filling gaps — and it will tell you when a measure or an outcome is missing instead of inventing a plausible one. Structure carries meaning here: each section is filed differently against the capability or the product, so an outcome buried in background never becomes something anyone is measured against. Your own headings and language are fine — they are read and understood, not matched against a list.

Open questions are recorded as blocking: a capability with unanswered ones does not pass its readiness gate. That is deliberate, and it is why a rhetorical question does not belong in that section.

Planning before you build

Ask Claude to plan a feature and it works a loop instead of guessing: it reads what is already known about the capability, pulls the engineering practices that govern the work — with their rationale, and the anti-patterns for the areas it touches — and only then drafts. You judge the approach. The agreed plan is stored against the feature and reviewed against those same practices, so gaps surface while they are still a paragraph rather than a pull request.

Plan the Safari cookie fix against our practices.

Findings come back as VIOLATED (the plan does something a practice forbids) or UNDERSPECIFIED (a practice governs this, but the plan does not say enough to tell). The second is the common one, and usually the fix is stating reasoning you already had.

Reviewing a change

Three reviewers, each answering one question, each read-only — none can write to your workspace or your files:

Run all three and get one merged report:

/plenec:review

Or name one — "check this against our ADRs", "review the auth change for security" — and Claude dispatches just that reviewer.

They are separate because the questions are. A spec review that drifts into architecture misses a requirement; a security pass diluted by plan deviations buries the one finding that matters. They overlap only at the edges: each names a finding in another's territory in a line rather than staying silent, and /plenec:review merges those into one finding with two citations instead of repeating it.

What makes them worth running over a generic review is grounding. The decision reviewer reads your accepted ADRs in full before claiming a violation, and reports what each decision rejected, not just what it chose. The security reviewer reads your recorded security practices and the anti-patterns for the domains the change touches, so it is checking your rules and not a generic checklist.

And an empty search is never reported as approval — if the brain says nothing about an area, you are told that, so you know the review was unaided before you trust it.

What's included

Five skills that teach Claude how to use the tools well:

Plus:

• /plenec:capture — review the session and write what's worth keeping to a knowledge page, after showing you what it proposes to capture.
• /plenec:review — all three reviewers in parallel, merged into one report.
• Three reviewer agents — described above, all read-only.
• /plenec:bind — bind this repository to a workspace, so you are not asked which one every session.
• Two hooks, both local, both silent when they have nothing to say, and neither sends anything anywhere: one states the repository's workspace binding at session start, the other reminds Claude to resolve an entity key like ATR-T88 properly rather than guessing its type.

Nothing in this plugin writes to your workspace on its own. Every capture, edit, and status change is something you asked for.

Other coding agents

This directory is also a portable Agent Plugins 1.0 package — plugin.json and mcp.json sit at its root alongside the Claude Code manifests. Codex, Cursor, Copilot, VS Code and Kiro load the same skills/ directory and the same Plenec server from it, unchanged.

What travels, and what does not:

The one manual step

Agent Plugins 1.0 deliberately defines no portable OAuth fields, so the pre-registered client cannot ride along in mcp.json. Without it a client tries to register its own, which Plenec's authorization server does not support — you get "Incompatible auth server: does not support dynamic client registration".

Configure these two values in your client, once:

• client id 379123512457038559 (public — PKCE, no secret)
• callback port 8765, matching the registered http://localhost:8765/callback

For Codex, in ~/.codex/config.toml (or .codex/config.toml for one project):

[mcp_servers.plenec]
url = "https://mcp.plenec.com/mcp"
auth = "oauth"
oauth.client_id = "379123512457038559"
oauth.callback_port = 8765

Other clients take the same two values in their own config format. If your client supports dynamic client registration and nothing else, it cannot connect to Plenec today.

Support

Issues and questions: https://github.com/atroo/claude-plugins/issues