CCPM Puts Project State in GitHub Issues and Parallel Work in Git Worktrees
Project management skill system for Agents that uses GitHub Issues and Git worktrees for parallel agent execution.
At a glance
- What is it?
- CCPM is a specification-driven project management skill for AI coding agents. It stores the plan in files and GitHub Issues, then spawns parallel agents in a shared worktree. The approach is sound where GitHub is already the team's source of truth, and awkward everywhere else.
- Who is it for?
- 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.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Activity is slowing. The repository last received commits 6 months ago.
- What is it written in?
- Mainly Shell, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
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. GitHub is the sync target, not the working store. That ordering matters: it means the agent can operate offline against local files, and the issue tracker becomes a published view rather than a live dependency. 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, because the README does not explain a locking or partitioning mechanism. The dependency modelling in the task files is presumably what prevents collisions, but that is inference from the described workflow, not something the README states outright.
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 supplied README is truncated mid-sentence at that point, so the exact Claude Code command is not available here. 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. There are no releases retrieved for this repository, 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 git worktrees so the branches are physically separate. 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, and the README does not explain how the two integrate.
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 shows no retrieved releases, so there is no changelog to scan between versions and no tag to pin. The last push recorded is 2026-03-18, 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 eval score badge claims 100 percent, and the repository carries a star badge. Neither is 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 the documentation leaves thinnest, and it 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.
Community notes