ccpm 官方入口：GitHub Issues 与多 Agent 并行开发指南

搜索 ccpm 时会遇到三个完全不同的东西：关键链项目管理、同名 Claude Code 插件管理器，以及这里讨论的 AI Agent 项目管理 Skill。认错入口，后面的安装路径和工作流都会跟着错。

当前项目的官方入口是 github.com/automazeio/ccpm。先看 owner 是 automazeio，再看仓库根目录是否包含 skill/ccpm、README.md、CHANGELOG.md 与 MIT License。README 会明确写出 PRD、GitHub Issues、worktree 和多 Agent 并行，而不是插件市场或关键链排程。

Issues 在这里不是待办清单，而是交接面

ccpm 先在本地生成 PRD、Epic 和任务文件，确认后才把 Epic 与任务同步到 GitHub Issues。Issue 状态就是远程项目状态，评论承担进度轨迹；人可以在网页接手，Agent 也能从 Issue 和本地文件继续。它没有强依赖 GitHub Projects API，团队原有标签、里程碑和 PR 习惯不必整套更换。

同步前还有一个容易忽略的安全检查：若远程地址仍指向 automazeio/ccpm 模板仓库，写入会被拒绝。ccpm 应该管理你自己的项目，而不是把测试 Issue 发回官方仓库。

并行发生在文件边界，不发生在口号里

启动一个 Issue 前，ccpm 先读取 Issue 与本地任务，分析会创建和修改哪些文件，再把工作拆成数据库、服务、API、界面或测试等独立流。每个流有自己的范围、预计时间和依赖，执行过程写入 updates/<issue>/。

能立即开始的流会同时启动；依赖未满足的流保持排队。Agent 只改分配给自己的文件，提交信息带 Issue 编号。公共类型、配置与依赖文件由一个指定工作流负责，其余流等待提交后再同步。出现冲突时暂停并报告，规则明确禁止使用强制推送把问题压过去。

一个 worktree 隔开 Epic，多个 Agent 仍要彼此可见

同步 Epic 时，ccpm 创建 epic/<name> 分支和相邻 worktree。它把整项功能与主分支工作区隔开，却允许该 Epic 内的 Agent 通过提交协调。这里有个边界：同一 worktree 不等于彼此隔绝。若两个流同时改共享文件，仍会冲突，所以分析文件里的 Shared Files 与 Sequential Requirements 不能省。

什么时候不要为了“多 Agent”硬拆

一个改动只涉及单文件、步骤高度顺序化，或者验收标准尚未确定时，并行不会带来可靠收益。ccpm 甚至会为分析结果计算并行系数，但数字不能替代文件范围判断。真正值得并行的，是可以独立提交、独立验证，并且合并顺序清楚的工作流。

从官方入口进入后，先读 README，再读 SKILL.md 与对应阶段文件。看到 Issue、worktree 和 Agent 数量先别兴奋；能否说清谁改哪些文件、谁要等谁，才决定这套并行开发是否站得住。