collaborative-plan-with-file

ファイルを使った共同計画ワークフロー

クイックスタート

Plan Note アーキテクチャを使用した、逐次型の共同計画ワークフローです。要件を分析してサブドメインを特定し、ドメインごとに詳細な計画を順番に作成し、ドメイン間の競合を検出します。

# Basic usage
/codex:collaborative-plan-with-file "Implement real-time notification system"

# With options
/codex:collaborative-plan-with-file "Refactor authentication module" --max-domains=4
/codex:collaborative-plan-with-file "Add payment gateway support" -y

主なワークフロー：理解 → テンプレート → ドメインごとの逐次計画 → 競合検出 → 完了

主な機能：

• plan-note.md：ドメインごとにセクションが事前割り当てされた、共同編集用の共有ドキュメント
• ドメインごとの逐次計画：コードベース全体のコンテキストを踏まえて、各サブドメインを順番に計画します
• 競合検出：ファイル、依存関係、方針の競合を自動スキャンします
• マージ不要：セクションが事前割り当てされているため、マージ競合を回避できます

自動モード

--yes または -y を指定すると、分割を自動承認し、確認をスキップします。

概要

このワークフローでは、順次実行されるフェーズを通じて、構造化された計画を作成できます。

1. 要件の把握とテンプレート作成 — 要件を分析し、サブドメインを特定して、plan-note.md テンプレートを作成します
2. ドメインごとの逐次計画 — 直接検索と分析を使って、各サブドメインを順番に計画します
3. 競合検出 — plan-note.md をスキャンし、すべてのドメイン間の競合を検出します
4. 完了 — 人が読みやすい計画の要約 plan.md を生成します

主な革新点は Plan Note アーキテクチャです。サブドメインごとにセクションが事前割り当てされた共有ドキュメントを使うため、逐次実行でもマージ競合を回避できます。

┌─────────────────────────────────────────────────────────────────────────┐
│                    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                                               │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

出力構造

スキーマ：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

出力成果物

フェーズ 1：要件の把握とテンプレート作成

成果物	目的
plan-note.md	ドメインごとにタスクプールとエビデンスセクションが事前割り当てされた共同編集用テンプレート
requirement-analysis.json	サブドメインの割り当て、TASK ID の範囲、複雑さの評価

フェーズ 2：ドメインごとの逐次計画

成果物	目的
domains/{domain}/.task/TASK-*.json	ドメインごとのタスク JSON ファイル（収束時はタスクごとに 1 ファイル）
更新された plan-note.md	各ドメインのタスクプールとエビデンスセクションが入力済み

フェーズ 3：競合検出

成果物	目的
conflicts.json	種類、重大度、解決策を含む検出済み競合
更新された plan-note.md	競合マーカーセクションが入力済み

フェーズ 4：完了

成果物	目的
.task/TASK-*.json	すべてのドメインのタスク JSON ファイルをマージしたもの（unified-execute で使用可能）
plan.json	plan-overview-base-schema.json に準拠した計画の概要
plan.md	要件、タスク、競合を含む、人が読みやすい要約

---

実装の詳細

セッションの初期化

ステップ 0：セッションを初期化

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

セッション変数：

• sessionId：一意のセッション識別子
• sessionFolder：すべての成果物のベースディレクトリ
• maxDomains：サブドメインの最大数（デフォルト：5）
• autoMode：自動確認を行うかどうかを示すブール値

自動検出：セッションフォルダーに plan-note.md が存在する場合、自動的に続行モードに入ります。

---

フェーズ 1：要件の把握とテンプレートの作成

目的：タスクの要件を分析し、並列化可能なサブドメインを特定して、セクションを事前割り当てした plan-note.md テンプレートを作成します。

ステップ 1.1：タスクの説明を分析する

組み込みツールを直接使用して、タスクの範囲を把握し、サブドメインを特定します。

分析作業：

1. 参考資料を検索する — 関連ドキュメント、README ファイル、アーキテクチャガイドを探します
   • 使用ツール：mcp__ace-tool__search_context、Grep、Glob、Read
   • 実行：ccw spec load --category planning（仕様システムが利用可能な場合）
