Skip to main content
PM is distributed via the cfdude-plugins marketplace and requires no npm install — the engine is zero-dependency by hard rule. The whole engine (scripts/conductor.mjs plus scripts/lib/*.mjs) is ~12,000 lines of Node 18+ built-ins, so there is nothing to install beyond the plugin itself. Add the marketplace, install the plugin, and you’re ready to initialize your first project.

Prerequisites

Node 18+ is required to run the conductor engine. If you’re already using OpenSpec or Superpowers, Node 18+ is almost certainly present. Claude Code is the only supported platform today — Codex, Gemini CLI, and other platforms are on the roadmap.

Installation steps

1

Add the cfdude-plugins marketplace

Register the cfdude-plugins marketplace with Claude Code so PM is discoverable:
2

Install PM

Install the pm plugin from the marketplace you just added:
3

Reload plugins

Reload the Claude Code plugin runtime so the new plugin and its hooks are active:
4

Initialize PM in your project

Navigate to your project directory and run the init command. This scaffolds the conductor state, registers any existing OpenSpec proposals and Superpowers plans as epics, and writes the managed rules block into CLAUDE.md:
See the Quick Start guide for a full walk-through of what /pm:init creates and the triage flow that follows.

Companion plugins (optional)

PM works completely standalone — install it, run /pm:init, and you immediately have cross-epic priority ordering, an explicit detour stack, and the reconcile gate with no other plugin required. That said, PM was designed to sit above three companions, and each one adds a distinct layer that PM deliberately doesn’t own itself.

OpenSpec

Spec-driven proposal workflow. OpenSpec owns the proposal.md / design.md / tasks.md artifacts and the two-gate review process. PM tracks the epic; OpenSpec owns what gets built and its durable spec record.

Superpowers

Execution discipline. Superpowers drives brainstorming, TDD, subagent-driven development, and code review. PM tracks when and in what order an epic gets built; Superpowers drives how well.

Honcho

Durable memory across sessions and repos. PM’s detour stack is the live working set for one project; Honcho is where a PUSH/POP memory line goes so the relationship between projects — and between sessions — survives a compaction, a new machine, or a week away. See docs.honcho.dev for setup.

PM (standalone)

No companions required. PM installs and initializes on its own. Each companion adds a layer PM intentionally doesn’t own — but skipping them loses nothing from PM’s core: priority ordering, the detour stack, and the reconcile gate all work without them.

Upgrading

When PM releases a new version, the SessionStart briefing will tell you that a reload and upgrade are needed. The process is always the same two steps:
/pm:upgrade refreshes the CLAUDE.md rules block, runs any pending state migrations, re-renders PROJECT.md, and stamps the new pmVersion onto .conductor/state.json. It is idempotent — safe to run more than once.
Always run /reload-plugins before /pm:upgrade whenever you’ve updated the plugin itself (not just a project init). Running /pm:upgrade against a stale plugin cache can apply the wrong migration. The SessionStart briefing explicitly tells you when a reload is needed — watch for it at the start of your session.

Contributing to PM itself

If you are using PM on your own projects, there is nothing in this section for you. Everything above is the complete setup. This one is for people who want to work on PM’s own source. PM’s repository is managed by the plugin it ships — PM dogfoods itself — and that creates exactly one problem you have to solve before your first commit. Every hook and slash command PM ships invokes the engine through CLAUDE_PLUGIN_ROOT, which resolves to the installed plugin. When the project you are working in is PM, that engine is behind your working tree, and its PostToolUse hook then rewrites the tracked PROJECT.md using an engine that predates your change, on every commit. Export the opt-in, naming your checkout, in whatever file your shell reads:
It has to live outside the repository, and that is the point rather than an oversight. A plugin’s reach ends at the project it is invoked in — it cannot write your shell profile. That boundary is exactly what makes the value trustworthy: it names one checkout and is compared by real path, so authorization comes from your environment, which a repository cannot reach. A bare =1 would authorize the handoff in every project that shell ever opens; don’t substitute one.
Full explanation and a verification command are in CONTRIBUTING.md.