协作规划文件技能Skill collaborative-plan-with-file

---

名称: 协作规划与文件 描述: 串行协作规划与计划笔记 - 多领域串行任务生成，统一计划笔记，冲突检测。无代理委派。 参数提示: “[-y|–yes] <任务描述> [–max-domains=5]”

协作规划与文件工作流

快速开始

使用计划笔记架构的串行协作规划工作流。分析需求，识别子领域，按领域串行生成详细计划，并检测跨领域冲突。

# 基本用法
/codex:协作规划与文件 "实现实时通知系统"

# 带选项
/codex:协作规划与文件 "重构认证模块" --max-domains=4
/codex:协作规划与文件 "添加支付网关支持" -y

核心工作流: 理解 → 模板 → 串行领域规划 → 冲突检测 → 完成

关键特性:

• 计划笔记.md: 共享协作文档，每个领域预分配部分
• 串行领域规划: 每个子领域串行规划，基于完整代码库上下文
• 冲突检测: 自动扫描文件、依赖和策略冲突
• 无需合并: 预分配部分消除合并冲突

自动模式

当使用 --yes 或 -y: 自动批准拆分，跳过确认。

概述

此工作流通过顺序阶段实现结构化规划：

1. 理解与模板 — 分析需求，识别子领域，创建计划笔记.md 模板
2. 串行领域规划 — 使用直接搜索和分析串行规划每个子领域
3. 冲突检测 — 扫描计划笔记.md 中的跨所有领域冲突
4. 完成 — 生成可读的计划.md 摘要

关键创新是计划笔记架构 — 一个共享协作文档，每个子领域有预分配部分，即使串行执行也能消除合并冲突。

