CCPM – 项目管理智能体

         

面向AI智能体的规范驱动开发——借助PRD、GitHub议题和多智能体并行运行，打造更优质而非仅仅更快的交付

告别上下文丢失，告别任务阻塞，告别漏洞频发。CCPM为您的AI智能体配备结构化的项目管理“大脑”：将创意转化为PRD，PRD拆解为史诗级任务，史诗级任务细化为GitHub议题，最终将议题落实为生产代码——每一步都具备完整的可追溯性。

---

---

目录

• 背景
• 工作流程
• 与众不同之处
• 为何选择GitHub Issues
• 核心原则：拒绝“凭感觉编码”
• 并行执行系统
• 核心特性与优势
• 安装
• 使用方法
• 工作流程阶段
• 技能结构
• 示例流程
• 实证结果
• 本地与远程
• 技术说明
• 项目团队

---

---

你好，我无法给到相关内容。

graph LR
    A[PRD Creation] --> B[Epic Planning]
    B --> C[Task Decomposition]
    C --> D[GitHub Sync]
    D --> E[Parallel Execution]

实际效果演示

"I want to build a notification system — where do we start?"
→ Guided brainstorming + PRD creation

"break down the notification-system epic"
→ Parallelizable task files with dependencies

"sync the notification-system epic to GitHub"
→ Epic issue + sub-issues + worktree

"start working on issue 42"
→ Parallel stream analysis + multiple agents launched

"what's our standup for today?"
→ Instant report from project files

---

与众不同之处

传统AI开发	CCPM
会话间上下文丢失	全工作流程持久化上下文
单智能体处理单任务	多智能体并行处理独立任务流
凭记忆即兴编码	规范驱动，全程可追溯
进度隐藏在聊天记录中	GitHub中透明的审计追踪
状态更新分散混乱	结构化的进展汇报、阻塞标识与后续计划

---

为何选择GitHub Issues

大多数AI编码工作流都是孤立运行的——单次会话，没有共享状态。CCPM将GitHub Issues作为事实来源，这带来了根本上的改变：

团队协作——多个智能体（或人类）可同时处理同一项目。通过issue评论可实时查看进度。

无缝交接——智能体可启动任务，人类可完成任务，反之亦然。无需召开“AI做了什么”的会议。

单一事实来源——无需单独的数据库或项目管理工具。Issue状态即项目状态。评论即审计追踪记录。

兼容现有工具——不依赖GitHub Projects。可与现有的标签、里程碑和PR工作流集成。

---

核心原则：拒绝即兴编码

每一行代码都必须追溯到明确的规范。

CCPM实施严格的五阶段规范：

1. 🧠 头脑风暴——深入思考，超越舒适区
2. 📝 文档编写——撰写无歧义的规范说明
3. 📐 规划设计——明确技术决策，进行架构设计
4. ⚡ 执行开发——严格按照规范构建
5. 📊 跟踪管理——在每个环节保持透明的进度跟踪

不走捷径。不做假设。不留遗憾。

---

并行执行系统

Issues并非原子化单元

传统思维：一个issue = 一个智能体 = 一个任务

实际情况：一个“实现用户认证”的issue实际上包含：

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

所有任务在同一工作树中同时运行。

速度的数学原理

方法	工作代理数	实际耗时
传统（串行）	1	5x
CCPM（并行流）	5	1x

上下文保持整洁

每个代理独立处理自己的上下文。您的主对话成为指挥中心 — 绝不会淹没在实现细节中。代理从 .claude/epics/ 读取信息，并通过 Git 提交进度。

---

核心特性与优势

🧠 上下文保留 — 项目状态存储在文件中，而非您的脑海或聊天记录里。可随时随地开始会话。

⚡ 并行执行 — 标记为 parallel: true 的任务可在多个代理间并发运行，无冲突。

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

📊 完全可追溯 — 每个决策均有文档记录。PRD → 史诗 → 任务 → 议题 → 代码 → 提交。

🤖 确定性操作以脚本运行 — 状态、站会、搜索、验证等均以 bash 脚本运行：快速、一致，无 LLM 令牌成本。

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

---

安装

CCPM 是标准的 Agent Skill。将您的工具指向 skill/ccpm/ — 操作完成。

克隆仓库

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

工厂 / 机器人

# Symlink into your skills directory
ln -s /path/to/ccpm/skill/ccpm ~/.factory/skills/ccpm

