Latest release Open source, MIT licensed

Manage outcomes,
not agents.

pm is a human-agent project management suite for coding agents. Your agents claim the work, keep its context as records and raise what they need from you. You steer all of them from one site.

Install, then set up a repo
$ curl -fsSL https://github.com/Yeeef/pm/releases/latest/download/install.sh | sh
$ pm init # in your repo

macOS on Apple silicon and Linux on x86-64 · Works with Claude Code and Codex · Source on GitHub

localhost · pm site · overview
The pm site's overview page: the decisions and actions that wait on the owner, each with a reply form.
The suite

One suite for the work, its context, and you.

pm keeps a project in two layers, a work store and Markdown records, and the pm cli is the only way into the work store. A service per clone turns both into the site you read and answer.

Project and task management for agents

Projects, sprints and tasks in one work store that every session shares. An agent claims a task before it works on it, and a task has one holder. Dependencies say what waits on what, and pm task ready lists what can start now. That is what lets many agents work one repo without colliding.

  • claims
  • one holder
  • dependencies
  • ready work

Context as Records, tied to the work

Goals, sprint frames, decisions, findings and design pages, as Markdown on your repo's records branch. Each record points at its project or sprint, so the why stays next to the work. Agents read them with pm show; you read them on the site.

  • goals
  • decisions
  • findings
  • design pages

The site: your interface to the swarm

A site per clone, served by the pm service, shows every project, sprint and record with live status. The decisions and actions your agents need from you wait at the top. You answer on the page, and the reply reaches the session that asked.

  • live status
  • decisions await you
  • replies
Structural, not prompts

A prompt asks. pm refuses.

A skill pack is a set of prompt files that ask an agent to behave. Nothing stops it from skipping a step, or from losing the rule an hour into a session. pm puts the agent's decision and action space in software: the pm cli, the work store and the session hooks. A step out of bounds is refused, and the refusal says what to do instead.

A skill pack

Seven prompt files

Guidance the agent reads, then weighs against everything else in its context. Whether it follows the plan is up to the model, every time.

  • plan.md
  • tasks.md
  • review.md
  • handoff.md
  • git.md
  • memory.md
  • status.md
pm

Enforced by the tools agents must use

  • The cli checks every writeClaims, closes, sprint frames and requests to you are checked before anything is written. A refusal changes nothing.
  • The work store holds one truthHolders, status and dependencies live in one Dolt database per clone, synced through your git remote. There is no status file to drift.
  • Hooks guard each session's start and stopSession start injects pm's rules and the project's state. At stop, a reply that asks you for something only in chat is blocked, with the command that raises it as a request on your site, and records edited but left uncommitted are caught. The chat-ask check and day summaries call the claude CLI, so it must be installed and logged in, Codex setups included.
agent sessionrefusals, verbatim from pm 0.6.0
$ pm task claim acme-q1.3.2
error: not claiming acme-q1.3.2 here: /home/me/acme is the main checkout; agents change code only in a worktree of their own. Make one and work there: …
$ pm task close acme-q1.3.4 --reason "Parser done"
error: acme-q1.3.4 is held by live session 5f0c2d1e-8a7b-4c3d-9e2f-1a6b7c8d9e0f (claimed 12m ago; its transcript was written in the last 30 minutes); leave it, or ask that session to close it, or to release it with pm task release acme-q1.3.4
$ pm sprint close acme-q1.3
error: open tasks in the sprint: acme-q1.3.5 (in_progress); close each with pm task close or move it with pm task move (a PR review closes with pm need close <id> --reason "merged as <sha>" once the PR is on main)
$ pm decision need --title "Cache layer" --sprint acme-q1.3 --question '…' --fact '…' --option redis '…' --cost redis '…' --default redis '…'
error: give at least two --option flags; a decision needs a choice; a decision need takes its parts as flags, one line each: …
Stop hook · pm hook owner-request · blocked
Your reply asks the owner for something that no open request of this session covers: "Can you confirm we drop the v1 API?". Chat requests never reach the owner's site, so the owner may never see them. …

Ids, paths and quoted asks are examples; the wording is pm's. "…" marks where a refusal goes on to give the exact command or form to use.

