mirror of
https://github.com/automazeio/ccpm.git
synced 2025-10-09 13:41:06 +03:00
Add Chinese documentation and fix typo (#676)
- Add Chinese documentation links in README.md, COMMANDS.md, and AGENTS.md - Fix typo: 'mutiple' -> 'multiple' in README.md - Include new Chinese documentation files in doc/ directory 🤖 Generated with [Claude Code](https://claude.ai/code) Co-authored-by: Claude <noreply@anthropic.com>
This commit is contained in:
cyxer000
@@ -1,5 +1,7 @@
|
||||
# Agents
|
||||
|
||||
**[中文文档 (Chinese Documentation)](doc/AGENTS_ZH.md)**
|
||||
|
||||
Specialized agents that do heavy work and return concise summaries to preserve context.
|
||||
|
||||
## Core Philosophy
|
||||
|
||||
@@ -1,5 +1,7 @@
|
||||
# Commands
|
||||
|
||||
**[中文文档 (Chinese Documentation)](doc/COMMANDS_ZH.md)**
|
||||
|
||||
Complete reference of all commands available in the Claude Code PM system.
|
||||
|
||||
> **Note**: Project Management commands (`/pm:*`) are documented in the main [README.md](README.md#command-reference).
|
||||
|
||||
@@ -1,5 +1,7 @@
|
||||
# Claude Code PM
|
||||
|
||||
**[中文文档 (Chinese Documentation)](doc/README_ZH.md)**
|
||||
|
||||
[](https://automaze.io)
|
||||
|
||||
[](https://github.com/automazeio/ccpm/blob/main/README.md)
|
||||
|
||||
112
doc/AGENTS_ZH.md
Normal file
112
doc/AGENTS_ZH.md
Normal file
@@ -0,0 +1,112 @@
|
||||
# 代理
|
||||
|
||||
专门处理繁重工作的代理，返回简洁摘要以保留上下文。
|
||||
|
||||
## 核心理念
|
||||
|
||||
> "不要将子代理拟人化。使用它们来组织你的提示并省略上下文。当子代理能够完成大量工作但只向主线程提供少量信息时效果最佳。"
|
||||
>
|
||||
> – Adam Wolff, Anthropic
|
||||
|
||||
## 可用代理
|
||||
|
||||
### 🔍 `code-analyzer`
|
||||
- **目的**: 跨多个文件查找错误而不污染主线程上下文
|
||||
- **模式**: 搜索多个文件 → 分析代码 → 返回错误报告
|
||||
- **用法**: 当你需要追踪逻辑流、查找错误或验证更改时
|
||||
- **返回**: 仅包含关键发现的简洁错误报告
|
||||
|
||||
### 📄 `file-analyzer`
|
||||
- **目的**: 读取和总结详细文件(日志、输出、配置)
|
||||
- **模式**: 读取文件 → 提取见解 → 返回摘要
|
||||
- **用法**: 当你需要理解日志文件或分析详细输出时
|
||||
- **返回**: 关键发现和可操作的见解(减少80-90%的大小)
|
||||
|
||||
### 🧪 `test-runner`
|
||||
- **目的**: 执行测试而不将输出转储到主线程
|
||||
- **模式**: 运行测试 → 捕获到日志 → 分析结果 → 返回摘要
|
||||
- **用法**: 当你需要运行测试并理解失败原因时
|
||||
- **返回**: 包含失败分析的测试结果摘要
|
||||
|
||||
### 🔀 `parallel-worker`
|
||||
- **目的**: 协调处理问题的多个并行工作流
|
||||
- **模式**: 读取分析 → 生成子代理 → 整合结果 → 返回摘要
|
||||
- **用法**: 当在工作树中执行并行工作流时
|
||||
- **返回**: 所有并行工作的整合状态
|
||||
|
||||
## 为什么使用代理?
|
||||
|
||||
代理是保护主线程免受信息过载的**上下文防火墙**:
|
||||
|
||||
```
|
||||
不使用代理:
|
||||
主线程读取10个文件 → 上下文爆炸 → 失去连贯性
|
||||
|
||||
使用代理:
|
||||
代理读取10个文件 → 主线程获得1个摘要 → 上下文得以保留
|
||||
```
|
||||
|
||||
## 代理如何保留上下文
|
||||
|
||||
1. **繁重工作** - 代理完成繁琐的工作(读取文件、运行测试、实现功能)
|
||||
2. **上下文隔离** - 实现细节保留在代理中，不在主线程
|
||||
3. **简洁返回** - 只有必要信息返回到主线程对话
|
||||
4. **并行执行** - 多个代理可以同时工作而不会产生上下文冲突
|
||||
|
||||
## 使用示例
|
||||
|
||||
```bash
|
||||
# 分析代码查找错误
|
||||
任务: "在代码库中搜索内存泄漏"
|
||||
代理: code-analyzer
|
||||
返回: "发现3个潜在泄漏: [简洁列表]"
|
||||
主线程不会看到: 检查的数百个文件
|
||||
|
||||
# 运行测试
|
||||
任务: "运行身份验证测试"
|
||||
代理: test-runner
|
||||
返回: "10个测试中有2个失败: [失败摘要]"
|
||||
主线程不会看到: 详细的测试输出和日志
|
||||
|
||||
# 并行实现
|
||||
任务: "使用并行流实现问题#1234"
|
||||
代理: parallel-worker
|
||||
返回: "完成4/4个流，修改了15个文件"
|
||||
主线程不会看到: 单个实现细节
|
||||
```
|
||||
|
||||
## 创建新代理
|
||||
|
||||
新代理应遵循以下原则:
|
||||
|
||||
1. **单一目的** - 每个代理都有一个明确的工作
|
||||
2. **上下文缩减** - 返回处理内容的10-20%
|
||||
3. **不角色扮演** - 代理不是"专家"，而是任务执行器
|
||||
4. **清晰模式** - 定义输入 → 处理 → 输出模式
|
||||
5. **错误处理** - 优雅地处理失败并清晰报告
|
||||
|
||||
## 需避免的反模式
|
||||
|
||||
❌ **创建"专家"代理** (数据库专家、API专家)
|
||||
代理没有不同的知识 - 它们都是相同的模型
|
||||
|
||||
❌ **返回详细输出**
|
||||
违背了上下文保留的目的
|
||||
|
||||
❌ **让代理相互沟通**
|
||||
应该使用协调代理(如parallel-worker)
|
||||
|
||||
❌ **为简单任务使用代理**
|
||||
只有当上下文缩减有价值时才使用代理
|
||||
|
||||
## 与PM系统的集成
|
||||
|
||||
代理与PM命令系统无缝集成:
|
||||
|
||||
- `/pm:issue-analyze` → 识别工作流
|
||||
- `/pm:issue-start` → 生成parallel-worker代理
|
||||
- parallel-worker → 生成多个子代理
|
||||
- 子代理 → 在工作树中并行工作
|
||||
- 结果 → 整合回主线程
|
||||
|
||||
这创建了一个层次结构，在每个级别都最大化并行性同时保留上下文。
|
||||
157
doc/COMMANDS_ZH.md
Normal file
157
doc/COMMANDS_ZH.md
Normal file
@@ -0,0 +1,157 @@
|
||||
# 命令
|
||||
|
||||
Claude Code PM 系统中所有可用命令的完整参考。
|
||||
|
||||
> **注意**: 项目管理命令 (`/pm:*`) 在主 [README.md](README.md#command-reference) 中有文档说明。
|
||||
|
||||
## 目录
|
||||
|
||||
- [上下文命令](#上下文命令)
|
||||
- [测试命令](#测试命令)
|
||||
- [实用命令](#实用命令)
|
||||
- [审查命令](#审查命令)
|
||||
|
||||
## 上下文命令
|
||||
|
||||
用于管理 `.claude/context/` 中项目上下文的命令。
|
||||
|
||||
### `/context:create`
|
||||
- **目的**: 创建初始项目上下文文档
|
||||
- **用法**: `/context:create`
|
||||
- **描述**: 分析项目结构并在 `.claude/context/` 中创建全面的基线文档。包括项目概述、架构、依赖项和模式。
|
||||
- **使用时机**: 项目开始时或需要完全重建上下文时
|
||||
- **输出**: 涵盖项目不同方面的多个上下文文件
|
||||
|
||||
### `/context:update`
|
||||
- **目的**: 使用最近的更改更新现有上下文
|
||||
- **用法**: `/context:update`
|
||||
- **描述**: 根据最近的代码更改、新功能或架构更新刷新上下文文档。保留现有上下文同时添加新信息。
|
||||
- **使用时机**: 重大更改后或主要工作会话前
|
||||
- **输出**: 带有变更跟踪的更新上下文文件
|
||||
|
||||
### `/context:prime`
|
||||
- **目的**: 将上下文加载到当前对话中
|
||||
- **用法**: `/context:prime`
|
||||
- **描述**: 读取所有上下文文件并将其加载到当前对话的内存中。对于保持项目意识至关重要。
|
||||
- **使用时机**: 任何工作会话开始时
|
||||
- **输出**: 已加载上下文的确认信息
|
||||
|
||||
## 测试命令
|
||||
|
||||
用于测试配置和执行的命令。
|
||||
|
||||
### `/testing:prime`
|
||||
- **目的**: 配置测试设置
|
||||
- **用法**: `/testing:prime`
|
||||
- **描述**: 检测和配置项目的测试框架，创建测试配置，并准备测试运行代理。
|
||||
- **使用时机**: 初始项目设置或测试框架更改时
|
||||
- **输出**: 包含测试命令和模式的 `.claude/testing-config.md`
|
||||
|
||||
### `/testing:run`
|
||||
- **目的**: 执行具有智能分析的测试
|
||||
- **用法**: `/testing:run [测试目标]`
|
||||
- **描述**: 使用测试运行代理运行测试，该代理将输出捕获到日志中，仅返回必要结果以保留上下文。
|
||||
- **选项**:
|
||||
- 无参数: 运行所有测试
|
||||
- 文件路径: 运行特定测试文件
|
||||
- 模式: 运行匹配模式的测试
|
||||
- **输出**: 具有失败分析的测试摘要，主线程中无详细输出
|
||||
|
||||
## 实用命令
|
||||
|
||||
通用实用程序和维护命令。
|
||||
|
||||
### `/prompt`
|
||||
- **目的**: 处理具有多个引用的复杂提示
|
||||
- **用法**: 在文件中写入提示，然后输入 `/prompt`
|
||||
- **描述**: 用于直接输入中具有众多 @ 引用的复杂提示失败时的临时命令。提示首先写入命令文件，然后执行。
|
||||
- **使用时机**: 当 Claude 的 UI 拒绝复杂提示时
|
||||
- **输出**: 执行写入的提示
|
||||
|
||||
### `/re-init`
|
||||
- **目的**: 使用 PM 规则更新或创建 CLAUDE.md
|
||||
- **用法**: `/re-init`
|
||||
- **描述**: 使用 `.claude/CLAUDE.md` 中的规则更新项目的 CLAUDE.md 文件，确保 Claude 实例具有正确的指令。
|
||||
- **使用时机**: 克隆 PM 系统后或更新规则后
|
||||
- **输出**: 项目根目录中更新的 CLAUDE.md
|
||||
|
||||
## 审查命令
|
||||
|
||||
用于处理外部代码审查工具的命令。
|
||||
|
||||
### `/code-rabbit`
|
||||
- **目的**: 智能处理 CodeRabbit 审查注释
|
||||
- **用法**: `/code-rabbit` 然后粘贴注释
|
||||
- **描述**: 使用上下文意识评估 CodeRabbit 建议，接受有效改进同时忽略缺乏上下文的建议。为多文件审查生成并行代理。
|
||||
- **功能**:
|
||||
- 理解 CodeRabbit 缺乏完整上下文
|
||||
- 接受: 真实错误、安全问题、资源泄漏
|
||||
- 忽略: 样式偏好、无关模式
|
||||
- 多文件的并行处理
|
||||
- **输出**: 接受/忽略建议的摘要及理由
|
||||
|
||||
## 命令模式
|
||||
|
||||
所有命令遵循一致的模式:
|
||||
|
||||
### 允许的工具
|
||||
每个命令在 frontmatter 中指定其所需工具:
|
||||
- `Read, Write, LS` - 文件操作
|
||||
- `Bash` - 系统命令
|
||||
- `Task` - 子代理生成
|
||||
- `Grep` - 代码搜索
|
||||
|
||||
### 错误处理
|
||||
命令遵循快速失败原则:
|
||||
- 首先检查先决条件
|
||||
- 清晰的错误消息及解决方案
|
||||
- 永不留下部分状态
|
||||
|
||||
### 上下文保留
|
||||
处理大量信息的命令:
|
||||
- 使用代理保护主线程免受详细输出影响
|
||||
- 返回摘要，而非原始数据
|
||||
- 仅保留必要信息
|
||||
|
||||
## 创建自定义命令
|
||||
|
||||
添加新命令的步骤:
|
||||
|
||||
1. **创建文件**: `commands/category/command-name.md`
|
||||
2. **添加 frontmatter**:
|
||||
```yaml
|
||||
---
|
||||
allowed-tools: Read, Write, LS
|
||||
---
|
||||
```
|
||||
3. **结构化内容**:
|
||||
- 目的和用法
|
||||
- 预检检查
|
||||
- 分步指令
|
||||
- 错误处理
|
||||
- 输出格式
|
||||
|
||||
4. **遵循模式**:
|
||||
- 保持简单 (不过度验证)
|
||||
- 快速失败并提供清晰消息
|
||||
- 使用代理进行繁重处理
|
||||
- 返回简洁输出
|
||||
|
||||
## 与代理集成
|
||||
|
||||
命令经常使用代理进行繁重工作:
|
||||
|
||||
- **test-runner**: 执行测试，分析结果
|
||||
- **file-analyzer**: 总结详细文件
|
||||
- **code-analyzer**: 在代码库中查找错误
|
||||
- **parallel-worker**: 协调并行执行
|
||||
|
||||
这使主线程上下文保持清洁，同时完成复杂工作。
|
||||
|
||||
## 注意事项
|
||||
|
||||
- 命令是作为指令解释的 markdown 文件
|
||||
- `/` 前缀触发命令执行
|
||||
- 命令可以生成代理以保留上下文
|
||||
- 所有 PM 命令 (`/pm:*`) 在主 README 中有文档说明
|
||||
- 命令遵循 `/rules/` 中定义的规则
|
||||
490
doc/README_ZH.md
Normal file
490
doc/README_ZH.md
Normal file
@@ -0,0 +1,490 @@
|
||||
# Claude Code 项目管理
|
||||
|
||||
[](https://automaze.io)
|
||||
|
||||
[](https://github.com/automazeio/ccpm/blob/main/README.md)
|
||||
[](https://github.com/automazeio/ccpm)
|
||||
|
||||
[](https://github.com/automazeio/ccpm/blob/main/LICENSE)
|
||||
|
||||
[](http://x.com/intent/follow?screen_name=aroussi)
|
||||
|
||||
[](https://github.com/automazeio/ccpm)
|
||||
|
||||
### 使用规范驱动开发、GitHub issues、Git worktrees和并行运行的多个AI代理来交付~~更快~~_更好的_ Claude Code工作流程。
|
||||
|
||||
停止丢失上下文。停止在任务上阻塞。停止交付bug。这个经过实战检验的系统将PRD转化为史诗任务，将史诗任务分解为GitHub issues，并将issues转化为生产代码——每一步都有完整的可追溯性。
|
||||
|
||||
|
||||
|
||||
## 目录
|
||||
|
||||
- [背景](#背景)
|
||||
- [工作流程](#工作流程)
|
||||
- [与众不同之处](#与众不同之处)
|
||||
- [为什么选择GitHub Issues？](#为什么选择github-issues)
|
||||
- [核心原则：拒绝凭感觉编码](#核心原则拒绝凭感觉编码)
|
||||
- [系统架构](#系统架构)
|
||||
- [工作流程阶段](#工作流程阶段)
|
||||
- [命令参考](#命令参考)
|
||||
- [并行执行系统](#并行执行系统)
|
||||
- [主要功能和优势](#主要功能和优势)
|
||||
- [已验证的结果](#已验证的结果)
|
||||
- [示例流程](#示例流程)
|
||||
- [立即开始](#立即开始)
|
||||
- [本地 vs 远程](#本地-vs-远程)
|
||||
- [技术说明](#技术说明)
|
||||
- [支持这个项目](#支持这个项目)
|
||||
|
||||
## 背景
|
||||
|
||||
每个团队都面临同样的问题：
|
||||
- **会话之间上下文丢失**，迫使不断重新发现
|
||||
- **并行工作在多个开发者接触相同代码时产生冲突**
|
||||
- **需求偏离**，口头决定覆盖书面规范
|
||||
- **进度在最后之前不可见**
|
||||
|
||||
这个系统解决了所有这些问题。
|
||||
|
||||
## 工作流程
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
A[PRD创建] --> B[史诗任务规划]
|
||||
B --> C[任务分解]
|
||||
C --> D[GitHub同步]
|
||||
D --> E[并行执行]
|
||||
```
|
||||
|
||||
### 实际操作演示（60秒）
|
||||
|
||||
```bash
|
||||
# 通过引导式头脑风暴创建全面的PRD
|
||||
/pm:prd-new memory-system
|
||||
|
||||
# 将PRD转化为技术史诗任务并进行任务分解
|
||||
/pm:prd-parse memory-system
|
||||
|
||||
# 推送到GitHub并开始并行执行
|
||||
/pm:epic-oneshot memory-system
|
||||
/pm:issue-start 1235
|
||||
```
|
||||
|
||||
## 与众不同之处
|
||||
|
||||
| 传统开发 | Claude Code PM系统 |
|
||||
| -------------------- | ---------------------------------- |
|
||||
| 会话之间丢失上下文 | **跨所有工作的持久上下文** |
|
||||
| 串行任务执行 | **并行代理处理独立任务** |
|
||||
| 从记忆中"凭感觉编码" | **规范驱动，全程可追溯** |
|
||||
| 进度隐藏在分支中 | **GitHub中的透明审计轨迹** |
|
||||
| 手动任务协调 | **智能优先级排序，使用`/pm:next`** |
|
||||
|
||||
## 为什么选择GitHub Issues？
|
||||
|
||||
大多数Claude Code工作流程在孤立环境中运行——单个开发者在本地环境中与AI协作。这产生了一个根本问题：**AI辅助开发变成了孤岛**。
|
||||
|
||||
通过使用GitHub Issues作为我们的数据库，我们解锁了强大的功能：
|
||||
|
||||
### 🤝 **真正的团队协作**
|
||||
- 多个Claude实例可以同时处理同一项目
|
||||
- 人类开发者通过issue评论实时查看AI进度
|
||||
- 团队成员可以随时加入——上下文始终可见
|
||||
- 管理者获得透明度而无需中断流程
|
||||
|
||||
### 🔄 **无缝的人机交接**
|
||||
- AI可以开始任务，人类可以完成任务（反之亦然）
|
||||
- 进度更新对每个人可见，不会困在聊天记录中
|
||||
- 代码审查通过PR评论自然发生
|
||||
- 无需召开"AI做了什么？"会议
|
||||
|
||||
### 📈 **超越个人工作的可扩展性**
|
||||
- 添加团队成员无需繁琐的入职流程
|
||||
- 多个AI代理并行处理不同issues
|
||||
- 分布式团队自动保持同步
|
||||
- 与现有的GitHub工作流程和工具兼容
|
||||
|
||||
### 🎯 **单一真相来源**
|
||||
- 无需单独的数据库或项目管理工具
|
||||
- Issue状态即项目状态
|
||||
- 评论即审计轨迹
|
||||
- 标签提供组织结构
|
||||
|
||||
这不仅仅是一个项目管理系统——它是一个**协作协议**，让人类和AI代理能够大规模协作，使用团队已经信任的基础设施。
|
||||
|
||||
## 核心原则：拒绝凭感觉编码
|
||||
|
||||
> **每一行代码都必须可追溯到规范。**
|
||||
|
||||
我们遵循严格的5阶段纪律：
|
||||
|
||||
1. **🧠 头脑风暴** - 深入思考
|
||||
2. **📝 文档化** - 编写不留任何解释空间的规范
|
||||
3. **📐 规划** - 通过明确的技术决策进行架构设计
|
||||
4. **⚡ 执行** - 精确构建规范中指定的内容
|
||||
5. **📊 跟踪** - 在每一步保持透明进度
|
||||
|
||||
不走捷径。不做假设。不留遗憾。
|
||||
|
||||
## 系统架构
|
||||
|
||||
```
|
||||
.claude/
|
||||
├── CLAUDE.md # 始终在线的指令（将内容复制到项目的CLAUDE.md文件中）
|
||||
├── agents/ # 面向任务的代理（用于上下文保存）
|
||||
├── commands/ # 命令定义
|
||||
│ ├── context/ # 创建、更新和准备上下文
|
||||
│ ├── pm/ # ← 项目管理命令（此系统）
|
||||
│ └── testing/ # 准备和执行测试（编辑此部分）
|
||||
├── context/ # 项目范围的上下文文件
|
||||
├── epics/ # ← PM的本地工作区（放入.gitignore中）
|
||||
│ └── [epic-name]/ # 史诗任务和相关任务
|
||||
│ ├── epic.md # 实现计划
|
||||
│ ├── [#].md # 单个任务文件
|
||||
│ └── updates/ # 进行中的更新
|
||||
├── prds/ # ← PM的PRD文件
|
||||
├── rules/ # 将任何规则文件放在此处以供引用
|
||||
└── scripts/ # 将任何脚本文件放在此处以供使用
|
||||
```
|
||||
|
||||
## 工作流程阶段
|
||||
|
||||
### 1. 产品规划阶段
|
||||
|
||||
```bash
|
||||
/pm:prd-new feature-name
|
||||
```
|
||||
启动全面的头脑风暴，创建产品需求文档，捕捉愿景、用户故事、成功标准和约束条件。
|
||||
|
||||
**输出：** `.claude/prds/feature-name.md`
|
||||
|
||||
### 2. 实现规划阶段
|
||||
|
||||
```bash
|
||||
/pm:prd-parse feature-name
|
||||
```
|
||||
将PRD转化为技术实现计划，包含架构决策、技术方法和依赖映射。
|
||||
|
||||
**输出：** `.claude/epics/feature-name/epic.md`
|
||||
|
||||
### 3. 任务分解阶段
|
||||
|
||||
```bash
|
||||
/pm:epic-decompose feature-name
|
||||
```
|
||||
将史诗任务分解为具体的、可操作的任务，包含验收标准、工作量估算和并行化标志。
|
||||
|
||||
**输出：** `.claude/epics/feature-name/[task].md`
|
||||
|
||||
### 4. GitHub同步
|
||||
|
||||
```bash
|
||||
/pm:epic-sync feature-name
|
||||
# 或对于自信的工作流程：
|
||||
/pm:epic-oneshot feature-name
|
||||
```
|
||||
将史诗任务和任务作为issues推送到GitHub，带有适当的标签和关系。
|
||||
|
||||
### 5. 执行阶段
|
||||
|
||||
```bash
|
||||
/pm:issue-start 1234 # 启动专门代理
|
||||
/pm:issue-sync 1234 # 推送进度更新
|
||||
/pm:next # 获取下一个优先任务
|
||||
```
|
||||
专门代理实现任务，同时保持进度更新和审计轨迹。
|
||||
|
||||
## 命令参考
|
||||
|
||||
> [!TIP]
|
||||
> 输入`/pm:help`获取简洁的命令摘要
|
||||
|
||||
### 初始设置
|
||||
- `/pm:init` - 安装依赖并配置GitHub
|
||||
|
||||
### PRD命令
|
||||
- `/pm:prd-new` - 为新产品需求启动头脑风暴
|
||||
- `/pm:prd-parse` - 将PRD转换为实现史诗任务
|
||||
- `/pm:prd-list` - 列出所有PRD
|
||||
- `/pm:prd-edit` - 编辑现有PRD
|
||||
- `/pm:prd-status` - 显示PRD实现状态
|
||||
|
||||
### 史诗任务命令
|
||||
- `/pm:epic-decompose` - 将史诗任务分解为任务文件
|
||||
- `/pm:epic-sync` - 将史诗任务和任务推送到GitHub
|
||||
- `/pm:epic-oneshot` - 一次性分解和同步命令
|
||||
- `/pm:epic-list` - 列出所有史诗任务
|
||||
- `/pm:epic-show` - 显示史诗任务及其任务
|
||||
- `/pm:epic-close` - 标记史诗任务为完成
|
||||
- `/pm:epic-edit` - 编辑史诗任务详情
|
||||
- `/pm:epic-refresh` - 从任务更新史诗任务进度
|
||||
|
||||
### Issue命令
|
||||
- `/pm:issue-show` - 显示issue和子issues
|
||||
- `/pm:issue-status` - 检查issue状态
|
||||
- `/pm:issue-start` - 开始工作并启动专门代理
|
||||
- `/pm:issue-sync` - 将更新推送到GitHub
|
||||
- `/pm:issue-close` - 标记issue为完成
|
||||
- `/pm:issue-reopen` - 重新打开已关闭的issue
|
||||
- `/pm:issue-edit` - 编辑issue详情
|
||||
|
||||
### 工作流程命令
|
||||
- `/pm:next` - 显示下一个优先issue及史诗任务上下文
|
||||
- `/pm:status` - 整体项目仪表板
|
||||
- `/pm:standup` - 每日站会报告
|
||||
- `/pm:blocked` - 显示被阻塞的任务
|
||||
- `/pm:in-progress` - 列出进行中的工作
|
||||
|
||||
### 同步命令
|
||||
- `/pm:sync` - 与GitHub的双向同步
|
||||
- `/pm:import` - 导入现有的GitHub issues
|
||||
|
||||
### 维护命令
|
||||
- `/pm:validate` - 检查系统完整性
|
||||
- `/pm:clean` - 归档已完成的工作
|
||||
- `/pm:search` - 搜索所有内容
|
||||
|
||||
## 并行执行系统
|
||||
|
||||
### Issues并非原子性的
|
||||
|
||||
传统思维：一个issue = 一个开发者 = 一个任务
|
||||
|
||||
**现实：一个issue = 多个并行工作流**
|
||||
|
||||
单个"实现用户认证"issue不是一个任务。它是...
|
||||
|
||||
- **代理1**：数据库表和迁移
|
||||
- **代理2**：服务层和业务逻辑
|
||||
- **代理3**：API端点和中间件
|
||||
- **代理4**：UI组件和表单
|
||||
- **代理5**：测试套件和文档
|
||||
|
||||
所有这些都在同一工作树中**同时**运行。
|
||||
|
||||
### 速度的数学计算
|
||||
|
||||
**传统方法：**
|
||||
- 包含3个issues的史诗任务
|
||||
- 串行执行
|
||||
|
||||
**本系统：**
|
||||
- 同样的史诗任务包含3个issues
|
||||
- 每个issue分解为约4个并行流
|
||||
- **12个代理同时工作**
|
||||
|
||||
我们不是将代理分配给issues。我们是**利用多个代理**来更快交付。
|
||||
|
||||
### 上下文优化
|
||||
|
||||
**传统的单线程方法：**
|
||||
- 主对话承载所有实现细节
|
||||
- 上下文窗口填满了数据库模式、API代码、UI组件
|
||||
- 最终达到上下文限制并失去连贯性
|
||||
|
||||
**并行代理方法：**
|
||||
- 主线程保持干净和战略性
|
||||
- 每个代理独立处理自己的上下文
|
||||
- 实现细节从不污染主对话
|
||||
- 主线程保持监督而不会淹没在代码中
|
||||
|
||||
你的主对话成为指挥家，而不是管弦乐队。
|
||||
|
||||
### GitHub vs 本地：完美分离
|
||||
|
||||
**GitHub看到的内容：**
|
||||
- 干净、简单的issues
|
||||
- 进度更新
|
||||
- 完成状态
|
||||
|
||||
**本地实际发生的事情：**
|
||||
- Issue #1234分解为5个并行代理
|
||||
- 代理通过Git提交进行协调
|
||||
- 复杂的编排对视图隐藏
|
||||
|
||||
GitHub无需知道工作是如何完成的——只需知道工作已完成。
|
||||
|
||||
### 命令流程
|
||||
|
||||
```bash
|
||||
# 分析可以并行化的内容
|
||||
/pm:issue-analyze 1234
|
||||
|
||||
# 启动集群
|
||||
/pm:epic-start multi-agent-collaboration
|
||||
|
||||
# 观看奇迹发生
|
||||
# 12个代理在3个issues上工作
|
||||
# 全部在：../epic-memory-system/中
|
||||
|
||||
# 完成时进行一次干净的合并
|
||||
/pm:epic-merge memory-system
|
||||
```
|
||||
|
||||
## 主要功能和优势
|
||||
|
||||
### 🧠 **上下文保存**
|
||||
永不丢失项目状态。每个史诗任务维护自己的上下文，代理从`.claude/context/`读取，并在同步前本地更新。
|
||||
|
||||
### ⚡ **并行执行**
|
||||
通过多个代理同时工作来更快交付。标记为`parallel: true`的任务支持无冲突的并发开发。
|
||||
|
||||
### 🔗 **GitHub原生**
|
||||
与团队已使用的工具兼容。Issues是真相来源，评论提供历史，不依赖Projects API。
|
||||
|
||||
### 🤖 **代理专业化**
|
||||
每项工作都有合适的工具。不同的代理处理UI、API和数据库工作。每个代理自动读取需求并发布更新。
|
||||
|
||||
### 📊 **全程可追溯**
|
||||
每个决策都有文档记录。PRD → 史诗任务 → 任务 → Issue → 代码 → 提交。从想法到生产的完整审计轨迹。
|
||||
|
||||
### 🚀 **开发者生产力**
|
||||
专注于构建，而非管理。智能优先级排序，自动上下文加载，准备就绪时增量同步。
|
||||
|
||||
## 已验证的结果
|
||||
|
||||
使用此系统的团队报告：
|
||||
- **89%的时间**不再因上下文切换而丢失——你将很少使用`/compact`和`/clear`
|
||||
- **5-8个并行任务** vs 之前的1个——同时编辑/测试多个文件
|
||||
- **bug率降低75%**——由于将功能分解为详细任务
|
||||
- **功能交付速度提升3倍**——基于功能大小和复杂度
|
||||
|
||||
## 示例流程
|
||||
|
||||
```bash
|
||||
# 开始新功能
|
||||
/pm:prd-new memory-system
|
||||
|
||||
# 审查和完善PRD...
|
||||
|
||||
# 创建实现计划
|
||||
/pm:prd-parse memory-system
|
||||
|
||||
# 审查史诗任务...
|
||||
|
||||
# 分解为任务并推送到GitHub
|
||||
/pm:epic-oneshot memory-system
|
||||
# 创建issues：#1234（史诗任务），#1235，#1236（任务）
|
||||
|
||||
# 开始任务开发
|
||||
/pm:issue-start 1235
|
||||
# 代理开始工作，在本地维护进度
|
||||
|
||||
# 同步进度到GitHub
|
||||
/pm:issue-sync 1235
|
||||
# 更新作为issue评论发布
|
||||
|
||||
# 检查整体状态
|
||||
/pm:epic-show multi-agent-collaboration
|
||||
```
|
||||
|
||||
## 立即开始
|
||||
|
||||
### 快速设置（2分钟）
|
||||
|
||||
1. **将此仓库安装到你的项目中**：
|
||||
|
||||
#### Unix/Linux/macOS
|
||||
|
||||
```bash
|
||||
cd path/to/your/project/
|
||||
curl -sSL https://raw.githubusercontent.com/automazeio/ccpm/main/ccpm.sh | bash
|
||||
# 或：wget -qO- https://raw.githubusercontent.com/automazeio/ccpm/main/ccpm.sh | bash
|
||||
```
|
||||
|
||||
#### Windows（PowerShell）
|
||||
```bash
|
||||
cd path/to/your/project/
|
||||
iwr -useb https://raw.githubusercontent.com/automazeio/ccpm/main/ccpm.bat | iex
|
||||
```
|
||||
> ⚠️ **重要**：如果你已有`.claude`目录，请将此仓库克隆到不同目录，然后将克隆的`.claude`目录内容复制到你项目的`.claude`目录中。
|
||||
|
||||
查看完整的/其他安装选项在[安装指南 ›](https://github.com/automazeio/ccpm/tree/main/install)中
|
||||
|
||||
|
||||
2. **初始化PM系统**：
|
||||
```bash
|
||||
/pm:init
|
||||
```
|
||||
此命令将：
|
||||
- 安装GitHub CLI（如需要）
|
||||
- 与GitHub进行身份验证
|
||||
- 安装[gh-sub-issue扩展](https://github.com/yahsan2/gh-sub-issue)以建立正确的父子关系
|
||||
- 创建所需目录
|
||||
- 更新.gitignore
|
||||
|
||||
3. **创建包含仓库信息的`CLAUDE.md`**
|
||||
```bash
|
||||
/init include rules from .claude/CLAUDE.md
|
||||
```
|
||||
> 如果你已有`CLAUDE.md`文件，运行：`/re-init`来用`.claude/CLAUDE.md`中的重要规则更新它。
|
||||
|
||||
4. **准备系统**：
|
||||
```bash
|
||||
/context:create
|
||||
```
|
||||
|
||||
|
||||
|
||||
### 开始你的第一个功能
|
||||
|
||||
```bash
|
||||
/pm:prd-new your-feature-name
|
||||
```
|
||||
|
||||
观看结构化规划如何转化为交付的代码。
|
||||
|
||||
## 本地 vs 远程
|
||||
|
||||
| 操作 | 本地 | GitHub |
|
||||
| ---------- | ---- | --------- |
|
||||
| PRD创建 | ✅ | — |
|
||||
| 实现规划 | ✅ | — |
|
||||
| 任务分解 | ✅ | ✅（同步） |
|
||||
| 执行 | ✅ | — |
|
||||
| 状态更新 | ✅ | ✅（同步） |
|
||||
| 最终交付物 | — | ✅ |
|
||||
|
||||
## 技术说明
|
||||
|
||||
### GitHub集成
|
||||
- 使用**gh-sub-issue扩展**建立正确的父子关系
|
||||
- 如果未安装扩展则回退到任务列表
|
||||
- 史诗任务issues自动跟踪子任务完成情况
|
||||
- 标签提供额外组织（`epic:feature`，`task:feature`）
|
||||
|
||||
### 文件命名约定
|
||||
- 任务在分解期间以`001.md`，`002.md`开始
|
||||
- GitHub同步后，重命名为`{issue-id}.md`（例如，`1234.md`）
|
||||
- 便于导航：issue #1234 = 文件`1234.md`
|
||||
|
||||
### 设计决策
|
||||
- 故意避免GitHub Projects API的复杂性
|
||||
- 所有命令首先在本地文件上操作以提高速度
|
||||
- 与GitHub的同步是明确且受控的
|
||||
- Worktrees为并行工作提供干净的git隔离
|
||||
- GitHub Projects可以单独添加用于可视化
|
||||
|
||||
---
|
||||
|
||||
## 支持这个项目
|
||||
|
||||
Claude Code PM由[Automaze](https://automaze.io)开发，**为交付产品的开发者，由交付产品的开发者**。
|
||||
|
||||
如果Claude Code PM帮助你的团队交付更好的软件：
|
||||
|
||||
- ⭐ **[给这个仓库点赞](https://github.com/automazeio/ccpm)** 来表达你的支持
|
||||
- 🐦 **[在X上关注@aroussi](https://x.com/aroussi)** 获取更新和提示
|
||||
|
||||
|
||||
---
|
||||
|
||||
> [!TIP]
|
||||
> **使用Automaze更快交付。** 我们与创始人合作，将他们的愿景变为现实，扩展他们的业务，并优化成功。
|
||||
> **[访问Automaze与我预约通话 ›](https://automaze.io)**
|
||||
|
||||
---
|
||||
|
||||
## 点赞历史
|
||||
|
||||
|
||||
Reference in New Issue
Block a user