Claude Code 项目管理系统开源

AI Agent 的规范驱动开发——使用 PRD、GitHub Issue 和多个并行运行的 Agent 更快更好地交付。

停止丢失上下文。停止被任务阻塞。停止交付缺陷。CCPM 为你的 AI Agent 提供了一个结构化的 PM 大脑：将想法转化为 PRD，将 PRD 转化为 Epic，将 Epic 转化为 GitHub Issue，将 Issue 转化为生产代码——每一步都拥有完整的可追溯性。

📢 CCPM 现在是一个 AGENT SKILL！它适用于任何支持 Agent Skills 的 harness：Claude Code、Codex、OpenCode、Factory、Amp、Cursor 等。

区别所在

核心原则：拒绝"感觉编码"

每一行代码必须可以追溯到一份规范。

CCPM 强制执行严格的 5 阶段规程：

🧠 头脑风暴——思考得比舒适区更深入

📝 文档化——编写没有歧义的规范

📐 规划——进行显式技术决策的架构设计

⚡ 执行——精确构建规范所述的内容

📊 跟踪——在每一步保持透明的进度

没有捷径。没有假设。没有遗憾。

并行执行系统

传统思维：一个 Issue = 一个 Agent = 一个任务

现实：单个"实现用户认证"Issue 实际上包括：

• Agent 1：数据库表和迁移
• Agent 2：服务层和业务逻辑
• Agent 3：API 端点和中间件
• Agent 4：UI 组件和表单
• Agent 5：测试套件和文档

所有这些同时在同一个 worktree 中运行。

每个 Agent 在隔离的上下文中处理自己的工作。你的主对话变成了指挥家——它永远不会被实现细节淹没。Agent 从 .claude/epics/ 读取数据并通过 Git 提交进度。

关键特性和收益

🧠 上下文保留 —— 项目状态存在文件中，不在你的脑子里或聊天历史中。在任何时间任何地方启动会话。

⚡ 并行执行 —— 标记为 parallel: true 的任务在多个 Agent 中并发运行而无冲突。

🔗 GitHub 原生 —— 与你的团队已在使用的工具协作。不依赖 Projects API。

📊 完整可追溯性 —— 每个决策都有文档。PRD → Epic → Task → Issue → Code → Commit。

🤖 确定性操作以脚本形式运行 —— status、standup、search、validate 都以 bash 脚本运行：快速、一致、无 LLM token 成本。

🌐 Harness 无关 —— 遵循 agentskills.io 开放标准。适用于 Factory、Claude Code、Amp、OpenCode、Codex、Cursor 等。

入门指南

CCPM 是标准 Agent Skill。指向你的 harness 的 skill/ccpm/ —— 就这样。

Claude Code

ln -s /path/to/ccpm/skill/ccpm .claude/skills/ccpm

Factory、Amp 或其他 Agent Skills 兼容的 harness

指向 skill/ccpm/。它遵循 agentskills.io 标准，开箱即用。

前置条件

• git 和 gh CLI（认证：gh auth login）
• 你项目的 GitHub 仓库

工作流程

CCPM 在 Agent 检测到 PM 意图时自动激活。自然交流即可——无需特殊语法。

自然语言触发

1. 规划——捕获需求

"I want to build a notification system — push, email, and in-app"

CCPM 在编写任何内容之前进行引导式头脑风暴。它会询问关于问题、用户、成功标准、约束和范围外的内容——然后在 .claude/prds/<name>.md 创建结构化 PRD。

准备好后："parse the notification-system PRD" → 在 .claude/epics/notification-system/epic.md 生成技术 Epic，包含架构决策、技术方案和任务预览。

2. 结构化——分解任务

"break down the notification-system epic into tasks"

每个任务都有一个文件，包含验收标准、工作量估计、depends_on、parallel 和 conflicts_with 元数据。任务被智能分批以进行并行创建。每个 Epic 默认 ≤10 个任务。

3. 同步——推送到 GitHub

"sync the notification-system epic to GitHub"

创建 Epic Issue，为每个任务创建子 Issue，将本地文件重命名以匹配 GitHub Issue 号，设置专用 worktree（../epic-notification-system/），并创建参考映射文件。

4. 执行——开始构建

"start working on issue 42"

分析 Issue 以识别独立工作流，启动并行 Agent 限制到自己的文件，并设置进度跟踪。每个 Agent 使用 Issue #N: description 提交，并通过 Git 协调。

5. 跟踪——了解当前进度

"standup" / "what's blocked" / "what's next"