Outcomes

What changes when pm runs the project.

01

Any task, any agent, any time.

Every session starts with pm's rules and the project's state. The task, its sprint's frame and the decisions behind it are in the work store and the records, so a fresh agent picks up where the last one stopped. A task whose holder has been idle for 30 minutes on the same machine can be claimed by the next agent.

pm show # state, injected at session start pm task ready # what can start now pm task claim <id> # one holder per task
02

A home for every plan.

Plans, decisions and findings have a home: checked records on the records branch, apart from your code branches. pm's rules send context there, so your code tree stays code.

PLANNING.mdIMPLEMENTATION.mdTASK_67.mdNOTES-v2.mdrecords branch
03

Run ten agents or more. Still manage them.

Agents raise the decisions and actions they need from you as requests, and each one lands in the same view. Every sprint has a goal, a scope and a done-when before any work runs: pm sprint open refuses a frame without them.

04

Self-contained.

pm init adds no line to your AGENTS.md or CLAUDE.md. Session hooks for Claude Code and Codex inject pm's context, and each command's --help holds the rest.

05

Clone it anywhere. Keep going.

The work store syncs through your own git remote under refs/pm/work, and records live on the records branch. On a new machine: clone, pm init, and your agents continue the work. No hosted service, no account.

The site

Your interface to a swarm of agents.

You do not read transcripts. You read the site: the state of every project, the goal and progress of every sprint, and the requests that wait on you, rendered from the records and the work store as they change.

How it works

Agents work through pm. You read one site.

Hooks give each session its context; the cli is the only way to change the work store. pm writes two layers, and one service per clone renders them for you and carries your replies back.

How pm works Agent sessions get context from session hooks and send commands to the pm cli. The cli writes the work store, a Dolt database, and the records, Markdown on the records branch; both sync through the git remote. The pm service reads both and renders the site. The owner replies on the site, and the service delivers each reply to the session that asked. replies reach the session that asked Agent sessions one task, one holder Claude Code Codex Subagents many at once Session hooks Start: rules and state Stop: chat-only asks and uncommitted records pm cli claim · close · need · decide every write checked; out of bounds, refused synced through your git remote refs/pm/work · records branch Work store Dolt projects, sprints, tasks, holders, dependencies, needs Records Markdown · records branch goals, frames, decisions, findings, design pages pm service one per clone: serves the site, syncs, delivers replies Site status and what awaits you You, the owner decide, act, review PRs context commands writes state reads renders replies How pm works Agent sessions get context from session hooks and send commands to the pm cli. The cli writes the work store and the records, which sync through the git remote. The pm service reads both and renders the site. The owner replies on the site, and the service delivers each reply to the session that asked. Agent sessions Claude Code · Codex · subagents context commands Session hooks rules and state; stop checks pm cli checked writes, refusals state writes Work store Dolt tasks, needs Records records branch Markdown synced via git remote reads pm service serves the site, syncs, delivers replies renders Site status and what awaits you replies You, the owner decide, act, review PRs replies reach the session that asked
Session hooksAt start, pm's rules and the project's state. At stop, a check for asks left in chat and for uncommitted records.
pm cliThe one way to change the work store: every write is checked first, and a refusal names the way forward.
Work store and recordsA Dolt database per clone, synced under refs/pm/work, and Markdown on the records branch.
pm serviceOne background process per clone. It holds the work store, serves the site, syncs, and delivers your replies.
Get started

Three steps to your first sprint.

1

Install pm

The script checks the binary against the release's SHA256SUMS and installs the latest release to ~/.local/bin/pm.

$ curl -fsSL https://github.com/Yeeef/pm/releases/latest/download/install.sh | sh
2

Set up your repo

Pins the pm version, adds the hooks for Claude Code and Codex, creates the records branch and the work store, and starts the pm service.

$ pm init
3

Start an agent

Open a Claude Code or Codex session and describe the outcome you want. It arrives with pm's rules and the project's state, frames the work as a project and sprints, and asks you on the site for what only you can decide.

Manage outcomes, not agents.

pm is open source under the MIT license. Read the code, file an issue, or install it and point your agents at a goal.