collaborative-plan-with-file

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Collaborative-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
undefined

Basic 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
--yes
or
-y
: Auto-approve splits, skip confirmations.
当使用
--yes
-y
参数时:自动批准拆分,跳过确认步骤。

Overview

工作流概述

This workflow enables structured planning through sequential phases:
  1. Understanding & Template — Analyze requirements, identify sub-domains, create plan-note.md template
  2. Serial Domain Planning — Plan each sub-domain sequentially using direct search and analysis
  3. Conflict Detection — Scan plan-note.md for conflicts across all domains
  4. 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                                               │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘
该工作流通过以下连续阶段实现结构化规划:
  1. 需求理解与模板生成 — 分析需求、识别子领域、创建plan-note.md模板
  2. 串行领域规划 — 使用直接搜索和分析功能,按顺序规划每个子领域
  3. 冲突检测 — 扫描plan-note.md以检测跨领域冲突
  4. 规划完成 — 生成易读的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 summary
Schema
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:需求理解与模板创建

ArtifactPurpose
plan-note.md
Collaborative template with pre-allocated task pool and evidence sections per domain
requirement-analysis.json
Sub-domain assignments, TASK ID ranges, complexity assessment
产物用途
plan-note.md
包含预分配任务池和证据章节的协作模板
requirement-analysis.json
子领域分配、TASK ID范围、复杂度评估

Phase 2: Serial Domain Planning

阶段2:串行领域规划

ArtifactPurpose
domains/{domain}/.task/TASK-*.json
Task JSON files per domain (one file per task with convergence)
Updated
plan-note.md
Task pool and evidence sections filled for each domain
产物用途
domains/{domain}/.task/TASK-*.json
各领域的任务JSON文件(每个任务对应一个文件,包含验收标准)
更新后的
plan-note.md
填充了各领域任务池和证据章节的文档

Phase 3: Conflict Detection

阶段3:冲突检测

ArtifactPurpose
conflicts.json
Detected conflicts with types, severity, and resolutions
Updated
plan-note.md
Conflict markers section populated
产物用途
conflicts.json
检测到的冲突,包含类型、严重程度和解决方案建议
更新后的
plan-note.md
填充了冲突标记章节的文档

Phase 4: Completion

阶段4:规划完成

ArtifactPurpose
.task/TASK-*.json
Merged task JSON files from all domains (consumable by unified-execute)
plan.json
Plan overview following plan-overview-base-schema.json
plan.md
Human-readable summary with requirements, tasks, and conflicts

产物用途
.task/TASK-*.json
合并所有领域的任务JSON文件(可被unified-execute执行)
plan.json
遵循plan-overview-base-schema.json的规划概览
plan.md
包含需求、任务和冲突的易读摘要

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:
  • sessionId
    : Unique session identifier
  • sessionFolder
    : Base directory for all artifacts
  • maxDomains
    : Maximum number of sub-domains (default: 5)
  • autoMode
    : Boolean for auto-confirmation
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
    : 所有产物的基础目录
  • maxDomains
    : 最大子领域数量(默认:5)
  • 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:
  1. Search for references — Find related documentation, README files, and architecture guides
    • Use:
      mcp__ace-tool__search_context
      , Grep, Glob, Read
    • Run:
      ccw spec load --category planning
      (if spec system available)
  2. Extract task keywords — Identify key terms and concepts from the task description
  3. Identify ambiguities — List any unclear points or multiple possible interpretations
  4. Clarify with user — If ambiguities found, use AskUserQuestion for clarification
  5. Identify sub-domains — Split into 2-{maxDomains} parallelizable focus areas based on task complexity
  6. Assess complexity — Evaluate overall task complexity (Low/Medium/High)
Sub-Domain Identification Patterns:
PatternKeywords
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.
使用内置工具直接理解任务范围并识别子领域。
分析活动:
  1. 搜索参考资料 — 查找相关文档、README文件和架构指南
    • 使用工具:
      mcp__ace-tool__search_context
      、Grep、Glob、Read
    • 执行命令:
      ccw spec load --category planning
      (若规范系统可用)
  2. 提取任务关键词 — 从任务描述中识别关键术语和概念
  3. 识别歧义点 — 列出所有不明确的点或多种可能的解释
  4. 与用户确认 — 若发现歧义,使用AskUserQuestion工具向用户澄清
  5. 识别子领域 — 根据任务复杂度拆分为2-{maxDomains}个可并行的重点方向
  6. 评估复杂度 — 评估整体任务复杂度(低/中/高)
