# PM CLI > What Stefan Preu's open-source PM CLI is, why he treats project management as a context problem, how agents use it, its design trade-offs and its current direction. > status: draft-owner-review · updated: 2026-10-20 · source: https://bot.unbrained.dev/knowledge/pm-cli PM CLI is Stefan Preu's main open-source project: project management for people and coding agents, built on the idea that project management is a context problem. ## What PM CLI is PM CLI is an open-source, MIT-licensed command-line tool and SDK for project management by people and coding agents. It is published on npm as @unbrained/pm-cli (install with `npm install -g @unbrained/pm-cli`; the command is `pm`). - Source: https://github.com/unbraind/pm-cli - Documentation and package list: https://pm-cli.unbrained.dev - Case study: https://preu.at/work/pm-cli Stefan started PM CLI in February 2026; the first commit is dated 17 February 2026. He is its designer and only human maintainer. Coding agents do much of the implementation and are credited as co-authors in the commit history. ## Project management as a context problem Agents start each session without memory of the last one. What usually survives is a task list: titles, maybe a status. A title does not say why the work exists, what was decided or ruled out, or how anyone will know it is done, so a fresh session re-derives it, guesses, or asks someone who may not remember. PM CLI treats goals, items with acceptance criteria, decisions, typed relationships, evidence and history as a vocabulary that people and agents can combine. The aim is that useful context survives handoffs and fresh sessions, and that anyone can see why a decision was made. ## How agents use PM CLI Agents work with PM CLI through ordinary commands: reading context, searching, claiming an item, updating its status, adding comments, linking files, docs and tests, and recording evidence. Output is compact and machine-readable, in TOON or JSON. Instead of loading everything, an agent asks for the slice of context it needs within a token budget and is told what was left out and how to get it (an "omission receipt"). The budget is PM CLI's own estimate, not a specific model's tokenizer count. Exact flags come from the installed version itself via `pm --help --json`, so agents read the contract of the version they actually run. ## Story one: continuity across fresh sessions The first PM CLI story is about continuity. In one session, planning records a goal, decisions and tasks with acceptance criteria as structured PM items. A second, cold session that shares nothing but the repository can then pick up the thread without the person repeating the goals. The preu.at case study shows this with a reproducible script on a synthetic project: https://preu.at/work/pm-cli. That demonstration is one synthetic project, one machine and one run. It shows recorded context being returned to a cold session; it does not measure faster or better work. ## Story two: a human overview of rapid agent work The second PM CLI story is different. When agents generate code and output faster than a person can follow, the problem is comprehension and drift, not lost context between sessions. Structured PM items with goals, decisions, status and evidence can give a person a more manageable review surface than all the generated code and transcripts, while agents manage their own context. Stefan keeps the two stories separate. Neither replaces code inspection or proves that the work is correct. ## Design decisions and trade-offs The case study at https://preu.at/work/pm-cli names four decisions: - Plain files in the repository rather than a server: context travels with branches and pull requests and is reviewed like code. The cost is care with many writers (a journal, a writer lock and an append-only history replayed with hash checks). - Context outside any one harness: the same record is reachable from the command line, over MCP, in ChatGPT and in the browser. The cost is that an agent has to ask, and the record is only as good as what gets written down. - A small vocabulary, extended from outside: new behavior goes into configuration, the SDK and separate extensions. The core is still more complex than Stefan would like. - Context on request, within a budget, with an omission receipt. ## Current direction: optional Git and other backends Earlier descriptions, including some of Stefan's own portfolio texts and pages, call PM CLI "git-native". His later, explicit direction is that PM CLI should be fully usable without a Git repository and that the PM SDK should support other storage backends and databases. He credits the file-based structure with establishing a strong foundation, so files are not being abandoned. This is a stated direction, not a claim that backend independence has fully shipped. Check the current documentation for what a given release supports. ## Ways to reach the same record Besides the CLI and SDK, hosted PM surfaces reach the same project record: - https://pm-web.unbrained.dev: browse, search and manage pm projects in the browser - https://pm-mcp.unbrained.dev: connect agents and IDEs over remote MCP with OAuth - https://pm-gpt.unbrained.dev: work with pm projects in ChatGPT and Codex - https://pm-search.unbrained.dev: find decisions, tasks and fixes in public repositories' pm items, with commit-pinned links Around the core there are separately published extensions, importers, starters and an independent Rust implementation, so users install only what they need. See the projects page. ## PM CLI is built with PM CLI PM CLI's own development is tracked in PM CLI. On 19 October 2026 its public repository held 3,001 items, 69 of them decisions. The agents working on it hit the same friction as any user, and that friction becomes new items. In May 2026 Stefan cut the repository's agent guide from 487 to 108 lines by moving exact instructions into the tool itself. These counts describe one repository at one commit; they show activity, not quality. ## A reported feedback loop Stefan describes a feedback loop around the PM ecosystem. A separate operator agent orchestrates agents that work on PM packages, using PM CLI and its SDK while they work. Issues, observations and simplification ideas flow upstream as GitHub issues; core planning agents deduplicate them and link them to related PM items. The operator deliberately does not write to the core repository itself. Stefan calls this loop self-correcting, but says his visibility largely comes from the agents' own reports. Successful autonomous repair has not been independently demonstrated. ## Where the idea came from Stefan says Steve Yegge's Beads inspired PM CLI, and his own frustrations shaped its direction. The PM ecosystem includes a Beads importer. This is not a verified comparison with current versions of either tool. ## Trying PM CLI in your own project Stefan's suggestion: first decide whether the project is new or already established. Then ask your agent how PM CLI could fit your existing workflow and tools, possibly with earlier sessions as context, and try that fit in practice instead of copying someone else's setup. Useful feedback is what helped, what did not, and where you or the agent hit friction. ## What is not claimed about PM CLI PM CLI's public material does not claim measured productivity gains, overall token savings, reliability percentages, adoption levels or client outcomes. Nothing here says how it behaves with large teams, very large trackers or many agents writing at once. Acceptance criteria describe an intended outcome; they are not proof that it was reached. For the current version, check npm (https://www.npmjs.com/package/@unbrained/pm-cli) or the GitHub releases. Repository commits, package versions and deployed versions are separate things.