2. タスクのキーワードを抽出する — タスクの説明から重要な用語と概念を特定します
3. 曖昧な点を特定する — 不明確な点や複数の解釈が可能な点を列挙します
4. ユーザーに確認する — 曖昧な点が見つかった場合は、request_user_input を使って確認します
5. サブドメインを特定する — タスクの複雑さに応じて、並列化可能な重点領域を 2～{maxDomains} 個に分割します
6. 複雑さを評価する — 全体的なタスクの複雑さを評価します（低／中／高）

サブドメインの特定パターン：

パターン	キーワード
バックエンド API	サービス、バックエンド、API、インターフェース
フロントエンド	インターフェース、フロントエンド、UI、ビュー
データベース	データ、ストレージ、データベース、永続化
テスト	テスト、検証、QA
インフラストラクチャ	デプロイ、基盤、運用、設定

ガイドライン：最新のドキュメント（README、設計ドキュメント、アーキテクチャガイドなど）の特定を優先します。曖昧な点がある場合は、解釈を決めつけずにユーザーに確認してください。

ステップ 1.2：plan-note.md のテンプレートを作成する

各サブドメイン用のセクションをあらかじめ割り当てた構造化テンプレートを作成します。

plan-note.md の構成：

---
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-001～100、ドメイン 2：TASK-101～200）。

ステップ 1.3：requirement-analysis.json を生成する

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))

成功基準：

• 最新のドキュメントが特定され、参照されている（利用可能な場合）
• 曖昧な点がユーザーへの確認によって解消されている（見つかった場合）
• 明確なサブドメインが 2～{maxDomains} 個特定されている
• 各サブドメインを独立して計画できる
• Plan Note テンプレートに、あらかじめ割り当てられたすべてのセクションが含まれている
• TASK ID の範囲が重複していない（ドメインごとに 100 個の ID）
• 要件の理解が包括的である

---

フェーズ 2：サブドメインの逐次計画

目的：各サブドメインを順番に計画し、詳細な計画を生成して plan-note.md を更新します。

実行モデル：インラインで逐次実行 — 検索ツールを使い、各ドメインを一度に 1 つずつ直接調査して計画します。

ステップ 2.1：ユーザーの確認（autoMode でない場合）

特定したサブドメインを表示し、開始前に確認します。

if (!autoMode) {
  request_user_input({
    questions: [{
      header: "确认规划",
      id: "confirm",
      question: `已识别 ${subDomains.length} 个子领域:\n${subDomains.map((s, i) =>
        `${i+1}. ${s.focus_area}: ${s.description}`).join('\n')}\n\n确认开始规划?`,
      options: [
        { label: "开始规划(Recommended)", description: "逐域进行规划" },
        { label: "调整拆分", description: "修改子领域划分" },
        { label: "取消", description: "退出规划" }
      ]
    }]
  })
}

ステップ 2.2：ドメインの逐次計画

各サブドメインについて、計画サイクル全体をインラインで実行します。

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
}

タスク要約の形式（plan-note.md のタスクプールの各セクション用）：

### 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

根拠の形式（plan-note.md の根拠セクション用）：

- **相关文件**: file list with relevance
- **现有模式**: patterns identified
- **约束**: constraints discovered

ドメイン計画のルール：

• 各ドメインは、plan-note.md 内であらかじめ割り当てられたセクションのみを変更します
• 割り当てられた TASK ID の範囲のみを使用します
• 各タスクに収束基準（criteria + verification + definition_of_done）を含めます
• ファイルごとの conflict_risk 評価を含む files[] を記載します
• ドメイン間の依存関係を明示的に参照します
• 各タスクの記録は、単独で完結していなければなりません（unified-execute が独立して利用できること）

ステップ 2.3：plan-note.md の整合性を確認する

すべてのドメインの計画が完了したら、共有ドキュメントを確認します。

確認作業：

1. 最終版の plan-note.md を読む
2. すべてのタスクプールのセクションに内容が記入されていることを確認する
3. すべてのエビデンスのセクションに内容が記入されていることを確認する
4. すべてのドメインで TASK ID が一意であることを検証する
5. セクションの形式に不整合がないか確認する