子领域识别模式:
模式关键词
后端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
  • ## 任务池 - {Domain N}
    — Pre-allocated task section per domain (TASK-{range})
  • ## 依赖关系
    — Auto-generated after all domains complete
  • ## 冲突标记
    — Populated in Phase 3
  • ## 上下文证据 - {Domain N}
    — Evidence section per domain
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
---
章节:
  • ## 需求理解
    — 核心目标、关键点、约束条件、拆分策略
  • ## 任务池 - {Domain N}
    — 每个领域的预分配任务章节(TASK-{range})
  • ## 依赖关系
    — 所有领域规划完成后自动生成
  • ## 冲突标记
    — 阶段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
undefined

TASK-{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
  • 修改文件:
    file-path
    (action): change summary
  • 收敛标准:
    • 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 discovered
Domain 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
    files[]
    with conflict_risk assessment per file
  • 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(若有)
  • 范围: 简要范围描述
  • 修改文件:
    file-path
    (action): 变更摘要
  • 验收标准:
    • 条件1
    • 条件2
  • 验证方式: 可执行命令或步骤
  • 完成定义: 业务语言描述

**证据格式**(用于plan-note.md的证据章节):

```markdown
- **相关文件**: 相关文件列表及相关性说明
- **现有模式**: 识别到的现有模式
- **约束条件**: 发现的约束
领域规划规则:
  • 每个领域仅修改plan-note.md中其预分配的章节
  • 仅使用分配的TASK ID范围
  • 每个任务需包含验收标准(条件 + 验证 + 完成定义)
  • 包含
    files[]
    并评估每个文件的conflict_risk
  • 明确记录跨领域依赖
  • 每个任务记录必须独立可被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:
  1. Read final plan-note.md
  2. Verify all task pool sections are populated
  3. Verify all evidence sections are populated
  4. Validate TASK ID uniqueness across all domains
  5. Check for any section format inconsistencies
Success Criteria:
  • domains/{domain}/.task/TASK-*.json
    created for each domain (one file per task)
  • Each task has convergence (criteria + verification + definition_of_done)
  • plan-note.md
    updated with all task pools and evidence sections
  • Task summaries follow consistent format
  • No TASK ID overlaps across domains

所有领域规划完成后,验证共享文档的一致性。
验证活动:
  1. 读取最终的plan-note.md
  2. 验证所有任务池章节已填充
  3. 验证所有证据章节已填充
  4. 验证所有领域的TASK ID无重复
  5. 检查章节格式是否一致
成功标准:
  • 每个领域已创建
    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/*.json
文件中提取所有任务。
javascript
// 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:
TypeSeverityDetection LogicResolution
file_conflicthighSame file:location modified by multiple domainsCoordinate modification order or merge changes
dependency_cyclecriticalCircular dependencies in task graph (DFS detection)Remove or reorganize dependencies
strategy_conflictmediumMultiple high-risk tasks in same file from different domainsReview 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 end
Success Criteria:
  • All tasks extracted and analyzed
  • conflicts.json
    written with detection results
  • plan-note.md
    updated with conflict markers
  • 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
.task/
directory.
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:
SectionContent
HeaderSession 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 AreaDescriptionTASK RangeEffort
${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
### ${sub.focus_area}\n\n
+ domainTasks.map(t =>
- **${t.id}**: ${t.title} (${t.type}, ${t.effort}) ${t.depends_on.length ? '← ' + t.depends_on.join(', ') : ''}
).join('\n') }).join('\n\n')}
${subDomains.map(sub => { const domainTasks = allTasks.filter(t => t.source?.original_id?.startsWith('TASK') && t.source?.session_id === sessionId) return
### ${sub.focus_area}\n\n
+ domainTasks.map(t =>
- **${t.id}**: ${t.title} (${t.type}, ${t.effort}) ${t.depends_on.length ? '← ' + t.depends_on.join(', ') : ''}
).join('\n') }).join('\n\n')}

冲突报告

冲突报告

${allConflicts.length === 0 ? '✅ 无冲突检测到' : allConflicts.map(c =>
- **${c.type}** (${c.severity}): ${c.description}
).join('\n')}
${allConflicts.length === 0 ? '✅ 无冲突检测到' : allConflicts.map(c =>
- **${c.type}** (${c.severity}): ${c.description}
).join('\n')}

执行

执行

```bash /workflow:unified-execute-with-file PLAN="${sessionFolder}/.task/" ```
Session artifacts: `${sessionFolder}/`
 Write(
${sessionFolder}/plan.md`, planMd)
undefined
```bash /workflow:unified-execute-with-file PLAN="${sessionFolder}/.task/" ```
会话产物目录: `${sessionFolder}/`
 Write(
${sessionFolder}/plan.md`, planMd)
undefined

Step 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: "保存产物,稍后执行" }
      ]
    }]
  })
}
SelectionAction
Execute Plan
Skill(skill="workflow:unified-execute-with-file", args="PLAN=\"${sessionFolder}/.task/\"")
Review ConflictsDisplay conflicts.json content for manual resolution
ExportCopy plan.md + plan-note.md to user-specified location
DoneDisplay artifact paths, end workflow
Success Criteria:
  • plan.md
    generated with complete summary
  • .task/TASK-*.json
    collected at session root (consumable by unified-execute)
  • 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: "保存产物,稍后执行" }
      ]
    }]
  })
}
选择项操作
执行规划
Skill(skill="workflow:unified-execute-with-file", args="PLAN=\"${sessionFolder}/.task/\"")
查看冲突展示conflicts.json内容供手动解决
导出将plan.md + plan-note.md复制到用户指定位置
完成展示产物路径,结束工作流
成功标准:
  • 已生成包含完整摘要的
    plan.md
  • 会话根目录下已收集
    .task/TASK-*.json
    (可被unified-execute消费)
  • 所有产物均存在于会话目录中
  • 已告知用户规划完成及下一步操作

Configuration

配置选项

FlagDefaultDescription
--max-domains
5Maximum sub-domains to identify
-y, --yes
falseAuto-confirm all decisions
参数默认值描述
--max-domains
5可识别的最大子领域数量
-y, --yes
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

错误处理与恢复

SituationActionRecovery
No codebase detectedNormal flow, pure requirement planningProceed without codebase context
Codebase search failsContinue with available contextNote limitation in plan-note.md
Domain planning failsRecord error, continue with next domainRetry failed domain or plan manually
Section not found in plan-noteCreate section defensivelyContinue with new section
No tasks generated for a domainReview domain descriptionRefine scope and retry
Conflict detection failsContinue with empty conflictsNote in completion summary
Session folder conflictAppend timestamp suffixCreate unique folder
plan-note.md format inconsistencyValidate and fix format after each domainRe-read and normalize

场景操作恢复方式
未检测到代码库正常执行纯需求规划无需代码库上下文继续执行
代码库搜索失败使用现有上下文继续执行在plan-note.md中记录限制
领域规划失败记录错误,继续下一个领域重试失败领域或手动规划
plan-note.md中未找到章节自动创建章节使用新章节继续执行
某领域未生成任务评审领域描述细化范围并重试
冲突检测失败生成空冲突结果继续执行在完成摘要中记录
会话文件夹冲突追加时间戳后缀创建唯一文件夹
plan-note.md格式不一致每个领域规划后验证并修复格式重新读取并标准化格式

Best Practices

最佳实践

Before Starting Planning

开始规划前

  1. Clear Task Description: Detailed requirements lead to better sub-domain splitting
  2. Reference Documentation: Ensure latest README and design docs are identified during Phase 1
  3. Clarify Ambiguities: Resolve unclear requirements before committing to sub-domains
  1. 清晰的任务描述: 详细的需求能带来更优的子领域拆分
  2. 参考文档: 确保在阶段1中识别到最新的README和设计文档
  3. 澄清歧义: 在确定子领域前解决所有不明确的需求

During Planning

规划过程中

  1. Review Plan Note: Check plan-note.md between domains to verify progress
  2. Verify Independence: Ensure sub-domains are truly independent and have minimal overlap
  3. Check Dependencies: Cross-domain dependencies should be documented explicitly
  4. Inspect Details: Review
    domains/{domain}/.task/TASK-*.json
    for specifics when needed
  5. Consistent Format: Follow task summary format strictly across all domains
  6. TASK ID Isolation: Use pre-assigned non-overlapping ranges to prevent ID conflicts
  1. 评审Plan Note: 在各领域规划间隙检查plan-note.md以验证进度
  2. 验证独立性: 确保子领域真正独立且重叠最少
  3. 检查依赖: 跨领域依赖应被明确记录
  4. 查看细节: 必要时评审
    domains/{domain}/.task/TASK-*.json
    的具体内容
  5. 格式一致: 严格遵循所有领域的任务摘要格式
  6. TASK ID隔离: 使用预分配的无重叠范围以避免ID冲突

After Planning

规划完成后

  1. Resolve Conflicts: Address high/critical conflicts before execution
  2. Review Summary: Check plan.md for completeness and accuracy
  3. Validate Tasks: Ensure all tasks have clear scope and modification targets
  1. 解决冲突: 执行前解决高/关键级冲突
  2. 评审摘要: 检查plan.md的完整性和准确性
  3. 验证任务: 确保所有任务都有清晰的范围和修改目标

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