collaborative-plan-with-file
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseCollaborative-Plan-With-File Workflow
基于文件的协作规划工作流
Quick Start
快速开始
Serial collaborative planning workflow using Plan Note architecture. Analyzes requirements, identifies sub-domains, generates detailed plans per domain serially, and detects conflicts across domains.
bash
undefined采用Plan Note架构的串行协作规划工作流。分析需求、识别子领域、为每个领域串行生成详细规划,并检测跨领域冲突。
bash
undefinedBasic usage
基础用法
/codex:collaborative-plan-with-file "Implement real-time notification system"
/codex:collaborative-plan-with-file "实现实时通知系统"
With options
带选项用法
/codex:collaborative-plan-with-file "Refactor authentication module" --max-domains=4
/codex:collaborative-plan-with-file "Add payment gateway support" -y
**Core workflow**: Understand → Template → Serial Domain Planning → Conflict Detection → Completion
**Key features**:
- **plan-note.md**: Shared collaborative document with pre-allocated sections per domain
- **Serial domain planning**: Each sub-domain planned sequentially with full codebase context
- **Conflict detection**: Automatic file, dependency, and strategy conflict scanning
- **No merge needed**: Pre-allocated sections eliminate merge conflicts/codex:collaborative-plan-with-file "重构认证模块" --max-domains=4
/codex:collaborative-plan-with-file "添加支付网关支持" -y
**核心工作流**:理解需求 → 生成模板 → 串行领域规划 → 冲突检测 → 完成规划
**关键特性**:
- **plan-note.md**:为每个领域预分配章节的共享协作文档
- **串行领域规划**:每个子领域在完整代码库上下文下按顺序规划
- **冲突检测**:自动扫描文件、依赖和策略冲突
- **无需合并**:预分配章节消除了合并冲突Auto Mode
自动模式
When or : Auto-approve splits, skip confirmations.
--yes-y当使用或参数时:自动批准拆分,跳过确认步骤。
--yes-yOverview
工作流概述
This workflow enables structured planning through sequential phases:
- Understanding & Template — Analyze requirements, identify sub-domains, create plan-note.md template
- Serial Domain Planning — Plan each sub-domain sequentially using direct search and analysis
- Conflict Detection — Scan plan-note.md for conflicts across all domains
- Completion — Generate human-readable plan.md summary
The key innovation is the Plan Note architecture — a shared collaborative document with pre-allocated sections per sub-domain, eliminating merge conflicts even in serial execution.
┌─────────────────────────────────────────────────────────────────────────┐
│ PLAN NOTE COLLABORATIVE PLANNING │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ Phase 1: Understanding & Template Creation │
│ ├─ Analyze requirements (inline search & analysis) │
│ ├─ Identify 2-5 sub-domains (focus areas) │
│ ├─ Create plan-note.md with pre-allocated sections │
│ └─ Assign TASK ID ranges (no conflicts) │
│ │
│ Phase 2: Serial Domain Planning │
│ ┌──────────────┐ │
│ │ Domain 1 │→ Explore codebase → Generate .task/TASK-*.json │
│ │ Section 1 │→ Fill task pool + evidence in plan-note.md │
│ └──────┬───────┘ │
│ ┌──────▼───────┐ │
│ │ Domain 2 │→ Explore codebase → Generate .task/TASK-*.json │
│ │ Section 2 │→ Fill task pool + evidence in plan-note.md │
│ └──────┬───────┘ │
│ ┌──────▼───────┐ │
│ │ Domain N │→ ... │
│ └──────────────┘ │
│ │
│ Phase 3: Conflict Detection (Single Source) │
│ ├─ Parse plan-note.md (all sections) │
│ ├─ Detect file/dependency/strategy conflicts │
│ └─ Update plan-note.md conflict section │
│ │
│ Phase 4: Completion (No Merge) │
│ ├─ Collect domain .task/*.json → session .task/*.json │
│ ├─ Generate plan.md (human-readable) │
│ └─ Ready for execution │
│ │
└─────────────────────────────────────────────────────────────────────────┘该工作流通过以下连续阶段实现结构化规划:
- 需求理解与模板生成 — 分析需求、识别子领域、创建plan-note.md模板
- 串行领域规划 — 使用直接搜索和分析功能,按顺序规划每个子领域
- 冲突检测 — 扫描plan-note.md以检测跨领域冲突
- 规划完成 — 生成易读的plan.md摘要
核心创新点是Plan Note架构——一个为每个子领域预分配章节的共享协作文档,即使在串行执行时也能消除合并冲突。
┌─────────────────────────────────────────────────────────────────────────┐
│ PLAN NOTE 协作规划框架 │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ 阶段1:需求理解与模板创建 │
│ ├─ 分析需求(内置搜索与分析工具) │
│ ├─ 识别2-5个子领域(重点方向) │
│ ├─ 创建包含预分配章节的plan-note.md文档 │
│ └─ 分配无冲突的TASK ID范围 │
│ │
│ 阶段2:串行领域规划 │
│ ┌──────────────┐ │
│ │ 领域1 │→ 探索代码库 → 生成 .task/TASK-*.json │
│ │ 章节1 │→ 填充任务池并更新plan-note.md中的证据部分 │
│ └──────┬───────┘ │
│ ┌──────▼───────┐ │
│ │ 领域2 │→ 探索代码库 → 生成 .task/TASK-*.json │
│ │ 章节2 │→ 填充任务池并更新plan-note.md中的证据部分 │
│ └──────┬───────┘ │
│ ┌──────▼───────┐ │
│ │ 领域N │→ ... │
│ └──────────────┘ │
│ │
│ 阶段3:冲突检测(单一数据源) │
│ ├─ 解析plan-note.md(所有章节) │
│ ├─ 检测文件/依赖/策略冲突 │
│ └─ 更新plan-note.md的冲突章节 │
│ │
│ 阶段4:规划完成(无需合并) │
│ ├─ 收集各领域 .task/*.json → 会话级 .task/*.json │
│ ├─ 生成plan.md(易读摘要) │
│ └─ 准备执行 │
│ │
└─────────────────────────────────────────────────────────────────────────┘Output Structure
输出结构
Schema:cat ~/.ccw/workflows/cli-templates/schemas/task-schema.json
{projectRoot}/.workflow/.planning/CPLAN-{slug}-{date}/
├── plan-note.md # ⭐ Core: Requirements + Tasks + Conflicts
├── requirement-analysis.json # Phase 1: Sub-domain assignments
├── domains/ # Phase 2: Per-domain plans
│ ├── {domain-1}/
│ │ └── .task/ # Per-domain task JSON files
│ │ ├── TASK-001.json
│ │ └── ...
│ ├── {domain-2}/
│ │ └── .task/
│ │ ├── TASK-101.json
│ │ └── ...
│ └── ...
├── plan.json # Plan overview (plan-overview-base-schema.json)
├── .task/ # ⭐ Merged task JSON files (all domains)
│ ├── TASK-001.json
│ ├── TASK-101.json
│ └── ...
├── conflicts.json # Phase 3: Conflict report
└── plan.md # Phase 4: Human-readable summarySchema:cat ~/.ccw/workflows/cli-templates/schemas/task-schema.json
{projectRoot}/.workflow/.planning/CPLAN-{slug}-{date}/
├── plan-note.md # ⭐ 核心文件:需求 + 任务 + 冲突
├── requirement-analysis.json # 阶段1:子领域分配信息
├── domains/ # 阶段2:各领域规划文件
│ ├── {domain-1}/
│ │ └── .task/ # 各领域的任务JSON文件
│ │ ├── TASK-001.json
│ │ └── ...
│ ├── {domain-2}/
│ │ └── .task/
│ │ ├── TASK-101.json
│ │ └── ...
│ └── ...
├── plan.json # 规划概览(遵循plan-overview-base-schema.json)
├── .task/ # ⭐ 合并后的任务JSON文件(所有领域)
│ ├── TASK-001.json
│ ├── TASK-101.json
│ └── ...
├── conflicts.json # 阶段3:冲突报告
└── plan.md # 阶段4:易读摘要Output Artifacts
输出产物说明
Phase 1: Understanding & Template
阶段1:需求理解与模板创建
| Artifact | Purpose |
|---|---|
| Collaborative template with pre-allocated task pool and evidence sections per domain |
| Sub-domain assignments, TASK ID ranges, complexity assessment |
| 产物 | 用途 |
|---|---|
| 包含预分配任务池和证据章节的协作模板 |
| 子领域分配、TASK ID范围、复杂度评估 |
Phase 2: Serial Domain Planning
阶段2:串行领域规划
| Artifact | Purpose |
|---|---|
| Task JSON files per domain (one file per task with convergence) |
Updated | Task pool and evidence sections filled for each domain |
| 产物 | 用途 |
|---|---|
| 各领域的任务JSON文件(每个任务对应一个文件,包含验收标准) |
更新后的 | 填充了各领域任务池和证据章节的文档 |
Phase 3: Conflict Detection
阶段3:冲突检测
| Artifact | Purpose |
|---|---|
| Detected conflicts with types, severity, and resolutions |
Updated | Conflict markers section populated |
| 产物 | 用途 |
|---|---|
| 检测到的冲突,包含类型、严重程度和解决方案建议 |
更新后的 | 填充了冲突标记章节的文档 |
Phase 4: Completion
阶段4:规划完成
| Artifact | Purpose |
|---|---|
| Merged task JSON files from all domains (consumable by unified-execute) |
| Plan overview following plan-overview-base-schema.json |
| Human-readable summary with requirements, tasks, and conflicts |
| 产物 | 用途 |
|---|---|
| 合并所有领域的任务JSON文件(可被unified-execute执行) |
| 遵循plan-overview-base-schema.json的规划概览 |
| 包含需求、任务和冲突的易读摘要 |
Implementation Details
实现细节
Session Initialization
会话初始化
Step 0: Initialize Session
步骤0:初始化会话
javascript
const getUtc8ISOString = () => new Date(Date.now() + 8 * 60 * 60 * 1000).toISOString()
// Detect project root
const projectRoot = Bash(`git rev-parse --show-toplevel 2>/dev/null || pwd`).trim()
// Parse arguments
const autoMode = $ARGUMENTS.includes('--yes') || $ARGUMENTS.includes('-y')
const maxDomainsMatch = $ARGUMENTS.match(/--max-domains=(\d+)/)
const maxDomains = maxDomainsMatch ? parseInt(maxDomainsMatch[1]) : 5
// Clean task description
const taskDescription = $ARGUMENTS
.replace(/--yes|-y|--max-domains=\d+/g, '')
.trim()
const slug = taskDescription.toLowerCase()
.replace(/[^a-z0-9\u4e00-\u9fa5]+/g, '-')
.substring(0, 30)
const dateStr = getUtc8ISOString().substring(0, 10)
const sessionId = `CPLAN-${slug}-${dateStr}`
const sessionFolder = `${projectRoot}/.workflow/.planning/${sessionId}`
// Auto-detect continue: session folder + plan-note.md exists → continue mode
// If continue → load existing state and resume from incomplete phase
Bash(`mkdir -p ${sessionFolder}/domains`)Session Variables:
- : Unique session identifier
sessionId - : Base directory for all artifacts
sessionFolder - : Maximum number of sub-domains (default: 5)
maxDomains - : Boolean for auto-confirmation
autoMode
Auto-Detection: If session folder exists with plan-note.md, automatically enters continue mode.
javascript
const getUtc8ISOString = () => new Date(Date.now() + 8 * 60 * 60 * 1000).toISOString()
// 检测项目根目录
const projectRoot = Bash(`git rev-parse --show-toplevel 2>/dev/null || pwd`).trim()
// 解析参数
const autoMode = $ARGUMENTS.includes('--yes') || $ARGUMENTS.includes('-y')
const maxDomainsMatch = $ARGUMENTS.match(/--max-domains=(\d+)/)
const maxDomains = maxDomainsMatch ? parseInt(maxDomainsMatch[1]) : 5
// 清理任务描述
const taskDescription = $ARGUMENTS
.replace(/--yes|-y|--max-domains=\d+/g, '')
.trim()
const slug = taskDescription.toLowerCase()
.replace(/[^a-z0-9\u4e00-\u9fa5]+/g, '-')
.substring(0, 30)
const dateStr = getUtc8ISOString().substring(0, 10)
const sessionId = `CPLAN-${slug}-${dateStr}`
const sessionFolder = `${projectRoot}/.workflow/.planning/${sessionId}`
// 自动检测是否继续:若会话文件夹和plan-note.md存在 → 进入继续模式
// 若继续 → 加载现有状态并从未完成的阶段恢复
Bash(`mkdir -p ${sessionFolder}/domains`)会话变量:
- : 唯一会话标识符
sessionId - : 所有产物的基础目录
sessionFolder - : 最大子领域数量(默认:5)
maxDomains - : 自动确认的布尔值
autoMode
自动检测:若会话文件夹和plan-note.md已存在,自动进入继续模式。
Phase 1: Understanding & Template Creation
阶段1:需求理解与模板创建
Objective: Analyze task requirements, identify parallelizable sub-domains, and create the plan-note.md template with pre-allocated sections.
目标:分析任务需求,识别可并行的子领域,并创建包含预分配章节的plan-note.md模板。
Step 1.1: Analyze Task Description
步骤1.1:分析任务描述
Use built-in tools directly to understand the task scope and identify sub-domains.
Analysis Activities:
- Search for references — Find related documentation, README files, and architecture guides
- Use: , Grep, Glob, Read
mcp__ace-tool__search_context - Run: (if spec system available)
ccw spec load --category planning
- Use:
- Extract task keywords — Identify key terms and concepts from the task description
- Identify ambiguities — List any unclear points or multiple possible interpretations
- Clarify with user — If ambiguities found, use AskUserQuestion for clarification
- Identify sub-domains — Split into 2-{maxDomains} parallelizable focus areas based on task complexity
- Assess complexity — Evaluate overall task complexity (Low/Medium/High)
Sub-Domain Identification Patterns:
| Pattern | Keywords |
|---|---|
| Backend API | 服务, 后端, API, 接口 |
| Frontend | 界面, 前端, UI, 视图 |
| Database | 数据, 存储, 数据库, 持久化 |
| Testing | 测试, 验证, QA |
| Infrastructure | 部署, 基础, 运维, 配置 |
Guideline: Prioritize identifying latest documentation (README, design docs, architecture guides). When ambiguities exist, ask user for clarification instead of assuming interpretations.
使用内置工具直接理解任务范围并识别子领域。
分析活动:
- 搜索参考资料 — 查找相关文档、README文件和架构指南
- 使用工具:、Grep、Glob、Read
mcp__ace-tool__search_context - 执行命令:(若规范系统可用)
ccw spec load --category planning
- 使用工具:
- 提取任务关键词 — 从任务描述中识别关键术语和概念
- 识别歧义点 — 列出所有不明确的点或多种可能的解释
- 与用户确认 — 若发现歧义,使用AskUserQuestion工具向用户澄清
- 识别子领域 — 根据任务复杂度拆分为2-{maxDomains}个可并行的重点方向
- 评估复杂度 — 评估整体任务复杂度(低/中/高)
子领域识别模式:
| 模式 | 关键词 |
|---|---|
| 后端API | 服务, 后端, API, 接口 |
| 前端 | 界面, 前端, UI, 视图 |
| 数据库 | 数据, 存储, 数据库, 持久化 |
| 测试 | 测试, 验证, QA |
| 基础设施 | 部署, 基础, 运维, 配置 |
指导原则:优先识别最新文档(README、设计文档、架构指南)。当存在歧义时,向用户澄清而非自行假设。
Step 1.2: Create plan-note.md Template
步骤1.2:创建plan-note.md模板
Generate a structured template with pre-allocated sections for each sub-domain.
plan-note.md Structure:
yaml
---
session_id: CPLAN-{slug}-{date}
original_requirement: "{task description}"
created_at: "{ISO timestamp}"
complexity: Low | Medium | High
sub_domains: ["{domain-1}", "{domain-2}", ...]
domain_task_id_ranges:
"{domain-1}": [1, 100]
"{domain-2}": [101, 200]
status: planning
---Sections:
- — Core objectives, key points, constraints, split strategy
## 需求理解 - — Pre-allocated task section per domain (TASK-{range})
## 任务池 - {Domain N} - — Auto-generated after all domains complete
## 依赖关系 - — Populated in Phase 3
## 冲突标记 - — Evidence section per domain
## 上下文证据 - {Domain N}
TASK ID Range Allocation: Each domain receives a non-overlapping range of 100 IDs (e.g., Domain 1: TASK-001100, Domain 2: TASK-101200).
生成包含各子领域预分配章节的结构化模板。
plan-note.md结构:
yaml
---
session_id: CPLAN-{slug}-{date}
original_requirement: "{task description}"
created_at: "{ISO timestamp}"
complexity: Low | Medium | High
sub_domains: ["{domain-1}", "{domain-2}", ...]
domain_task_id_ranges:
"{domain-1}": [1, 100]
"{domain-2}": [101, 200]
status: planning
---章节:
- — 核心目标、关键点、约束条件、拆分策略
## 需求理解 - — 每个领域的预分配任务章节(TASK-{range})
## 任务池 - {Domain N} - — 所有领域规划完成后自动生成
## 依赖关系 - — 阶段3中填充
## 冲突标记 - — 每个领域的证据章节
## 上下文证据 - {Domain N}
TASK ID范围分配:每个领域分配100个不重叠的ID(例如:领域1:TASK-001100,领域2:TASK-101200)。
Step 1.3: Generate requirement-analysis.json
步骤1.3:生成requirement-analysis.json
javascript
Write(`${sessionFolder}/requirement-analysis.json`, JSON.stringify({
session_id: sessionId,
original_requirement: taskDescription,
complexity: complexity, // Low | Medium | High
sub_domains: subDomains.map(sub => ({
focus_area: sub.focus_area,
description: sub.description,
task_id_range: sub.task_id_range,
estimated_effort: sub.estimated_effort,
dependencies: sub.dependencies // cross-domain dependencies
})),
total_domains: subDomains.length
}, null, 2))Success Criteria:
- Latest documentation identified and referenced (if available)
- Ambiguities resolved via user clarification (if any found)
- 2-{maxDomains} clear sub-domains identified
- Each sub-domain can be planned independently
- Plan Note template includes all pre-allocated sections
- TASK ID ranges have no overlap (100 IDs per domain)
- Requirements understanding is comprehensive
javascript
Write(`${sessionFolder}/requirement-analysis.json`, JSON.stringify({
session_id: sessionId,
original_requirement: taskDescription,
complexity: complexity, // Low | Medium | High
sub_domains: subDomains.map(sub => ({
focus_area: sub.focus_area,
description: sub.description,
task_id_range: sub.task_id_range,
estimated_effort: sub.estimated_effort,
dependencies: sub.dependencies // 跨领域依赖
})),
total_domains: subDomains.length
}, null, 2))成功标准:
- 已识别并引用最新文档(若可用)
- 歧义点已通过用户澄清解决(若有)
- 已识别2-{maxDomains}个清晰的子领域
- 每个子领域可独立规划
- Plan Note模板包含所有预分配章节
- TASK ID范围无重叠(每个领域100个ID)
- 需求理解全面
Phase 2: Serial Sub-Domain Planning
阶段2:串行子领域规划
Objective: Plan each sub-domain sequentially, generating detailed plans and updating plan-note.md.
Execution Model: Serial inline execution — each domain explored and planned directly using search tools, one at a time.
目标:按顺序规划每个子领域,生成详细规划并更新plan-note.md。
执行模式:串行内置执行 — 每个领域依次使用搜索工具进行探索和规划。
Step 2.1: User Confirmation (unless autoMode)
步骤2.1:用户确认(自动模式除外)
Display identified sub-domains and confirm before starting.
javascript
if (!autoMode) {
AskUserQuestion({
questions: [{
question: `已识别 ${subDomains.length} 个子领域:\n${subDomains.map((s, i) =>
`${i+1}. ${s.focus_area}: ${s.description}`).join('\n')}\n\n确认开始规划?`,
header: "Confirm",
multiSelect: false,
options: [
{ label: "开始规划", description: "逐域进行规划" },
{ label: "调整拆分", description: "修改子领域划分" },
{ label: "取消", description: "退出规划" }
]
}]
})
}显示已识别的子领域并在开始前确认。
javascript
if (!autoMode) {
AskUserQuestion({
questions: [{
question: `已识别 ${subDomains.length} 个子领域:\n${subDomains.map((s, i) =>
`${i+1}. ${s.focus_area}: ${s.description}`).join('\n')}\n\n确认开始规划?`,
header: "确认",
multiSelect: false,
options: [
{ label: "开始规划", description: "逐域进行规划" },
{ label: "调整拆分", description: "修改子领域划分" },
{ label: "取消", description: "退出规划" }
]
}]
})
}Step 2.2: Serial Domain Planning
步骤2.2:串行领域规划
For each sub-domain, execute the full planning cycle inline:
javascript
for (const sub of subDomains) {
// 1. Create domain directory with .task/ subfolder
Bash(`mkdir -p ${sessionFolder}/domains/${sub.focus_area}/.task`)
// 2. Explore codebase for domain-relevant context
// Use: mcp__ace-tool__search_context, Grep, Glob, Read
// Focus on:
// - Modules/components related to this domain
// - Existing patterns to follow
// - Integration points with other domains
// - Architecture constraints
// 3. Generate task JSON records (following task-schema.json)
const domainTasks = [
// For each task within the assigned ID range:
{
id: `TASK-${String(sub.task_id_range[0]).padStart(3, '0')}`,
title: "...",
description: "...", // scope/goal of this task
type: "feature", // infrastructure|feature|enhancement|fix|refactor|testing
priority: "medium", // high|medium|low
effort: "medium", // small|medium|large
scope: "...", // Brief scope description
depends_on: [], // TASK-xxx references
convergence: {
criteria: ["... (testable)"], // Testable conditions
verification: "... (executable)", // Command or steps
definition_of_done: "... (business language)"
},
files: [ // Files to modify
{
path: "...",
action: "modify", // modify|create|delete
changes: ["..."], // Change descriptions
conflict_risk: "low" // low|medium|high
}
],
source: {
tool: "collaborative-plan-with-file",
session_id: sessionId,
original_id: `TASK-${String(sub.task_id_range[0]).padStart(3, '0')}`
}
}
// ... more tasks
]
// 4. Write individual task JSON files (one per task)
domainTasks.forEach(task => {
Write(`${sessionFolder}/domains/${sub.focus_area}/.task/${task.id}.json`,
JSON.stringify(task, null, 2))
})
// 5. Sync summary to plan-note.md
// Read current plan-note.md
// Locate pre-allocated sections:
// - Task Pool: "## 任务池 - ${toTitleCase(sub.focus_area)}"
// - Evidence: "## 上下文证据 - ${toTitleCase(sub.focus_area)}"
// Fill with task summaries and evidence
// Write back plan-note.md
}Task Summary Format (for plan-note.md task pool sections):
markdown
undefined对每个子领域,依次执行完整的规划周期:
javascript
for (const sub of subDomains) {
// 1. 创建领域目录及.task/子文件夹
Bash(`mkdir -p ${sessionFolder}/domains/${sub.focus_area}/.task`)
// 2. 探索与该领域相关的代码库上下文
// 使用工具:mcp__ace-tool__search_context、Grep、Glob、Read
// 重点关注:
// - 与该领域相关的模块/组件
// - 需遵循的现有模式
// - 与其他领域的集成点
// - 架构约束
// 3. 生成任务JSON记录(遵循task-schema.json)
const domainTasks = [
// 每个任务对应分配的ID范围:
{
id: `TASK-${String(sub.task_id_range[0]).padStart(3, '0')}`,
title: "...",
description: "...", // 任务范围/目标
type: "feature", // infrastructure|feature|enhancement|fix|refactor|testing
priority: "medium", // high|medium|low
effort: "medium", // small|medium|large
scope: "...", // 简要范围描述
depends_on: [], // TASK-xxx 引用
convergence: {
criteria: ["... (可测试)"], // 可测试的验收条件
verification: "... (可执行)", // 验证命令或步骤
definition_of_done: "... (业务语言描述)"
},
files: [ // 需修改的文件
{
path: "...",
action: "modify", // modify|create|delete
changes: ["..."], // 变更描述
conflict_risk: "low" // low|medium|high
}
],
source: {
tool: "collaborative-plan-with-file",
session_id: sessionId,
original_id: `TASK-${String(sub.task_id_range[0]).padStart(3, '0')}`
}
}
// ... 更多任务
]
// 4. 写入单个任务JSON文件(每个任务一个文件)
domainTasks.forEach(task => {
Write(`${sessionFolder}/domains/${sub.focus_area}/.task/${task.id}.json`,
JSON.stringify(task, null, 2))
})
// 5. 将摘要同步到plan-note.md
// 读取当前plan-note.md
// 定位预分配章节:
// - 任务池: "## 任务池 - ${toTitleCase(sub.focus_area)}"
// - 证据: "## 上下文证据 - ${toTitleCase(sub.focus_area)}"
// 填充任务摘要和证据
// 写回plan-note.md
}任务摘要格式(用于plan-note.md的任务池章节):
markdown
undefinedTASK-{ID}: {Title} [{focus-area}]
TASK-{ID}: {Title} [{focus-area}]
- 状态: pending
- 类型: feature/fix/refactor/enhancement/testing/infrastructure
- 优先级: high/medium/low
- 工作量: small/medium/large
- 依赖: TASK-xxx (if any)
- 范围: Brief scope description
- 修改文件: (action): change summary
file-path - 收敛标准:
- criteria 1
- criteria 2
- 验证方式: executable command or steps
- 完成定义: business language definition
**Evidence Format** (for plan-note.md evidence sections):
```markdown
- **相关文件**: file list with relevance
- **现有模式**: patterns identified
- **约束**: constraints discoveredDomain Planning Rules:
- Each domain modifies ONLY its pre-allocated sections in plan-note.md
- Use assigned TASK ID range exclusively
- Include convergence criteria for each task (criteria + verification + definition_of_done)
- Include with conflict_risk assessment per file
files[] - Reference cross-domain dependencies explicitly
- Each task record must be self-contained (can be independently consumed by unified-execute)
- 状态: pending
- 类型: feature/fix/refactor/enhancement/testing/infrastructure
- 优先级: high/medium/low
- 工作量: small/medium/large
- 依赖: TASK-xxx(若有)
- 范围: 简要范围描述
- 修改文件: (action): 变更摘要
file-path - 验收标准:
- 条件1
- 条件2
- 验证方式: 可执行命令或步骤
- 完成定义: 业务语言描述
**证据格式**(用于plan-note.md的证据章节):
```markdown
- **相关文件**: 相关文件列表及相关性说明
- **现有模式**: 识别到的现有模式
- **约束条件**: 发现的约束领域规划规则:
- 每个领域仅修改plan-note.md中其预分配的章节
- 仅使用分配的TASK ID范围
- 每个任务需包含验收标准(条件 + 验证 + 完成定义)
- 包含并评估每个文件的conflict_risk
files[] - 明确记录跨领域依赖
- 每个任务记录必须独立可被unified-execute消费
Step 2.3: Verify plan-note.md Consistency
步骤2.3:验证plan-note.md一致性
After all domains are planned, verify the shared document.
Verification Activities:
- Read final plan-note.md
- Verify all task pool sections are populated
- Verify all evidence sections are populated
- Validate TASK ID uniqueness across all domains
- Check for any section format inconsistencies
Success Criteria:
- created for each domain (one file per task)
domains/{domain}/.task/TASK-*.json - Each task has convergence (criteria + verification + definition_of_done)
- updated with all task pools and evidence sections
plan-note.md - Task summaries follow consistent format
- No TASK ID overlaps across domains
所有领域规划完成后,验证共享文档的一致性。
验证活动:
- 读取最终的plan-note.md
- 验证所有任务池章节已填充
- 验证所有证据章节已填充
- 验证所有领域的TASK ID无重复
- 检查章节格式是否一致
成功标准:
- 每个领域已创建(每个任务一个文件)
domains/{domain}/.task/TASK-*.json - 每个任务包含验收标准(条件 + 验证 + 完成定义)
- 已更新所有任务池和证据章节
plan-note.md - 任务摘要格式一致
- 跨领域TASK ID无重叠
Phase 3: Conflict Detection
阶段3:冲突检测
Objective: Analyze plan-note.md for conflicts across all domain contributions.
目标:分析plan-note.md中所有领域贡献的内容,检测冲突。
Step 3.1: Parse plan-note.md
步骤3.1:解析plan-note.md
Extract all tasks from all "任务池" sections and domain .task/*.json files.
javascript
// parsePlanNote(markdown)
// - Extract YAML frontmatter between `---` markers
// - Scan for heading patterns: /^(#{2,})\s+(.+)$/
// - Build sections array: { level, heading, start, content }
// - Return: { frontmatter, sections }
// Also load all domain .task/*.json for detailed data
// loadDomainTasks(sessionFolder, subDomains):
// const allTasks = []
// for (const sub of subDomains) {
// const taskDir = `${sessionFolder}/domains/${sub.focus_area}/.task`
// const taskFiles = Glob(`${taskDir}/TASK-*.json`)
// taskFiles.forEach(file => {
// allTasks.push(JSON.parse(Read(file)))
// })
// }
// return allTasks
// extractTasksFromSection(content, sectionHeading)
// - Match: /### (TASK-\d+):\s+(.+?)\s+\[(.+?)\]/
// - For each: extract taskId, title, author
// - Parse details: status, type, priority, effort, depends_on, files, convergence
// - Return: array of task objects
// parseTaskDetails(content)
// - Extract via regex:
// - /\*\*状态\*\*:\s*(.+)/ → status
// - /\*\*类型\*\*:\s*(.+)/ → type
// - /\*\*优先级\*\*:\s*(.+)/ → priority
// - /\*\*工作量\*\*:\s*(.+)/ → effort
// - /\*\*依赖\*\*:\s*(.+)/ → depends_on (extract TASK-\d+ references)
// - Extract files: /- `([^`]+)` \((\w+)\):\s*(.+)/ → path, action, change
// - Return: { status, type, priority, effort, depends_on[], files[], convergence }从所有“任务池”章节和领域文件中提取所有任务。
.task/*.jsonjavascript
// parsePlanNote(markdown)
// - 提取`---`标记之间的YAML前置元数据
// - 扫描标题模式: /^(#{2,})\s+(.+)$/
// - 构建章节数组: { level, heading, start, content }
// - 返回: { frontmatter, sections }
// 同时加载所有领域的.task/*.json文件以获取详细数据
// loadDomainTasks(sessionFolder, subDomains):
// const allTasks = []
// for (const sub of subDomains) {
// const taskDir = `${sessionFolder}/domains/${sub.focus_area}/.task`
// const taskFiles = Glob(`${taskDir}/TASK-*.json`)
// taskFiles.forEach(file => {
// allTasks.push(JSON.parse(Read(file)))
// })
// }
// return allTasks
// extractTasksFromSection(content, sectionHeading)
// - 匹配正则: /### (TASK-\d+):\s+(.+?)\s+\[(.+?)\]/
// - 提取: taskId, title, author
// - 解析详情: status, type, priority, effort, depends_on, files, convergence
// - 返回: 任务对象数组
// parseTaskDetails(content)
// - 通过正则提取:
// - /\*\*状态\*\*:\s*(.+)/ → status
// - /\*\*类型\*\*:\s*(.+)/ → type
// - /\*\*优先级\*\*:\s*(.+)/ → priority
// - /\*\*工作量\*\*:\s*(.+)/ → effort
// - /\*\*依赖\*\*:\s*(.+)/ → depends_on(提取TASK-\d+引用)
// - 提取文件信息: /- `([^`]+)` \((\w+)\):\s*(.+)/ → path, action, change
// - 返回: { status, type, priority, effort, depends_on[], files[], convergence }Step 3.2: Detect Conflicts
步骤3.2:检测冲突
Scan all tasks for three categories of conflicts.
Conflict Types:
| Type | Severity | Detection Logic | Resolution |
|---|---|---|---|
| file_conflict | high | Same file:location modified by multiple domains | Coordinate modification order or merge changes |
| dependency_cycle | critical | Circular dependencies in task graph (DFS detection) | Remove or reorganize dependencies |
| strategy_conflict | medium | Multiple high-risk tasks in same file from different domains | Review approaches and align on single strategy |
Detection Functions:
javascript
// detectFileConflicts(tasks)
// Build fileMap: { "file-path": [{ task_id, task_title, source_domain, changes }] }
// For each file with modifications from multiple domains:
// → conflict: type='file_conflict', severity='high'
// → include: file, tasks_involved, domains_involved, changes
// → resolution: 'Coordinate modification order or merge changes'
// detectDependencyCycles(tasks)
// Build dependency graph: { taskId: [dependsOn_taskIds] }
// DFS with recursion stack to detect cycles:
function detectCycles(tasks) {
const graph = new Map(tasks.map(t => [t.id, t.depends_on || []]))
const visited = new Set(), inStack = new Set(), cycles = []
function dfs(node, path) {
if (inStack.has(node)) { cycles.push([...path, node].join(' → ')); return }
if (visited.has(node)) return
visited.add(node); inStack.add(node)
;(graph.get(node) || []).forEach(dep => dfs(dep, [...path, node]))
inStack.delete(node)
}
tasks.forEach(t => { if (!visited.has(t.id)) dfs(t.id, []) })
return cycles
}
// detectStrategyConflicts(tasks)
// Group tasks by files they modify (from task.files[].path)
// For each file with tasks from multiple domains:
// Filter for tasks with files[].conflict_risk === 'high' or 'medium'
// If >1 high-risk from different domains:
// → conflict: type='strategy_conflict', severity='medium'
// → resolution: 'Review approaches and align on single strategy'扫描所有任务以检测三类冲突。
冲突类型:
| 类型 | 严重程度 | 检测逻辑 | 解决方案 |
|---|---|---|---|
| file_conflict | 高 | 同一文件的同一位置被多个领域修改 | 协调修改顺序或合并变更 |
| dependency_cycle | 关键 | 任务图中存在循环依赖(DFS检测) | 移除或重新组织依赖 |
| strategy_conflict | 中 | 同一文件中存在来自不同领域的多个高风险任务 | 评审方案并对齐单一策略 |
检测函数:
javascript
// detectFileConflicts(tasks)
// 构建fileMap: { "file-path": [{ task_id, task_title, source_domain, changes }] }
// 对每个被多个领域修改的文件:
// → 冲突: type='file_conflict', severity='high'
// → 包含信息: file, tasks_involved, domains_involved, changes
// → 解决方案: 'Coordinate modification order or merge changes'
// detectDependencyCycles(tasks)
// 构建依赖图: { taskId: [dependsOn_taskIds] }
// 使用带递归栈的DFS检测循环:
function detectCycles(tasks) {
const graph = new Map(tasks.map(t => [t.id, t.depends_on || []]))
const visited = new Set(), inStack = new Set(), cycles = []
function dfs(node, path) {
if (inStack.has(node)) { cycles.push([...path, node].join(' → ')); return }
if (visited.has(node)) return
visited.add(node); inStack.add(node)
;(graph.get(node) || []).forEach(dep => dfs(dep, [...path, node]))
inStack.delete(node)
}
tasks.forEach(t => { if (!visited.has(t.id)) dfs(t.id, []) })
return cycles
}
// detectStrategyConflicts(tasks)
// 按任务修改的文件分组
// 对每个被多个领域修改的文件:
// 筛选出files[].conflict_risk === 'high'或'medium'的任务
// 若来自不同领域的高风险任务数量>1:
// → 冲突: type='strategy_conflict', severity='medium'
// → 解决方案: 'Review approaches and align on single strategy'Step 3.3: Generate Conflict Artifacts
步骤3.3:生成冲突产物
Write conflict results and update plan-note.md.
javascript
// 1. Write conflicts.json
Write(`${sessionFolder}/conflicts.json`, JSON.stringify({
detected_at: getUtc8ISOString(),
total_tasks: allTasks.length,
total_domains: subDomains.length,
total_conflicts: allConflicts.length,
conflicts: allConflicts // { type, severity, tasks_involved, description, suggested_resolution }
}, null, 2))
// 2. Update plan-note.md "## 冲突标记" section
// generateConflictMarkdown(conflicts):
// If empty: return '✅ 无冲突检测到'
// For each conflict:
// ### CONFLICT-{padded_index}: {description}
// - **严重程度**: critical | high | medium
// - **涉及任务**: TASK-xxx, TASK-yyy
// - **涉及领域**: domain-a, domain-b
// - **问题详情**: (based on conflict type)
// - **建议解决方案**: ...
// - **决策状态**: [ ] 待解决
// replaceSectionContent(markdown, sectionHeading, newContent):
// Find section heading position via regex
// Find next heading of same or higher level
// Replace content between heading and next section
// If section not found: append at endSuccess Criteria:
- All tasks extracted and analyzed
- written with detection results
conflicts.json - updated with conflict markers
plan-note.md - All conflict types checked (file, dependency, strategy)
写入冲突检测结果并更新plan-note.md。
javascript
// 1. 写入conflicts.json
Write(`${sessionFolder}/conflicts.json`, JSON.stringify({
detected_at: getUtc8ISOString(),
total_tasks: allTasks.length,
total_domains: subDomains.length,
total_conflicts: allConflicts.length,
conflicts: allConflicts // { type, severity, tasks_involved, description, suggested_resolution }
}, null, 2))
// 2. 更新plan-note.md的"## 冲突标记"章节
// generateConflictMarkdown(conflicts):
// 若无冲突: return '✅ 无冲突检测到'
// 对每个冲突:
// ### CONFLICT-{padded_index}: {description}
// - **严重程度**: critical | high | medium
// - **涉及任务**: TASK-xxx, TASK-yyy
// - **涉及领域**: domain-a, domain-b
// - **问题详情**: (基于冲突类型)
// - **建议解决方案**: ...
// - **决策状态**: [ ] 待解决
// replaceSectionContent(markdown, sectionHeading, newContent):
// 通过正则定位章节标题位置
// 找到下一个同级或更高级别的标题
// 替换标题与下一章节之间的内容
// 若未找到章节: 追加到文档末尾成功标准:
- 所有任务已被提取并分析
- 已写入包含检测结果的
conflicts.json - 已更新冲突标记章节
plan-note.md - 已检查所有冲突类型(文件、依赖、策略)
Phase 4: Completion
阶段4:规划完成
Objective: Generate human-readable plan summary and finalize workflow.
目标:生成易读的规划摘要并完成工作流。
Step 4.1: Collect Domain .task/*.json to Session .task/
步骤4.1:收集领域.task/*.json到会话级.task/目录
Copy all per-domain task JSON files into a single session-level directory.
.task/javascript
// Create session-level .task/ directory
Bash(`mkdir -p ${sessionFolder}/.task`)
// Collect all domain task files
for (const sub of subDomains) {
const taskDir = `${sessionFolder}/domains/${sub.focus_area}/.task`
const taskFiles = Glob(`${taskDir}/TASK-*.json`)
taskFiles.forEach(file => {
const filename = path.basename(file)
// Copy domain task file to session .task/ directory
Bash(`cp ${file} ${sessionFolder}/.task/${filename}`)
})
}将所有领域的任务JSON文件复制到单个会话级目录。
.task/javascript
// 创建会话级.task/目录
Bash(`mkdir -p ${sessionFolder}/.task`)
// 收集所有领域的任务文件
for (const sub of subDomains) {
const taskDir = `${sessionFolder}/domains/${sub.focus_area}/.task`
const taskFiles = Glob(`${taskDir}/TASK-*.json`)
taskFiles.forEach(file => {
const filename = path.basename(file)
// 将领域任务文件复制到会话级.task/目录
Bash(`cp ${file} ${sessionFolder}/.task/${filename}`)
})
}Step 4.2: Generate plan.json
步骤4.2:生成plan.json
Generate a plan overview following the plan-overview-base-schema.
javascript
// Generate plan.json (plan-overview-base-schema)
const allTaskFiles = Glob(`${sessionFolder}/.task/TASK-*.json`)
const taskIds = allTaskFiles.map(f => JSON.parse(Read(f)).id).sort()
// Guard: skip plan.json if no tasks generated
if (taskIds.length === 0) {
console.warn('No tasks generated; skipping plan.json')
} else {
const planOverview = {
summary: `Collaborative plan for: ${taskDescription}`,
approach: `Multi-domain planning across ${subDomains.length} sub-domains: ${subDomains.map(s => s.focus_area).join(', ')}`,
task_ids: taskIds,
task_count: taskIds.length,
complexity: complexity,
recommended_execution: "Agent",
_metadata: {
timestamp: getUtc8ISOString(),
source: "direct-planning",
planning_mode: "direct",
plan_type: "collaborative",
schema_version: "2.0"
}
}
Write(`${sessionFolder}/plan.json`, JSON.stringify(planOverview, null, 2))
} // end guard生成遵循plan-overview-base-schema的规划概览。
javascript
// 生成plan.json(遵循plan-overview-base-schema)
const allTaskFiles = Glob(`${sessionFolder}/.task/TASK-*.json`)
const taskIds = allTaskFiles.map(f => JSON.parse(Read(f)).id).sort()
// 防护逻辑:若未生成任务则跳过plan.json
if (taskIds.length === 0) {
console.warn('未生成任何任务; 跳过plan.json')
} else {
const planOverview = {
summary: `Collaborative plan for: ${taskDescription}`,
approach: `Multi-domain planning across ${subDomains.length} sub-domains: ${subDomains.map(s => s.focus_area).join(', ')}`,
task_ids: taskIds,
task_count: taskIds.length,
complexity: complexity,
recommended_execution: "Agent",
_metadata: {
timestamp: getUtc8ISOString(),
source: "direct-planning",
planning_mode: "direct",
plan_type: "collaborative",
schema_version: "2.0"
}
}
Write(`${sessionFolder}/plan.json`, JSON.stringify(planOverview, null, 2))
} // 结束防护逻辑Step 4.3: Generate plan.md
步骤4.3:生成plan.md
Create a human-readable summary from plan-note.md content.
plan.md Structure:
| Section | Content |
|---|---|
| Header | Session ID, task description, creation time |
| 需求 (Requirements) | Copied from plan-note.md "需求理解" section |
| 子领域拆分 (Sub-Domains) | Each domain with description, task range, estimated effort |
| 任务概览 (Task Overview) | All tasks with complexity, dependencies, and target files |
| 冲突报告 (Conflict Report) | Summary of detected conflicts or "无冲突" |
| 执行指令 (Execution) | Command to execute the plan |
javascript
const planMd = `# Collaborative Plan
**Session**: ${sessionId}
**Requirement**: ${taskDescription}
**Created**: ${getUtc8ISOString()}
**Complexity**: ${complexity}
**Domains**: ${subDomains.length}从plan-note.md内容创建易读的摘要。
plan.md结构:
| 章节 | 内容 |
|---|---|
| 头部 | 会话ID、任务描述、创建时间 |
| 需求 (Requirements) | 复制自plan-note.md的"需求理解"章节 |
| 子领域拆分 (Sub-Domains) | 每个领域的描述、任务范围、预估工作量 |
| 任务概览 (Task Overview) | 所有任务的复杂度、依赖和目标文件 |
| 冲突报告 (Conflict Report) | 检测到的冲突摘要或"无冲突" |
| 执行指令 (Execution) | 执行规划的命令 |
javascript
const planMd = `# 协作规划
**会话**: ${sessionId}
**需求**: ${taskDescription}
**创建时间**: ${getUtc8ISOString()}
**复杂度**: ${complexity}
**领域数量**: ${subDomains.length}需求理解
需求理解
${requirementSection}
${requirementSection}
子领域拆分
子领域拆分
| # | Focus Area | Description | TASK Range | Effort |
|---|---|---|---|---|
| ${subDomains.map((s, i) => ` | ${i+1} | ${s.focus_area} | ${s.description} | ${s.task_id_range[0]}-${s.task_id_range[1]} |
| # | 重点方向 | 描述 | TASK范围 | 预估工作量 |
|---|---|---|---|---|
| ${subDomains.map((s, i) => ` | ${i+1} | ${s.focus_area} | ${s.description} | ${s.task_id_range[0]}-${s.task_id_range[1]} |
任务概览
任务概览
${subDomains.map(sub => {
const domainTasks = allTasks.filter(t => t.source?.original_id?.startsWith('TASK') && t.source?.session_id === sessionId)
return +
domainTasks.map(t => ).join('\n')
}).join('\n\n')}
### ${sub.focus_area}\n\n- **${t.id}**: ${t.title} (${t.type}, ${t.effort}) ${t.depends_on.length ? '← ' + t.depends_on.join(', ') : ''}${subDomains.map(sub => {
const domainTasks = allTasks.filter(t => t.source?.original_id?.startsWith('TASK') && t.source?.session_id === sessionId)
return +
domainTasks.map(t => ).join('\n')
}).join('\n\n')}
### ${sub.focus_area}\n\n- **${t.id}**: ${t.title} (${t.type}, ${t.effort}) ${t.depends_on.length ? '← ' + t.depends_on.join(', ') : ''}冲突报告
冲突报告
${allConflicts.length === 0
? '✅ 无冲突检测到'
: allConflicts.map(c => ).join('\n')}
- **${c.type}** (${c.severity}): ${c.description}${allConflicts.length === 0
? '✅ 无冲突检测到'
: allConflicts.map(c => ).join('\n')}
- **${c.type}** (${c.severity}): ${c.description}执行
执行
```bash
/workflow:unified-execute-with-file PLAN="${sessionFolder}/.task/"
```
Session artifacts: `${sessionFolder}/`
${sessionFolder}/plan.md`, planMd)
Write(undefined```bash
/workflow:unified-execute-with-file PLAN="${sessionFolder}/.task/"
```
会话产物目录: `${sessionFolder}/`
${sessionFolder}/plan.md`, planMd)
Write(undefinedStep 4.4: Display Completion Summary
步骤4.4:显示完成摘要
Present session statistics and next steps.
javascript
// Display:
// - Session ID and directory path
// - Total domains planned
// - Total tasks generated
// - Conflict status (count and severity)
// - Execution command for next step
if (!autoMode) {
AskUserQuestion({
questions: [{
question: `规划完成:\n- ${subDomains.length} 个子领域\n- ${allTasks.length} 个任务\n- ${allConflicts.length} 个冲突\n\n下一步:`,
header: "Next Step",
multiSelect: false,
options: [
{ label: "Execute Plan", description: "使用 unified-execute 执行计划" },
{ label: "Review Conflicts", description: "查看并解决冲突" },
{ label: "Export", description: "导出 plan.md" },
{ label: "Done", description: "保存产物,稍后执行" }
]
}]
})
}| Selection | Action |
|---|---|
| Execute Plan | |
| Review Conflicts | Display conflicts.json content for manual resolution |
| Export | Copy plan.md + plan-note.md to user-specified location |
| Done | Display artifact paths, end workflow |
Success Criteria:
- generated with complete summary
plan.md - collected at session root (consumable by unified-execute)
.task/TASK-*.json - All artifacts present in session directory
- User informed of completion and next steps
展示会话统计信息和下一步操作选项。
javascript
// 显示内容:
// - 会话ID和目录路径
// - 已规划的领域总数
// - 生成的任务总数
// - 冲突状态(数量和严重程度)
// - 下一步的执行命令
if (!autoMode) {
AskUserQuestion({
questions: [{
question: `规划完成:\n- ${subDomains.length} 个子领域\n- ${allTasks.length} 个任务\n- ${allConflicts.length} 个冲突\n\n下一步:`,
header: "下一步操作",
multiSelect: false,
options: [
{ label: "执行规划", description: "使用 unified-execute 执行计划" },
{ label: "查看冲突", description: "查看并解决冲突" },
{ label: "导出", description: "导出 plan.md" },
{ label: "完成", description: "保存产物,稍后执行" }
]
}]
})
}| 选择项 | 操作 |
|---|---|
| 执行规划 | |
| 查看冲突 | 展示conflicts.json内容供手动解决 |
| 导出 | 将plan.md + plan-note.md复制到用户指定位置 |
| 完成 | 展示产物路径,结束工作流 |
成功标准:
- 已生成包含完整摘要的
plan.md - 会话根目录下已收集(可被unified-execute消费)
.task/TASK-*.json - 所有产物均存在于会话目录中
- 已告知用户规划完成及下一步操作
Configuration
配置选项
| Flag | Default | Description |
|---|---|---|
| 5 | Maximum sub-domains to identify |
| false | Auto-confirm all decisions |
| 参数 | 默认值 | 描述 |
|---|---|---|
| 5 | 可识别的最大子领域数量 |
| false | 自动确认所有决策 |
Iteration Patterns
迭代模式
New Planning Session
新建规划会话
User initiates: TASK="task description"
├─ No session exists → New session mode
├─ Analyze task with inline search tools
├─ Identify sub-domains
├─ Create plan-note.md template
├─ Generate requirement-analysis.json
│
├─ Serial domain planning:
│ ├─ Domain 1: explore → .task/TASK-*.json → fill plan-note.md
│ ├─ Domain 2: explore → .task/TASK-*.json → fill plan-note.md
│ └─ Domain N: ...
│
├─ Collect domain .task/*.json → session .task/
│
├─ Verify plan-note.md consistency
├─ Detect conflicts
├─ Generate plan.md summary
└─ Report completion用户发起: TASK="任务描述"
├─ 无现有会话 → 新建会话模式
├─ 使用内置搜索工具分析任务
├─ 识别子领域
├─ 创建plan-note.md模板
├─ 生成requirement-analysis.json
│
├─ 串行领域规划:
│ ├─ 领域1: 探索 → .task/TASK-*.json → 填充plan-note.md
│ ├─ 领域2: 探索 → .task/TASK-*.json → 填充plan-note.md
│ └─ 领域N: ...
│
├─ 收集领域 .task/*.json → 会话级 .task/
│
├─ 验证plan-note.md一致性
├─ 检测冲突
├─ 生成plan.md摘要
└─ 报告完成Continue Existing Session
继续现有会话
User resumes: TASK="same task"
├─ Session exists → Continue mode
├─ Load plan-note.md and requirement-analysis.json
├─ Identify incomplete domains (empty task pool sections)
├─ Plan remaining domains serially
└─ Continue with conflict detection用户恢复: TASK="相同任务"
├─ 存在现有会话 → 继续模式
├─ 加载plan-note.md和requirement-analysis.json
├─ 识别未完成的领域(空任务池章节)
├─ 按顺序规划剩余领域
└─ 继续执行冲突检测Error Handling & Recovery
错误处理与恢复
| Situation | Action | Recovery |
|---|---|---|
| No codebase detected | Normal flow, pure requirement planning | Proceed without codebase context |
| Codebase search fails | Continue with available context | Note limitation in plan-note.md |
| Domain planning fails | Record error, continue with next domain | Retry failed domain or plan manually |
| Section not found in plan-note | Create section defensively | Continue with new section |
| No tasks generated for a domain | Review domain description | Refine scope and retry |
| Conflict detection fails | Continue with empty conflicts | Note in completion summary |
| Session folder conflict | Append timestamp suffix | Create unique folder |
| plan-note.md format inconsistency | Validate and fix format after each domain | Re-read and normalize |
| 场景 | 操作 | 恢复方式 |
|---|---|---|
| 未检测到代码库 | 正常执行纯需求规划 | 无需代码库上下文继续执行 |
| 代码库搜索失败 | 使用现有上下文继续执行 | 在plan-note.md中记录限制 |
| 领域规划失败 | 记录错误,继续下一个领域 | 重试失败领域或手动规划 |
| plan-note.md中未找到章节 | 自动创建章节 | 使用新章节继续执行 |
| 某领域未生成任务 | 评审领域描述 | 细化范围并重试 |
| 冲突检测失败 | 生成空冲突结果继续执行 | 在完成摘要中记录 |
| 会话文件夹冲突 | 追加时间戳后缀 | 创建唯一文件夹 |
| plan-note.md格式不一致 | 每个领域规划后验证并修复格式 | 重新读取并标准化格式 |
Best Practices
最佳实践
Before Starting Planning
开始规划前
- Clear Task Description: Detailed requirements lead to better sub-domain splitting
- Reference Documentation: Ensure latest README and design docs are identified during Phase 1
- Clarify Ambiguities: Resolve unclear requirements before committing to sub-domains
- 清晰的任务描述: 详细的需求能带来更优的子领域拆分
- 参考文档: 确保在阶段1中识别到最新的README和设计文档
- 澄清歧义: 在确定子领域前解决所有不明确的需求
During Planning
规划过程中
- Review Plan Note: Check plan-note.md between domains to verify progress
- Verify Independence: Ensure sub-domains are truly independent and have minimal overlap
- Check Dependencies: Cross-domain dependencies should be documented explicitly
- Inspect Details: Review for specifics when needed
domains/{domain}/.task/TASK-*.json - Consistent Format: Follow task summary format strictly across all domains
- TASK ID Isolation: Use pre-assigned non-overlapping ranges to prevent ID conflicts
- 评审Plan Note: 在各领域规划间隙检查plan-note.md以验证进度
- 验证独立性: 确保子领域真正独立且重叠最少
- 检查依赖: 跨领域依赖应被明确记录
- 查看细节: 必要时评审的具体内容
domains/{domain}/.task/TASK-*.json - 格式一致: 严格遵循所有领域的任务摘要格式
- TASK ID隔离: 使用预分配的无重叠范围以避免ID冲突
After Planning
规划完成后
- Resolve Conflicts: Address high/critical conflicts before execution
- Review Summary: Check plan.md for completeness and accuracy
- Validate Tasks: Ensure all tasks have clear scope and modification targets
- 解决冲突: 执行前解决高/关键级冲突
- 评审摘要: 检查plan.md的完整性和准确性
- 验证任务: 确保所有任务都有清晰的范围和修改目标
When to Use
适用场景
Use collaborative-plan-with-file when:
- A complex task spans multiple sub-domains (backend + frontend + database, etc.)
- Need structured multi-domain task breakdown with conflict detection
- Planning a feature that touches many parts of the codebase
- Want pre-allocated section organization for clear domain separation
Use lite-plan when:
- Single domain, clear task with no sub-domain splitting needed
- Quick planning without conflict detection
Use req-plan-with-file when:
- Requirement-level progressive roadmap needed (MVP → iterations)
- Higher-level decomposition before detailed planning
Use analyze-with-file when:
- Need in-depth analysis before planning
- Understanding and discussion, not task generation
Now execute collaborative-plan-with-file for: $ARGUMENTS
当以下情况时使用collaborative-plan-with-file:
- 复杂任务跨越多个子领域(后端 + 前端 + 数据库等)
- 需要结构化的多领域任务拆分及冲突检测
- 规划涉及代码库多个部分的功能
- 希望通过预分配章节实现清晰的领域分离
当以下情况时使用lite-plan:
- 单一领域、任务清晰无需子领域拆分
- 快速规划无需冲突检测
当以下情况时使用req-plan-with-file:
- 需要需求级的渐进式路线图(MVP → 迭代)
- 详细规划前需要更高层次的分解
当以下情况时使用analyze-with-file:
- 规划前需要深入分析
- 仅需理解和讨论,无需生成任务
现在为以下内容执行collaborative-plan-with-file: $ARGUMENTS