成功基準：

• 各ドメインについて domains/{domain}/.task/TASK-*.json が作成されている（タスクごとに 1 ファイル）
• 各タスクに収束条件（基準 + 検証 + definition_of_done）がある
• plan-note.md がすべてのタスクプールとエビデンスのセクションで更新されている
• タスクの概要が一貫した形式に従っている
• ドメイン間で TASK ID が重複していない

---

フェーズ 3：競合の検出

目的：plan-note.md を分析し、各ドメインからの貢献内容に競合がないか確認します。

ステップ 3.1：plan-note.md を解析する

すべての「任务池」セクションとドメインの .task/*.json ファイルから、すべてのタスクを抽出します。

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

ステップ 3.2：競合を検出する

すべてのタスクを、次の 3 種類の競合についてスキャンします。

競合の種類：

種類	重大度	検出ロジック	解決方法
file_conflict	高	複数のドメインが同じ file:location を変更している	変更の順序を調整するか、変更を統合します
dependency_cycle	致命的	タスクグラフに循環依存がある（DFS による検出）	依存関係を削除するか、再編成します
strategy_conflict	中	異なるドメインから同じファイルに対する高リスクのタスクが複数ある	アプローチを確認し、単一の方針に調整します

検出関数：

// 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'

ステップ 3.3：競合アーティファクトを生成する

競合の結果を書き込み、plan-note.md を更新します。

// 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

成功基準：

• すべてのタスクが抽出され、分析されている
• 検出結果を含む conflicts.json が書き込まれている
• plan-note.md が競合マーカーで更新されている
• すべての競合の種類（ファイル、依存関係、方針）が確認されている

---

フェーズ 4：完了

目的：人が読みやすい計画の概要を生成し、ワークフローを完了します。

ステップ 4.1：ドメインの .task/*.json をセッションの .task/ に集約する

ドメインごとのすべてのタスク JSON ファイルを、単一のセッションレベルの .task/ ディレクトリにコピーします。

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

ステップ 4.2：plan.json を生成する

plan-overview-base-schema に従って、計画の概要を生成します。

// 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

ステップ 4.3：plan.md を生成する

plan-note.md の内容から、人が読みやすい概要を作成します。

plan.md の構成：

セクション	内容
ヘッダー	セッション ID、タスクの説明、作成日時
要件	plan-note.md の「需求理解」セクションからコピー
サブドメインの分割	各ドメインの説明、タスク範囲、見積もり工数
タスクの概要	複雑度、依存関係、対象ファイルを含むすべてのタスク
競合レポート	検出された競合の概要、または「無冲突」
実行	計画を実行するコマンド

const planMd = `# Collaborative Plan

**Session**: ${sessionId}
**Requirement**: ${taskDescription}
**Created**: ${getUtc8ISOString()}
**Complexity**: ${complexity}
**Domains**: ${subDomains.length}

## 需求理解

${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]} | ${s.estimated_effort} |`).join('\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')}

## 执行

\`\`\`bash
/workflow:unified-execute-with-file PLAN="${sessionFolder}/.task/"
\`\`\`

**Session artifacts**: \`${sessionFolder}/\`
`
Write(`${sessionFolder}/plan.md`, planMd)

ステップ 4.4：完了の概要を表示する

セッションの統計情報と次の手順を提示します。

// Display:
// - Session ID and directory path
// - Total domains planned
// - Total tasks generated
// - Conflict status (count and severity)
// - Execution command for next step

if (!autoMode) {
  request_user_input({
    questions: [{
      header: "下一步",
      id: "next_step",
      question: `规划完成:\n- ${subDomains.length} 个子领域\n- ${allTasks.length} 个任务\n- ${allConflicts.length} 个冲突\n\n下一步:`,
      options: [
        { label: "Execute Plan(Recommended)", description: "使用 unified-execute 执行计划" },
        { label: "Review Conflicts", description: "查看并解决冲突" },
        { label: "Done", description: "保存产物，稍后执行" }
      ]
    }]
  })
}

選択肢	操作
計画を実行	Skill(skill="workflow:unified-execute-with-file", args="PLAN=\"${sessionFolder}/.task/\"")
競合を確認	手動で解決できるよう、conflicts.json の内容を表示
エクスポート	plan.md + plan-note.md をユーザー指定の場所にコピー
完了	アーティファクトのパスを表示し、ワークフローを終了

ステップ 4.5：セッション状態を同期する

$session-sync -y "Plan complete: {domains} domains, {tasks} tasks"

計画の知見をもとに specs/*.md を更新し、計画セッションのエントリーを project-tech.json に追加します。

成功基準：

• 完全な概要を含む plan.md が生成されている
• .task/TASK-*.json がセッションのルートに集約されている（unified-execute で使用可能）
• すべてのアーティファクトがセッションディレクトリに存在する
• $session-sync によってセッション状態が同期されている
• 完了と次の手順がユーザーに通知されている

---

設定

フラグ	デフォルト	説明
--max-domains	5	識別するサブドメインの最大数
-y, --yes	false	すべての判断を自動承認する

反復パターン

新しい計画セッション

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

既存のセッションを続ける

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

---

エラー処理と復旧

状況	対応	復旧
コードベースが検出されない	通常のフローで進め、要件の計画のみを行う	コードベースのコンテキストなしで続行する
コードベースの検索に失敗する	利用可能なコンテキストで続行する	制限事項を plan-note.md に記録する
ドメインの計画に失敗する	エラーを記録し、次のドメインに進む	失敗したドメインを再試行するか、手動で計画する
plan-note 内にセクションが見つからない	安全策としてセクションを作成する	新しいセクションで続行する
ドメインのタスクが生成されない	ドメインの説明を見直す	スコープを調整して再試行する
競合の検出に失敗する	競合なしとして続行する	完了サマリーに記録する
セッションフォルダーが競合する	タイムスタンプのサフィックスを追加する	一意のフォルダーを作成する
plan-note.md の形式に一貫性がない	各ドメインの後に形式を検証して修正する	再読み込みして形式を統一する

---

ベストプラクティス

計画を開始する前に

1. 明確なタスクの説明：要件を詳しく記述すると、サブドメインをより適切に分割できます
2. 参考ドキュメント：フェーズ 1 で最新の README と設計ドキュメントが特定されていることを確認します
3. 曖昧さの解消：サブドメインを確定する前に、不明確な要件を解決します

計画中

1. 計画ノートの確認：ドメイン間で plan-note.md を確認し、進捗を検証します
2. 独立性の検証：サブドメインが真に独立しており、重複が最小限であることを確認します
3. 依存関係の確認：ドメイン間の依存関係は明示的に記録します
4. 詳細の確認：必要に応じて domains/{domain}/.task/TASK-*.json を確認し、詳細を把握します
5. 形式の一貫性：すべてのドメインでタスク概要の形式を厳密に統一します
6. TASK ID の分離：ID の競合を防ぐため、事前に割り当てられた重複しない範囲を使用します

計画後

1. 競合の解決：実行前に重大または深刻な競合に対処します
2. サマリーの確認：plan.md の完全性と正確性を確認します
3. タスクの検証：すべてのタスクでスコープと変更対象が明確であることを確認します

使用する場面

以下の場合は collaborative-plan-with-file を使用します：

• 複雑なタスクが複数のサブドメイン（バックエンド + フロントエンド + データベースなど）にまたがる
• 競合検出を含む、構造化された複数ドメインのタスク分割が必要
• コードベースの多くの部分に関わる機能を計画する
• ドメインを明確に分離するため、セクションを事前に割り当てて整理したい

以下の場合は lite-plan を使用します：

• 単一ドメインで、サブドメインへの分割が不要な明確なタスク
• 競合検出を行わずに、すばやく計画したい

以下の場合は req-plan-with-file を使用します：

• 要件レベルの段階的なロードマップ（MVP → イテレーション）が必要
• 詳細な計画の前に、より高いレベルで分解したい

以下の場合は analyze-with-file を使用します：

• 計画の前に詳細な分析が必要
• タスクの生成ではなく、理解と議論を重視する

---

次に、以下を対象に collaborative-plan-with-file を実行します：$ARGUMENTS