┌─────────────────────────────────────────────────────────────────────────┐
│                    计划笔记协作规划                                      │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│  阶段 1: 理解与模板创建                                                  │
│     ├─ 分析需求（内联搜索和分析）                                        │
│     ├─ 识别 2-5 个子领域（重点领域）                                     │
│     ├─ 创建计划笔记.md 带预分配部分                                      │
│     └─ 分配任务ID范围（无冲突）                                          │
│                                                                          │
│  阶段 2: 串行领域规划                                                    │
│     ┌──────────────┐                                                     │
│     │   领域 1     │→ 探索代码库 → 生成 .task/TASK-*.json               │
│     │   部分 1     │→ 在计划笔记.md 中填充任务池和证据                  │
│     └──────┬───────┘                                                     │
│     ┌──────▼───────┐                                                     │
│     │   领域 2     │→ 探索代码库 → 生成 .task/TASK-*.json               │
│     │   部分 2     │→ 在计划笔记.md 中填充任务池和证据                  │
│     └──────┬───────┘                                                     │
│     ┌──────▼───────┐                                                     │
│     │   领域 N     │→ ...                                               │
│     └──────────────┘                                                     │
│                                                                          │
│  阶段 3: 冲突检测（单源）                                                │
│     ├─ 解析计划笔记.md（所有部分）                                        │
│     ├─ 检测文件/依赖/策略冲突                                             │
│     └─ 更新计划笔记.md 冲突部分                                          │
│                                                                          │
│  阶段 4: 完成（无合并）                                                  │
│     ├─ 收集领域 .task/*.json → 会话 .task/*.json                        │
│     ├─ 生成计划.md（可读）                                               │
│     └─ 准备执行                                                         │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

输出结构

模式: cat ~/.ccw/workflows/cli-templates/schemas/task-schema.json

{项目根目录}/.workflow/.planning/CPLAN-{slug}-{日期}/
├── 计划笔记.md                  # ⭐ 核心: 需求 + 任务 + 冲突
├── 需求分析.json               # 阶段 1: 子领域分配
├── 领域/                      # 阶段 2: 每领域计划
│   ├── {领域-1}/
│   │   └── .task/                # 每领域任务 JSON 文件
│   │       ├── TASK-001.json
│   │       └── ...
│   ├── {领域-2}/
│   │   └── .task/
│   │       ├── TASK-101.json
│   │       └── ...
│   └── ...
├── 计划.json                     # 计划概览（计划概览基础模式.json）
├── .task/                        # ⭐ 合并的任务 JSON 文件（所有领域）
│   ├── TASK-001.json
│   ├── TASK-101.json
│   └── ...
├── 冲突.json                    # 阶段 3: 冲突报告
└── 计划.md                       # 阶段 4: 可读摘要

输出产物

阶段 1: 理解与模板

产物	目的
计划笔记.md	协作模板，每个领域有预分配任务池和证据部分
需求分析.json	子领域分配，任务ID范围，复杂度评估

阶段 2: 串行领域规划

产物	目的
领域/{领域}/.task/TASK-*.json	每领域任务 JSON 文件（每任务一个文件，带收敛）
更新 计划笔记.md	每个领域的任务池和证据部分填充

阶段 3: 冲突检测

产物	目的
冲突.json	检测到的冲突，含类型、严重性和解决方案
更新 计划笔记.md	冲突标记部分填充

阶段 4: 完成

产物	目的
.task/TASK-*.json	从所有领域合并的任务 JSON 文件（可由统一执行使用）
计划.json	计划概览，遵循计划概览基础模式.json
计划.md	可读摘要，含需求、任务和冲突

---

实现详情

会话初始化

步骤 0: 初始化会话

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}`

// 自动检测继续：会话文件夹 + 计划笔记.md 存在 → 继续模式
// 如果继续 → 加载现有状态并从未完成阶段恢复
Bash(`mkdir -p ${sessionFolder}/领域`)

会话变量:

• sessionId: 唯一会话标识符
• sessionFolder: 所有产物的基础目录
• maxDomains: 最大子领域数（默认: 5）
• autoMode: 布尔值，用于自动确认

自动检测: 如果会话文件夹存在且有计划笔记.md，自动进入继续模式。

---

阶段 1: 理解与模板创建

目标: 分析任务需求，识别可并行子领域，并创建计划笔记.md 模板，带预分配部分。

步骤 1.1: 分析任务描述

使用内置工具直接理解任务范围和识别子领域。

分析活动:

1. 搜索引用 — 查找相关文档、README 文件和架构指南
   • 使用: mcp__ace-tool__search_context, Grep, Glob, Read
   • 读取: .workflow/项目技术.json, .workflow/项目指南.json（如果存在）
2. 提取任务关键词 — 从任务描述中识别关键术语和概念
3. 识别歧义 — 列出任何不明确点或多重可能解释
4. 与用户澄清 — 如果发现歧义，使用 AskUserQuestion 进行澄清
5. 识别子领域 — 基于任务复杂度拆分为 2-{maxDomains} 个可并行重点领域
6. 评估复杂度 — 评估整体任务复杂度（低/中/高）

子领域识别模式:

模式	关键词
后端 API	服务, 后端, API, 接口
前端	界面, 前端, UI, 视图
数据库	数据, 存储, 数据库, 持久化
测试	测试, 验证, QA
基础设施	部署, 基础, 运维, 配置

指南: 优先识别最新文档（README、设计文档、架构指南）。当存在歧义时，向用户澄清，而不是假设解释。

步骤 1.2: 创建计划笔记.md 模板

生成结构化模板，每个子领域有预分配部分。

计划笔记.md 结构:

---
会话_id: CPLAN-{slug}-{date}
原始需求: "{任务描述}"
创建时间: "{ISO 时间戳}"
复杂度: 低 | 中 | 高
子领域: ["{领域-1}", "{领域-2}", ...]
领域任务_id范围:
  "{领域-1}": [1, 100]
  "{领域-2}": [101, 200]
状态: 规划中
---

部分:

• ## 需求理解 — 核心目标、关键点、约束、拆分策略
• ## 任务池 - {领域 N} — 每领域预分配任务部分（TASK-{范围}）
• ## 依赖关系 — 所有领域完成后自动生成
• ## 冲突标记 — 阶段 3 填充
• ## 上下文证据 - {领域 N} — 每领域证据部分

任务ID范围分配: 每个领域接收非重叠的 100 个ID范围（例如，领域 1: TASK-001~100，领域 2: TASK-101~200）。

步骤 1.3: 生成需求分析.json

Write(`${sessionFolder}/需求分析.json`, JSON.stringify({
  会话_id: sessionId,
  原始需求: taskDescription,
  复杂度: complexity,  // 低 | 中 | 高
  子领域: subDomains.map(sub => ({
    重点领域: sub.重点领域,
    描述: sub.描述,
    任务_id范围: sub.任务_id范围,
    预估工作量: sub.预估工作量,
    依赖: sub.依赖  // 跨领域依赖
  })),
  总领域数: subDomains.length
}, null, 2))

成功标准:

• 识别并引用最新文档（如果可用）
• 歧义通过用户澄清解决（如果找到）
• 识别 2-{maxDomains} 个清晰子领域
• 每个子领域可独立规划
• 计划笔记模板包含所有预分配部分
• 任务ID范围无重叠（每领域 100 个ID）
• 需求理解全面

---

阶段 2: 串行子领域规划

目标: 串行规划每个子领域，生成详细计划并更新计划笔记.md。

执行模型: 串行内联执行 — 每个领域使用搜索工具直接探索和规划，一次一个。

步骤 2.1: 用户确认（除非自动模式）

显示识别的子领域并在开始前确认。

if (!autoMode) {
  AskUserQuestion({
    questions: [{
      问题: `已识别 ${subDomains.length} 个子领域:
${subDomains.map((s, i) =>
        `${i+1}. ${s.重点领域}: ${s.描述}`).join('
')}

确认开始规划?`,
      标题: "确认",
      多选: false,
      选项: [
        { 标签: "开始规划", 描述: "逐域进行规划" },
        { 标签: "调整拆分", 描述: "修改子领域划分" },
        { 标签: "取消", 描述: "退出规划" }
      ]
    }]
  })
}

步骤 2.2: 串行领域规划

对于每个子领域，内联执行完整规划周期：

for (const sub of subDomains) {
  // 1. 创建领域目录，带 .task/ 子文件夹
  Bash(`mkdir -p ${sessionFolder}/领域/${sub.重点领域}/.task`)

  // 2. 探索代码库，获取领域相关上下文
  //    使用: mcp__ace-tool__search_context, Grep, Glob, Read
  //    重点关注:
  //      - 与此领域相关的模块/组件
  //      - 现有模式以供遵循
  //      - 与其他领域的集成点
  //      - 架构约束

  // 3. 生成任务 JSON 记录（遵循任务模式.json）
  const domainTasks = [
    // 对于分配的ID范围内的每个任务:
    {
      id: `TASK-${String(sub.任务_id范围[0]).padStart(3, '0')}`,
      标题: "...",
      描述: "...",                 // 此任务的范围/目标
      类型: "功能",                    // 基础设施|功能|增强|修复|重构|测试
      优先级: "中",                 // 高|中|低
      工作量: "中",                   // 小|中|大
      范围: "...",                       // 简要范围描述
      依赖: [],                     // TASK-xxx 引用
      收敛: {
        标准: ["... (可测试)"],     // 可测试条件
        验证: "... (可执行)", // 命令或步骤
        完成定义: "... (业务语言)"
      },
      文件: [                            // 要修改的文件
        {
          路径: "...",
          操作: "修改",              // 修改|创建|删除
          变更: ["..."],               // 变更描述
          冲突风险: "低"            // 低|中|高
        }
      ],
      来源: {
        工具: "协作规划与文件",
        会话_id: sessionId,
        原始_id: `TASK-${String(sub.任务_id范围[0]).padStart(3, '0')}`
      }
    }
    // ... 更多任务
  ]

  // 4. 写入独立任务 JSON 文件（每任务一个）
  domainTasks.forEach(task => {
    Write(`${sessionFolder}/领域/${sub.重点领域}/.task/${task.id}.json`,
      JSON.stringify(task, null, 2))
  })

  // 5. 同步摘要到计划笔记.md
  //    读取当前计划笔记.md
  //    定位预分配部分:
  //      - 任务池:  "## 任务池 - ${toTitleCase(sub.重点领域)}"
  //      - 证据:   "## 上下文证据 - ${toTitleCase(sub.重点领域)}"
  //    用任务摘要和证据填充
  //    写回计划笔记.md
}

任务摘要格式（用于计划笔记.md 任务池部分）：

### TASK-{ID}: {标题} [{重点领域}]
- **状态**: 待处理
- **类型**: 功能/修复/重构/增强/测试/基础设施
- **优先级**: 高/中/低
- **工作量**: 小/中/大
- **依赖**: TASK-xxx（如果有）
- **范围**: 简要范围描述
- **修改文件**: `文件路径` (操作): 变更摘要
- **收敛标准**:
  - 标准 1
  - 标准 2
- **验证方式**: 可执行命令或步骤
- **完成定义**: 业务语言定义

证据格式（用于计划笔记.md 证据部分）：

- **相关文件**: 文件列表，含相关性
- **现有模式**: 识别的模式
- **约束**: 发现的约束

领域规划规则:

• 每个领域仅修改计划笔记.md 中的预分配部分
• 仅使用分配的任务ID范围
• 为每个任务包含收敛标准（标准 + 验证 + 完成定义）
• 包含 文件[]，带每文件冲突风险评估
• 明确引用跨领域依赖
• 每个任务记录必须自包含（可由统一执行独立使用）

步骤 2.3: 验证计划笔记.md 一致性

所有领域规划完成后，验证共享文档。

验证活动:

1. 读取最终计划笔记.md
2. 验证所有任务池部分已填充
3. 验证所有证据部分已填充
4. 验证所有领域的任务ID唯一性
5. 检查任何部分格式不一致

成功标准:

• 领域/{领域}/.task/TASK-*.json 为每个领域创建（每任务一个文件）
• 每个任务有收敛（标准 + 验证 + 完成定义）
• 计划笔记.md 更新所有任务池和证据部分
• 任务摘要遵循一致格式
• 跨领域无任务ID重叠

---

阶段 3: 冲突检测

目标: 分析计划笔记.md，检测所有领域贡献的冲突。

步骤 3.1: 解析计划笔记.md

从所有“任务池”部分和领域 .task/*.json 文件中提取所有任务。

// parsePlanNote(markdown)
//   - 提取 `---` 标记之间的 YAML 前置数据
//   - 扫描标题模式: /^(#{2,})\s+(.+)$/
//   - 构建部分数组: { 级别, 标题, 开始, 内容 }
//   - 返回: { 前置数据, 部分 }

// 同时加载所有领域 .task/*.json 获取详细数据
// loadDomainTasks(sessionFolder, subDomains):
//   const allTasks = []
//   for (const sub of subDomains) {
//     const taskDir = `${sessionFolder}/领域/${sub.重点领域}/.task`
//     const taskFiles = Glob(`${taskDir}/TASK-*.json`)
//     taskFiles.forEach(file => {
//       allTasks.push(JSON.parse(Read(file)))
//     })
//   }
//   return allTasks

// extractTasksFromSection(内容, 部分标题)
//   - 匹配: /### (TASK-\d+):\s+(.+?)\s+\[(.+?)\]/
//   - 对于每个: 提取 taskId, 标题, 作者
//   - 解析详情: 状态, 类型, 优先级, 工作量, 依赖, 文件, 收敛
//   - 返回: 任务对象数组

// parseTaskDetails(内容)
//   - 通过正则提取:
//     - /\*\*状态\*\*:\s*(.+)/ → 状态
//     - /\*\*类型\*\*:\s*(.+)/ → 类型
//     - /\*\*优先级\*\*:\s*(.+)/ → 优先级
//     - /\*\*工作量\*\*:\s*(.+)/ → 工作量
//     - /\*\*依赖\*\*:\s*(.+)/ → 依赖（提取 TASK-\d+ 引用）
//   - 提取文件: /- `([^`]+)` \((\w+)\):\s*(.+)/ → 路径, 操作, 变更
//   - 返回: { 状态, 类型, 优先级, 工作量, 依赖[], 文件[], 收敛 }

步骤 3.2: 检测冲突

扫描所有任务，检测三类冲突。

冲突类型:

类型	严重性	检测逻辑	解决方案
文件冲突	高	同一文件:位置被多个领域修改	协调修改顺序或合并变更
依赖循环	关键	任务图中的循环依赖（DFS 检测）	移除或重组依赖
策略冲突	中	同一文件中有来自不同领域的多个高风险任务	审查方法并统一策略

检测函数:

// detectFileConflicts(tasks)
//   构建文件映射: { "文件路径": [{ task_id, task_标题, 来源领域, 变更 }] }
//   对于每个被多个领域修改的文件:
//     → 冲突: 类型='文件冲突', 严重性='高'
//     → 包括: 文件, 涉及任务, 涉及领域, 变更
//     → 解决方案: '协调修改顺序或合并变更'

// detectDependencyCycles(tasks)
//   构建依赖图: { taskId: [dependsOn_taskIds] }
//   使用递归栈进行 DFS 以检测循环:
function detectCycles(tasks) {
  const graph = new Map(tasks.map(t => [t.id, t.依赖 || []]))
  const visited = new Set(), inStack = new Set(), cycles = []
  function dfs(节点, 路径) {
    if (inStack.has(节点)) { cycles.push([...路径, 节点].join(' → ')); return }
    if (visited.has(节点)) return
    visited.add(节点); inStack.add(节点)
    ;(graph.get(节点) || []).forEach(依赖 => dfs(依赖, [...路径, 节点]))
    inStack.delete(节点)
  }
  tasks.forEach(t => { if (!visited.has(t.id)) dfs(t.id, []) })
  return cycles
}

// detectStrategyConflicts(tasks)
//   按修改的文件分组任务（从 task.files[].path）
//   对于每个有来自多个领域任务的文件:
//     筛选 files[].冲突风险 === '高' 或 '中' 的任务
//     如果 >1 个来自不同领域的高风险任务:
//       → 冲突: 类型='策略冲突', 严重性='中'
//       → 解决方案: '审查方法并统一策略'

步骤 3.3: 生成冲突产物

写入冲突结果并更新计划笔记.md。

// 1. 写入冲突.json
Write(`${sessionFolder}/冲突.json`, JSON.stringify({
  检测时间: getUtc8ISOString(),
  总任务数: allTasks.length,
  总领域数: subDomains.length,
  总冲突数: allConflicts.length,
  冲突: allConflicts  // { 类型, 严重性, 涉及任务, 描述, 建议解决方案 }
}, null, 2))

// 2. 更新计划笔记.md "## 冲突标记" 部分
// generateConflictMarkdown(conflicts):
//   如果为空: 返回 '✅ 无冲突检测到'
//   对于每个冲突:
//     ### CONFLICT-{填充索引}: {描述}
//     - **严重程度**: 关键 | 高 | 中
//     - **涉及任务**: TASK-xxx, TASK-yyy
//     - **涉及领域**: 领域-a, 领域-b
//     - **问题详情**: (基于冲突类型)
//     - **建议解决方案**: ...
//     - **决策状态**: [ ] 待解决

// replaceSectionContent(markdown, sectionHeading, newContent):
//   通过正则查找部分标题位置
//   查找相同或更高级别的下一个标题
//   替换标题和下一部分之间的内容
//   如果部分未找到: 在末尾追加

成功标准:

• 所有任务提取和分析
• 冲突.json 写入检测结果
• 计划笔记.md 更新冲突标记
• 所有冲突类型检查（文件、依赖、策略）

---

阶段 4: 完成

目标: 生成可读计划摘要并完成工作流。

步骤 4.1: 收集领域 .task/*.json 到会话 .task/

将所有每领域任务 JSON 文件复制到单个会话级 .task/ 目录。

// 创建会话级 .task/ 目录
Bash(`mkdir -p ${sessionFolder}/.task`)

// 收集所有领域任务文件
for (const sub of subDomains) {
  const taskDir = `${sessionFolder}/领域/${sub.重点领域}/.task`
  const taskFiles = Glob(`${taskDir}/TASK-*.json`)
  taskFiles.forEach(file => {
    const filename = path.basename(file)
    // 复制领域任务文件到会话 .task/ 目录
    Bash(`cp ${file} ${sessionFolder}/.task/${filename}`)
  })
}

步骤 4.2: 生成计划.json

生成计划概览，遵循计划概览基础模式。

// 生成计划.json（计划概览基础模式）
const allTaskFiles = Glob(`${sessionFolder}/.task/TASK-*.json`)
const taskIds = allTaskFiles.map(f => JSON.parse(Read(f)).id).sort()

// 守卫: 如果无任务生成，跳过计划.json
if (taskIds.length === 0) {
  console.warn('无任务生成; 跳过计划.json')
} else {

const planOverview = {
  摘要: `协作计划: ${taskDescription}`,
  方法: `多领域规划，覆盖 ${subDomains.length} 个子领域: ${subDomains.map(s => s.重点领域).join(', ')}`,
  任务_ids: taskIds,
  任务数: taskIds.length,
  复杂度: complexity,
  推荐执行: "代理",
  _元数据: {
    时间戳: getUtc8ISOString(),
    来源: "直接规划",
    规划模式: "直接",
    计划类型: "协作",
    模式版本: "2.0"
  }
}
Write(`${sessionFolder}/计划.json`, JSON.stringify(planOverview, null, 2))

} // 结束守卫

步骤 4.3: 生成计划.md

从计划笔记.md 内容创建可读摘要。

计划.md 结构:

部分	内容
标题	会话 ID, 任务描述, 创建时间
需求 (需求理解)	从计划笔记.md “需求理解”部分复制
子领域拆分 (子领域)	每个领域含描述、任务范围、预估工作量
任务概览 (任务概览)	所有任务，含复杂度、依赖和目标文件
冲突报告 (冲突报告)	检测到的冲突摘要或“无冲突”
执行指令 (执行)	执行计划的命令

const planMd = `# 协作计划

**会话**: ${sessionId}
**需求**: ${taskDescription}
**创建**: ${getUtc8ISOString()}
**复杂度**: ${complexity}
**领域数**: ${subDomains.length}

## 需求理解

${requirementSection}

## 子领域拆分

| # | 重点领域 | 描述 | 任务范围 | 工作量 |
|---|-----------|-------------|------------|--------|
${subDomains.map((s, i) => `| ${i+1} | ${s.重点领域} | ${s.描述} | ${s.任务_id范围[0]}-${s.任务_id范围[1]} | ${s.预估工作量} |`).join('
')}

## 任务概览

${subDomains.map(sub => {
  const domainTasks = allTasks.filter(t => t.来源?.原始_id?.startsWith('TASK') && t.来源?.会话_id === sessionId)
  return `### ${sub.重点领域}

` +
    domainTasks.map(t => `- **${t.id}**: ${t.标题} (${t.类型}, ${t.工作量}) ${t.依赖.length ? '← ' + t.依赖.join(', ') : ''}`).join('
')
}).join('

')}

## 冲突报告

${allConflicts.length === 0
  ? '✅ 无冲突检测到'
  : allConflicts.map(c => `- **${c.类型}** (${c.严重性}): ${c.描述}`).join('
')}

## 执行

\`\`\`bash
/workflow:统一执行与文件 PLAN="${sessionFolder}/.task/"
\`\`\`

**会话产物**: \`${sessionFolder}/\`
`
Write(`${sessionFolder}/计划.md`, planMd)

步骤 4.4: 显示完成摘要

显示会话统计信息和下一步步骤。

// 显示:
// - 会话 ID 和目录路径
// - 总领域规划数
// - 总任务生成数
// - 冲突状态（数量和严重性）
// - 下一步执行命令

if (!autoMode) {
  AskUserQuestion({
    questions: [{
      问题: `规划完成:
- ${subDomains.length} 个子领域
- ${allTasks.length} 个任务
- ${allConflicts.length} 个冲突

下一步:`,
      标题: "下一步",
      多选: false,
      选项: [
        { 标签: "执行计划", 描述: "使用统一执行执行计划" },
        { 标签: "审查冲突", 描述: "查看并解决冲突" },
        { 标签: "导出", 描述: "导出计划.md" },
        { 标签: "完成", 描述: "保存产物，稍后执行" }
      ]
    }]
  })
}

选择	动作
执行计划	Skill(skill="workflow:统一执行与文件", args="PLAN=\"${sessionFolder}/.task/\"")
审查冲突	显示冲突.json 内容以供手动解决
导出	复制计划.md + 计划笔记.md 到用户指定位置
完成	显示产物路径，结束工作流

成功标准:

• 计划.md 生成完整摘要
• .task/TASK-*.json 收集在会话根目录（可由统一执行使用）
• 所有产物存在于会话目录
• 用户知晓完成和下一步步骤

---

配置

标志	默认	描述
--max-domains	5	最大子领域识别数
-y, --yes	false	自动确认所有决策

迭代模式

新规划会话

用户发起: 任务="任务描述"
   ├─ 无会话存在 → 新会话模式
   ├─ 使用内联搜索工具分析任务
   ├─ 识别子领域
   ├─ 创建计划笔记.md 模板
   ├─ 生成需求分析.json
   │
   ├─ 串行领域规划:
   │   ├─ 领域 1: 探索 → .task/TASK-*.json → 填充计划笔记.md
   │   ├─ 领域 2: 探索 → .task/TASK-*.json → 填充计划笔记.md
   │   └─ 领域 N: ...
   │
   ├─ 收集领域 .task/*.json → 会话 .task/
   │
   ├─ 验证计划笔记.md 一致性
   ├─ 检测冲突
   ├─ 生成计划.md 摘要
   └─ 报告完成

继续现有会话

用户恢复: 任务="相同任务"
   ├─ 会话存在 → 继续模式
   ├─ 加载计划笔记.md 和需求分析.json
   ├─ 识别未完成领域（空任务池部分）
   ├─ 串行规划剩余领域
   └─ 继续冲突检测

---

错误处理与恢复

情况	动作	恢复
无代码库检测	正常流程，纯需求规划	继续，无代码库上下文
代码库搜索失败	继续，使用可用上下文	在计划笔记.md 中记录限制
领域规划失败	记录错误，继续下一个领域	重试失败领域或手动规划
计划笔记.md 中部分未找到	防御性创建部分	继续新部分
无任务为领域生成	审查领域描述	细化范围并重试
冲突检测失败	继续，空冲突	在完成摘要中记录
会话文件夹冲突	追加时间戳后缀	创建唯一文件夹
计划笔记.md 格式不一致	在每个领域后验证和修复格式	重新读取并标准化

---

最佳实践

开始规划前

1. 清晰任务描述: 详细需求导致更好的子领域拆分
2. 参考文档: 确保阶段 1 识别最新 README 和设计文档
3. 澄清歧义: 在提交子领域前解决不明确需求

规划期间

1. 审查计划笔记: 在领域间检查计划笔记.md 以验证进度
2. 验证独立性: 确保子领域真正独立，重叠最小
3. 检查依赖: 跨领域依赖应明确记录
4. 检查详情: 需要时审查 领域/{领域}/.task/TASK-*.json 细节
5. 一致格式: 严格遵循所有领域的任务摘要格式
6. 任务ID隔离: 使用预分配非重叠范围防止ID冲突

规划后

1. 解决冲突: 执行前解决高/关键冲突
2. 审查摘要: 检查计划.md 完整性和准确性
3. 验证任务: 确保所有任务有清晰范围和修改目标

何时使用

使用协作规划与文件时:

• 复杂任务跨越多个子领域（后端 + 前端 + 数据库等）
• 需要结构化多领域任务分解，带冲突检测
• 规划涉及代码库多部分的功能
• 希望预分配部分组织，明确领域分离

使用精简规划时:

• 单一领域，清晰任务，无需子领域拆分
• 快速规划，无需冲突检测

使用需求规划与文件时:

• 需求级渐进路线图（MVP → 迭代）
• 详细规划前的高层分解

使用分析与文件时:

• 需要深入分析后再规划
• 理解和讨论，非任务生成

---

现在为以下执行协作规划与文件: $ARGUMENTS