所有跟踪操作都以 bash 脚本形式运行——即时输出，无 LLM 开销。脚本扫描 .claude/epics/ 并报告进行中的内容、下一步和阻塞项。

项目结构

skill/ccpm/
├── SKILL.md                  # 入口点——检测意图、路由到参考
└── references/
    ├── plan.md               # PRD 编写 + 解析为 Epic
    ├── structure.md          # Epic 分解为任务
    ├── sync.md               # GitHub 同步、进度评论、关闭、合并
    ├── execute.md            # Issue 分析 + 并行 Agent 启动
    ├── track.md              # 状态、standup、搜索、下一步、阻塞
    ├── conventions.md        # 文件格式、frontmatter schema、git 规则
    └── scripts/              # bash 脚本用于确定性操作
        ├── status.sh
        ├── standup.sh
        ├── epic-list.sh
        ├── search.sh
        └── ...               # 共 14 个脚本

你的项目文件存在项目根目录的 .claude/ 中：

.claude/
├── prds/                     # 产品需求文档
├── epics/
│   └── <feature>/
│       ├── epic.md           # 技术 Epic
│       ├── <N>.md            # 任务文件（同步后以 GitHub Issue 号命名）
│       ├── <N>-analysis.md   # 并行工作流分析
│       └── updates/          # Agent 进度跟踪
└── (archived epics)

文件是真实来源——存在你的仓库中的纯 markdown，无外部服务。

实际示例

You: "I want to build a payment integration with Stripe — subscriptions and one-time charges"

CCPM: Asks 5 clarifying questions about scope, users, success criteria...

You: [answers]

CCPM: ✅ PRD created: .claude/prds/payment-integration.md
      Ready to create the technical epic?

You: "yes, parse it"

CCPM: ✅ Epic created: .claude/epics/payment-integration/epic.md
      8 task categories identified. Ready to decompose?

You: "break it down"

CCPM: ✅ Created 7 tasks — 5 parallel, 2 sequential
      Ready to push to GitHub?

You: "sync it"

CCPM: ✅ Epic #1234 created
      ✅ 7 sub-issues created (#1235–#1241)
      ✅ Worktree: ../epic-payment-integration/

You: "start working on issue 1235"

CCPM: Analyzed 3 parallel streams:
      Stream A: Stripe client setup ✓ Started
      Stream B: Webhook handler ✓ Started
      Stream C: Database models ⏸ Waiting on A

You: "what's our standup?"

CCPM: [runs standup.sh instantly]
      📅 Daily Standup — 2026-03-18
      🔄 In Progress: Issue #1235 (payment-integration) — 60%
      ⏭️ Next: Issue #1236 — Subscription billing logic
      📊 Tasks: 2 in progress, 5 open, 0 closed

验证结果

采用该系统的团队报告：

• 89% 减少上下文切换时间
• 5–8 个并行任务（之前是 1 个）
• 75% 降低缺陷率——由于编码前的详细任务分解
• 特性交付速度最高提升 3 倍

在对比使用 CCPM 的 Agent 与基线（无 skill）的结构化评估中验证。

常见问题

GitHub 集成 —— 使用 gh-sub-issue 扩展来实现正确的父子关系。如果未安装则回退到任务列表。安装方式：gh extension install yahsan2/gh-sub-issue

文件命名 —— 任务在分解期间以 001.md、002.md 开始。GitHub 同步后，重命名为 {issue-id}.md（例如 1234.md）。Issue #1234 = 文件 1234.md。

设计决策 —— 有意避免 GitHub Projects API 的复杂性。所有操作首先在本地文件上运行以提高速度。GitHub 同步是显式和受控的。Worktree 为并行工作提供清晰的 git 隔离。

寻找 v1？ —— 原始的 /pm:* Claude Code 斜杠命令系统保存在 v1 分支上。

核心特性对比

最佳应用场景 —— 需要多个 Agent 协作、完整可追溯性、GitHub 原生工作流的项目。

不适用于 —— 超出围用 shell 脚本的复杂项目管理需求。但简单的操作流快速且确定性。

这个项目背后的人

CCPM 由 Automaze 为做产品的开发者开发，核心开发团队也是做产品的开发者。

如果 CCPM 帮助你的团队交付更好的软件：

⭐ Star 此仓库以示支持

🐦 在 X 上关注 @aroussi 获取更新和技巧

与 Automaze 更快地交付。我们与创始人合作，将他们的愿景变为现实，扩展他们的业务，并优化成功。访问 Automaze 预约通话 ›

---