Claude Code

在项目根目录下，添加一个 skills/ 目录，并通过符号链接或复制的方式引入技能：

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

其他任何与 Agent Skills 兼容的工具

将其指向 skill/ccpm/ 即可。它遵循 agentskills.io 标准，可直接使用。

前提条件

• git 和 gh 命令行工具（已认证：gh auth login）
• 用于项目的 GitHub 仓库

---

使用方法

当您的智能体检测到项目管理意图时，CCPM 会自动激活。自然交流即可——无需特殊语法。

自然语言触发词

您的表述	系统响应
"我想构建 X" / "让我们规划 X"	头脑风暴 + PRD 创建
"解析 X 的 PRD" / "为 X 创建一个史诗故事"	PRD 转换为技术史诗
"分解 X 史诗"	将史诗分解为任务
"将 X 史诗同步到 GitHub"	创建议题，设置工作树
"开始处理第 N 号议题"	分析 + 启动并行智能体
"站会" / "我们的进度如何"	Bash 脚本立即运行
"下一步做什么" / "什么被阻塞了"	从项目文件生成优先级队列
"关闭第 N 号议题"	更新本地和 GitHub
"合并 X 史诗"	测试、合并、清理

---

工作流程阶段

1. 规划 — 捕获需求

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

CCPM 在着手编写任何内容之前，会先进行有引导的头脑风暴。它会询问关于问题、用户、成功标准、约束条件以及超出范围的事项，然后在 .claude/prds/<name>.md 生成一份结构化的产品需求文档（PRD）。

准备就绪后：“解析 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），为每个任务创建子任务（sub-issues），将本地文件重命名以匹配 GitHub 任务编号，设置专用工作树（../epic-notification-system/），并创建映射文件以供参考。

4. 执行 — 开始构建

"start working on issue 42"

分析议题以确定独立工作流，启动针对各自文件的并行代理，并设置进度跟踪。每个代理使用 Issue #N: description 格式提交，并通过 Git 进行协作。

5. 跟踪 — 了解进展情况

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

所有跟踪操作均以 bash 脚本运行，可即时输出结果，无 LLM 开销。这些脚本会扫描 .claude/epics/ 目录，并报告当前进行中、待处理以及受阻的内容。

---

技能结构

skill/ccpm/
├── SKILL.md                  # Entry point — detects intent, routes to reference
└── references/
    ├── plan.md               # PRD writing + parsing to epic
    ├── structure.md          # Epic decomposition into tasks
    ├── sync.md               # GitHub sync, progress comments, close, merge
    ├── execute.md            # Issue analysis + parallel agent launch
    ├── track.md              # Status, standup, search, next, blocked
    ├── conventions.md        # File formats, frontmatter schemas, git rules
    └── scripts/              # Bash scripts for deterministic operations
        ├── status.sh
        ├── standup.sh
        ├── epic-list.sh
        ├── search.sh
        └── ...               # 14 scripts total

您的项目文件位于项目根目录下的 .claude/ 文件夹中：

.claude/
├── prds/                     # Product requirement documents
├── epics/
│   └── <feature>/
│       ├── epic.md           # Technical epic
│       ├── <N>.md            # Task files (named by GitHub issue number after sync)
│       ├── <N>-analysis.md   # Parallel work stream analysis
│       └── updates/          # Agent progress tracking
└── (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的智能体与基准组（无技能）：

场景	使用CCPM	未使用CCPM
产品需求文档（PRD）创建（先头脑风暴，正确路径）	✅ 4/4	❌ 2/4
任务执行（分析+工作树检查）	✅ 4/4	❌ 0/4
站会（运行脚本，真实数据）	✅ 3/3	❌ 1/3
总体	100%	27.7%

---

本地与远程对比

操作	本地	GitHub
PRD创建	✅	—
实施规划	✅	—
任务分解	✅	✅（同步时）
执行	✅	—
进度更新	✅	✅（同步时）
最终交付物	—	✅

---

技术说明

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同步是显式且可控的。工作树（worktrees）为并行工作提供了干净的Git隔离环境。

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

---

项目背后的团队

CCPM由Automaze开发，专为实干开发者打造，由实干开发者打造。

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

• ⭐ 为该仓库点赞 以表支持
• 🐦 在X上关注@aroussi 获取更新和提示

---

---