CCPM Puts Project State in GitHub Issues and Parallel Work in Git Worktrees

The Problem CCPM Targets: Agent Context That Dies With the Session

A coding agent that works for an hour and then loses its thread is not a project manager. It is a very fast contractor with amnesia. The README lists four symptoms it was built against: context evaporating between sessions, parallel work creating conflicts when multiple agents touch the same code, requirements drifting as verbal decisions override written specs, and progress staying invisible until the end. Those are real failure modes for anyone running agents on more than a single sitting, and they compound. An agent that re-discovers the codebase every session burns tokens on orientation instead of work. An agent that keeps the plan in chat history cannot hand off to a human, or to another agent, without a meeting.

The intended user is a small team or a solo developer already using an agent harness (Claude Code, Codex, OpenCode, Factory, Amp, Cursor) and already using GitHub. CCPM does not try to be a new tracker. It treats the issue tracker you have as the database and the repository as the memory. That is the entire thesis, and it is a reasonable one: the fewer places project state lives, the fewer places it can disagree with itself.

The Five-Stage Pipeline: PRD, Epic, Task, Issue, Worktree

The workflow is linear and documented as a mermaid graph: PRD Creation, then Epic Planning, then Task Decomposition, then GitHub Sync, then Parallel Execution. Each stage has a corresponding conversational trigger. The README gives these examples: "I want to build a notification system" starts guided brainstorming and PRD creation; "break down the notification-system epic" produces parallelizable task files with dependencies; "sync the notification-system epic to GitHub" creates an epic issue, sub-issues and a worktree; "start working on issue 42" triggers parallel stream analysis and launches multiple agents.

The data flow is file-first, then remote. Artifacts live under `.claude/epics/` according to the README, and agents read from that directory and commit progress back through Git. The README also states that deterministic operations (status, standup, search, validate) run as bash scripts rather than through the model, which keeps those commands fast and free of token cost. That is a design decision worth noting, because it draws a line between what the agent reasons about and what a shell script can answer exactly.

Parallel Execution Assumes One Issue Is Several Jobs

The most opinionated claim in the README is that issues are not atomic. A single issue titled "Implement user authentication" is, in CCPM's framing, five concurrent jobs: database tables and migrations, service layer and business logic, API endpoints and middleware, UI components and forms, and test suites plus documentation. Each gets its own agent. Tasks marked `parallel: true` are the ones that run concurrently.

The README's velocity table puts serial work at 5x wall time with one agent and parallel work at 1x with five. That is arithmetic, not a benchmark, and it assumes the five streams are genuinely independent. The README says agents share the same worktree, and that each agent handles its own context in isolation while the main conversation acts as conductor. Whether five agents writing to one worktree stay out of each other's way is exactly the question a reader should ask; the README claims tasks marked `parallel: true` run concurrently across multiple agents without conflicts.

Install: A Symlink Into Your Harness's Skills Directory

CCPM is packaged as an Agent Skill rather than a CLI, so installation is about placement, not compilation. The README's steps are short. Clone the repository:

git clone https://github.com/automazeio/ccpm.git

For Factory or Droid, symlink the skill into the harness's skills directory:

ln -s /path/to/ccpm/skill/ccpm ~/.factory/skills/ccpm

For Claude Code, the README says to add a `skills/` directory in your project root and symlink or copy the skill into it. The general rule it states is that you point your harness at `skill/ccpm/` and that is it.

The practical constraint is that this only works with harnesses implementing the agentskills.io standard. If your tool has no skills directory, there is nothing to install. The repository has no published GitHub releases, so there is no versioned artifact to pin; you are tracking the default branch. For a tool that writes into your project's `.claude/epics/` directory and creates worktrees, that is a meaningful operational detail.

Where CCPM Is the Wrong Tool

The GitHub dependency is the first hard boundary. The README frames GitHub Issues as the source of truth and explicitly notes the design does not depend on the GitHub Projects API, only on issues, labels, milestones and pull requests. If your team's tracker is Jira, Linear, GitLab or anything else, CCPM's sync stage has nowhere to publish. You could use the local file half of the workflow and ignore the sync, but then you lose the audit trail that the README treats as the point of the system.

The second boundary is the shape of the work. CCPM's value comes from decomposition: a PRD becomes an epic, an epic becomes parallelizable tasks with dependencies. If your work is a single-file bug fix, or an exploratory spike where the requirements are not knowable in advance, the five-phase discipline is overhead. The README's own framing is "No shortcuts. No assumptions." That is a feature for a project with a written specification and a liability for one without.

The third is the worktree model itself. Agents committing into a shared worktree means your repository's working state is being mutated by several processes at once. Teams that already find multi-agent git conflicts painful should treat the parallel execution stage as the part to evaluate hardest, not the part to adopt first.

Compared With a Plain Agent Session or a Spec Framework

The obvious alternative is what most people do today: run one agent in one session, keep the plan in the conversation, and paste context back in when it drifts. That approach has zero setup cost and no GitHub requirement, and for a task that fits in one context window it is strictly simpler. The difference in approach is where state lives. A plain session keeps state in the model's context, which is lost when the session ends. CCPM keeps state in files under `.claude/epics/` and in GitHub issues, which survives the session and is readable by a human who was not present.

A second comparison is a specification framework that generates a plan but stops there. CCPM's distinguishing move is the execution half: it takes the decomposed tasks and actually launches multiple agents against them, using a git worktree. Tools that only produce a plan document leave the parallelism to you. That is a real difference in scope, and it is also why CCPM's failure modes are more expensive: a bad plan document wastes reading time, while a bad parallel execution mutates your repository.

The README also points to a companion project, automazeio/proof, described as capturing visual proof of terminal output, browser interactions and mobile simulator recordings. That is a separate tool, not part of CCPM.

Maintenance, Licence and What to Check Before Adopting

CCPM is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the standard permissive position and it imposes no copyleft obligation on your own code. It says nothing about the licence of the harness you pair it with, and nothing about the content your agents commit. This is not legal advice; if you are redistributing a modified skill, read the LICENSE file in the repository rather than the badge.

Maintenance cost is dominated by the skill's coupling to its harness. Because CCPM is a set of skill files and bash scripts rather than a compiled binary, upgrades mean pulling the repository and re-checking that the skill directory layout still matches your harness's convention. The repository has no published GitHub releases, so there is no tag to pin, though a CHANGELOG.md sits at the root. The last push recorded is 2026-10-19, which indicates the project is active, but activity is not the same as stability for a tool that writes into your working tree.

The README's badges are not evidence of anything about your codebase. What is worth verifying first is concrete: confirm that `skill/ccpm/` resolves correctly in your harness, confirm the `.claude/epics/` directory is one you are willing to commit or gitignore deliberately, and read the parallel execution scripts to see how agents are kept apart inside the shared worktree. That last item is the one that decides whether CCPM saves you time or costs you a merge conflict.

Editorial conclusion

Adopt CCPM if your team already treats GitHub Issues as the source of truth and you want agent work to leave a traceable trail from PRD to commit. Skip it if your issue tracker is Jira, Linear or GitLab, because the whole design assumes GitHub. Before committing, verify two things in the repository: that the skill directory matches your harness's skill layout, and that the parallel execution logic genuinely isolates agents, since the README describes five agents sharing one worktree.

Frequently asked questions

Official sources

1. automazeio/ccpm on GitHub
2. Issues
3. License: MIT
4. Project website
5. README