workflow-execute

ワークフローの実行

体系的なタスクの検出、エージェントの連携、進捗の追跡を通じて、自律的なワークフロー実行を調整します。ユーザーを中断することなくワークフロー全体を実行します（複数のアクティブなセッションがある場合の初回セッション選択を除く）。エージェントに完全なコンテキストを提供し、包括的な TodoWrite による追跡で適切なフロー制御の実行を確実にします。

再開モード：--resume-session フラグを指定して呼び出すと、検出フェーズをスキップし、指定したセッションの TodoWrite 生成とエージェント実行に直接進みます。

使用方法

# Interactive mode (with confirmations)
/workflow-execute
/workflow-execute --resume-session="WFS-auth"

# Auto mode (skip confirmations, use defaults)
/workflow-execute --yes
/workflow-execute -y
/workflow-execute -y --resume-session="WFS-auth"

# With auto-commit (commit after each task completion)
/workflow-execute --with-commit
/workflow-execute -y --with-commit
/workflow-execute -y --with-commit --resume-session="WFS-auth"

自動モードのデフォルト設定

--yes または -y フラグを使用する場合：

• セッション選択：最初の（最も新しい）アクティブなセッションを自動的に選択します
• 完了時の選択：セッションを自動的に完了します（/workflow:session:complete --yes を実行）

--with-commit フラグを使用する場合：

• 自動コミット：各エージェントタスクの完了後、サマリードキュメントに基づいて変更をコミットします
• コミットの原則：最小限のコミットにとどめます。完了したタスクによって変更されたファイルのみをコミットします
• コミットメッセージ：タスクのサマリーから次の形式で生成します："feat/fix/refactor: {task-title} - {summary}"

フラグの解析：

// ★ 统一 auto mode 检测：-y/--yes 从 $ARGUMENTS 或 ccw 传播
const autoYes = /\b(-y|--yes)\b/.test($ARGUMENTS)
const withCommit = $ARGUMENTS.includes('--with-commit')

パフォーマンス最適化戦略

遅延読み込み：タスク JSON はあらかじめ読み込まず、実行中に必要に応じて読み込みます。TODO_LIST.md と IMPL_PLAN.md が計画用のメタデータを提供します。

読み込み戦略：

• TODO_LIST.md：Phase 3 で読み込みます（TodoWrite 生成に必要なタスクのメタデータ、ステータス、依存関係）
• IMPL_PLAN.md：Phase 2 で存在を確認し（通常モード）、Phase 4A で実行戦略を解析します
• タスク JSON：遅延読み込みです。タスクの実行直前にのみ読み込みます（Phase 4B）

基本ルール

TodoWrite を使って進捗を包括的に追跡しながら、ユーザーを中断することなくワークフロー全体を自律的に完了します。 ワークフローの完了または依存関係によるブロックに至るまで、検出された未完了タスクをすべて実行します。 ユーザーが完了方法を選択：すべてのタスクが終了したら、レビューするか完了するかをユーザーに尋ねます。 1 エージェントにつき 1 つのタスク JSON：各エージェントのインスタンスが実行するタスク JSON ファイルは 1 つのみです。複数のタスクを 1 回のエージェント実行にまとめてはいけません。

基本的な責務

• セッションの検出：アクティブなワークフローセッションを特定して選択します
• 実行戦略の解析：IMPL_PLAN.md から実行モデルを抽出します
• TodoWrite による進捗追跡：ワークフロー全体を通して、実行ステータスをリアルタイムで維持します
• エージェントの調整：完全なコンテキストを提供しながら、専門エージェントを連携させます
• ステータスの同期：タスク JSON ファイルとワークフローの状態を更新します
• 自律的な完了：すべてのタスクが完了するか、ブロック状態に達するまで実行を続けます
• セッション完了時のユーザー選択：すべてのタスクが終了したら、レビューするか完了するかをユーザーに尋ねます

実行方針

• 進捗の追跡：ワークフロー全体の実行を通して、TodoWrite を継続的に更新します
• 自律的な完了：ワークフローが完了するまで、ユーザーを中断することなくすべてのタスクを実行します

実行プロセス

Normal Mode:
Phase 1: Discovery
   ├─ Count active sessions
   └─ Decision:
      ├─ count=0 → ERROR: No active sessions
      ├─ count=1 → Auto-select session → Phase 2
      └─ count>1 → AskUserQuestion (max 4 options) → Phase 2

Phase 2: Planning Document Validation
   ├─ Check IMPL_PLAN.md exists
   ├─ Check TODO_LIST.md exists
   └─ Validate .task/ contains IMPL-*.json files

Phase 3: TodoWrite Generation
   ├─ Update session status to "active" (Step 0)
   ├─ Parse TODO_LIST.md for task statuses
   ├─ Generate TodoWrite for entire workflow
   └─ Prepare session context paths

Phase 4: Execution Strategy & Task Execution
   ├─ Step 4A: Parse execution strategy from IMPL_PLAN.md
   └─ Step 4B: Execute tasks with lazy loading
      └─ Loop:
         ├─ Get next in_progress task from TodoWrite
         ├─ Lazy load task JSON
         ├─ Launch agent with task context
         ├─ Mark task completed (update IMPL-*.json status)
         │  # Quick fix: Update task status for ccw dashboard
         │  # TS=$(date -Iseconds) && jq --arg ts "$TS" '.status="completed" | .status_history=(.status_history // [])+[{"from":"in_progress","to":"completed","changed_at":$ts}]' IMPL-X.json > tmp.json && mv tmp.json IMPL-X.json
         ├─ [with-commit] Commit changes based on summary (minimal principle)
         │  # Read summary from .summaries/IMPL-X-summary.md
         │  # Extract changed files from summary's "Files Modified" section
         │  # Generate commit message: "feat/fix/refactor: {task-title} - {summary}"
         │  # git add <changed-files> && git commit -m "<commit-message>"
         └─ Advance to next task

Phase 5: Completion
   ├─ Update task statuses in JSON files
   ├─ Generate summaries
   └─ AskUserQuestion: Choose next step
      ├─ "Enter Review" → Phase 6
      └─ "Complete Session" → /workflow:session:complete

Phase 6: Post-Implementation Review (Optional)
   └─ Ref: phases/06-review.md
      ├─ Select review type (quality/security/architecture/action-items)
      ├─ CLI-assisted analysis (Gemini/Qwen)
      ├─ Generate REVIEW-{type}.md report
      └─ Post-review: another review or complete session

Resume Mode (--resume-session):
   ├─ Skip Phase 1 & Phase 2
   └─ Entry Point: Phase 3 (TodoWrite Generation)
      ├─ Update session status to "active" (if not already)
      └─ Continue: Phase 4 → Phase 5 → [Phase 6]

実行ライフサイクル

Phase 1：検出

適用対象：通常モードのみ（再開モードではスキップ）

目的：アクティブなワークフローセッションを検索し、複数のセッションがある場合はユーザーの確認を得て選択します

プロセス：

Step 1.1：アクティブなセッション数の確認

bash(find .workflow/active/ -name "WFS-*" -type d 2>/dev/null | wc -l)

Step 1.2：セッション選択の処理

ケース A：セッションなし（count = 0）

ERROR: No active workflow sessions found
Run /workflow-plan "task description" to create a session

ケース B：セッションが 1 つ（count = 1）

bash(find .workflow/active/ -name "WFS-*" -type d 2>/dev/null | head -1 | xargs basename)

自動的に選択し、Phase 2 に進みます。

ケース C：複数のセッション（count > 1）

メタデータとともにセッションを一覧表示し、ユーザーに選択を促します：

bash(for dir in .workflow/active/WFS-*/; do [ -d "$dir" ] || continue; session=$(basename "$dir"); project=$(jq -r '.project // "Unknown"' "${dir}workflow-session.json" 2>/dev/null || echo "Unknown"); total=$(grep -c '^\- \[' "${dir}TODO_LIST.md" 2>/dev/null || echo 0); completed=$(grep -c '^\- \[x\]' "${dir}TODO_LIST.md" 2>/dev/null || echo 0); if [ "$total" -gt 0 ]; then progress=$((completed * 100 / total)); else progress=0; fi; echo "$session | $project | $completed/$total tasks ($progress%)"; done)

--yes フラグの解析：

// ★ 统一 auto mode 检测：-y/--yes 从 $ARGUMENTS 或 ccw 传播
const autoYes = /\b(-y|--yes)\b/.test($ARGUMENTS)

条件付き選択：

if (autoYes) {
  // Auto mode: Select first session (most recent)
  const firstSession = sessions[0]
  console.log(`[--yes] Auto-selecting session: ${firstSession.id}`)
  selectedSessionId = firstSession.id
  // Continue to Phase 2
} else {
  // Interactive mode: Use AskUserQuestion to present formatted options (max 4 options shown)
  // If more than 4 sessions, show most recent 4 with "Other" option for manual input
  const sessions = getActiveSessions()  // sorted by last modified
  const displaySessions = sessions.slice(0, 4)

  AskUserQuestion({
    questions: [{
      question: "Multiple active sessions detected. Select one:",
      header: "Session",
      multiSelect: false,
      options: displaySessions.map(s => ({
        label: s.id,
        description: `${s.project} | ${s.progress}`
      }))
      // Note: User can select "Other" to manually enter session ID
    }]
  })
}

入力の検証：

• ユーザーが選択肢から選んだ場合：選択されたセッション ID を使用します
• ユーザーが「Other」を選択して入力した場合：セッションが存在することを検証します
• 検証に失敗した場合：エラーを表示して再入力を促すか、選択可能なセッションを提示します

ユーザーの入力（数字「1」、完全な ID「WFS-auth-system」、または部分文字列「auth」に対応）を解析して選択を検証し、Phase 2 に進みます。

ステップ 1.3：セッションメタデータを読み込む

bash(cat .workflow/active/${sessionId}/workflow-session.json)

出力：セッションメタデータをメモリに保存します まだタスク JSON を読み込まないでください - 実行フェーズまで保留します（遅延読み込み）

再開モード：--resume-session="session-id" フラグが指定されている場合、このフェーズ全体をスキップします。

フェーズ 2：計画ドキュメントの検証

適用対象：通常モードのみ（再開モードではスキップ）

目的：実行前に計画関連ファイルが存在することを確認します

プロセス：

1. IMPL_PLAN.md を確認：ファイルが存在することを確認します（詳細な解析はフェーズ 4A まで保留します）
2. plan.json を確認：ファイルが存在することを確認します（構造化された計画の概要。フェーズ 4A で使用します）
3. TODO_LIST.md を確認：ファイルが存在することを確認します（読み込みはフェーズ 3 まで保留します）
4. タスクディレクトリを検証：.task/ に IMPL-*.json ファイルが少なくとも 1 つ含まれていることを確認します

主な最適化：ここでは存在確認のみを行います。実際のファイル読み込みは後続のフェーズで行われます。

再開モード：--resume-session フラグが指定されている場合、このフェーズはスキップされます。再開モードの開始地点はフェーズ 3 です。

フェーズ 3：TodoWrite の生成

適用対象：通常モードと再開モードの両方（再開モードの開始地点）

ステップ 0：セッションのステータスをアクティブに更新 TodoWrite を生成する前に、セッションのステータスを「planning」から「active」に更新します：

# Update session status (idempotent - safe to run if already active)
jq '.status = "active" | .execution_started_at = (.execution_started_at // now | todate)' \
  .workflow/active/${sessionId}/workflow-session.json > tmp.json && \
  mv tmp.json .workflow/active/${sessionId}/workflow-session.json

これにより、実行中にダッシュボードでセッションが「ACTIVE」と表示されます。

プロセス：

1. TodoWrite リストを作成：タスク JSON ではなく、TODO_LIST.md からタスクリストを生成します
   • TODO_LIST.md を解析し、現在のステータスとともにすべてのタスクを抽出します
   • 依存関係が満たされている最初の保留中タスクを特定します
   • ワークフロー全体を網羅する包括的な TodoWrite を生成します
2. セッションコンテキストを準備：エージェントが使用するワークフローパスを注入します（指定された session-id を使用）
3. 前提条件を検証：IMPL_PLAN.md と TODO_LIST.md が存在し、有効であることを確認します

再開モードの動作：

• .workflow/active/{session-id}/ から既存の TODO_LIST.md を直接読み込みます
• TODO_LIST.md から現在の進捗を抽出します
• TODO_LIST.md の状態から TodoWrite を生成します
• ただちにエージェントの実行に進みます（フェーズ 4）

フェーズ 4：実行戦略の選択とタスクの実行

対象：通常モードと再開モードの両方

ステップ 4A：実行戦略の解析（plan.json を優先し、IMPL_PLAN.md をフォールバックとして使用）

実行戦略には、IMPL_PLAN.md（人が読みやすい形式）よりも plan.json（構造化形式）を優先します。

1. plan.json が存在する場合：recommended_execution、complexity、task_ids[]、shared_context を読み取ります
2. IMPL_PLAN.md にフォールバックする場合：セクション 4 を読み取り、実行モデルを抽出します

以下を抽出します。

• 実行モデル：逐次 | 並列 | フェーズ別 | TDD サイクル
• 並列化の機会：並列実行できるタスク
• 逐次実行の要件：逐次実行が必要なタスク
• クリティカルパス：優先実行順序

どちらにも実行戦略がない場合は、インテリジェントなフォールバックを使用します（タスク構造を分析します）。

ステップ 4B：遅延読み込みによるタスクの実行

重要な最適化：実行に必要になったときにのみ、タスク JSON を読み取ります。

実行ループのパターン：

while (TODO_LIST.md has pending tasks) {
  next_task_id = getTodoWriteInProgressTask()
  task_json = Read(.workflow/active/{session}/.task/{next_task_id}.json)  // Lazy load
  executeTaskWithAgent(task_json)
  updateTodoListMarkCompleted(next_task_id)
  advanceTodoWriteToNextTask()
}

タスクごとの実行プロセス：

1. 次のタスクを特定：TodoWrite から次の in_progress タスク ID を取得します
2. 必要に応じてタスク JSON を読み込み：現在のタスクの .task/{task-id}.json のみを読み取ります
3. タスク構造を検証：必須フィールド（id、title、description、depends_on、convergence）が存在することを確認します
4. エージェントを起動：フロー制御手順を含む完全なコンテキストを指定して、専門のエージェントを呼び出します
5. 進捗を監視：エージェントの実行を追跡し、ユーザーを中断させずにエラーに対処します
6. 結果を収集：実装結果と出力を収集します
7. [with-commit] 自動コミット：--with-commit フラグが有効な場合、要約に基づいて変更をコミットします
   • .summaries/{task-id}-summary.md から要約を読み取ります
   • 要約の「変更したファイル」セクションから変更ファイルを抽出します
   • meta.type からコミットの種類を判定します（feature→feat、bugfix→fix、refactor→refactor）
   • コミットメッセージを生成します：「{type}: {task-title} - {summary-first-line}」
   • 変更したファイルのみをコミットします（最小限の原則）：git add <files> && git commit -m "<message>"
8. ワークフローを続行：TODO_LIST.md から次の保留中のタスクを特定し、繰り返します

注：TODO_LIST.md の更新はオーケストレーターではなく、エージェント（例：code-developer.md）が処理します。

フェーズ 5：完了

対象：通常モードと再開モードの両方

プロセス：

1. タスクの状態を更新：JSON ファイル内の完了したタスクに完了の印を付けます
2. 要約を生成：.summaries/ にタスクの要約を作成します
3. TodoWrite を更新：現在のタスクに完了の印を付け、次のタスクに進みます
4. 状態を同期：セッションの状態とワークフローの状態を更新します
5. ワークフローの完了を確認：すべてのタスクが完了していることを確認します
6. ユーザーの選択：すべてのタスクが完了したら、次のステップをユーザーに選択してもらいます。

// Parse --yes flag
// ★ 统一 auto mode 检测：-y/--yes 从 $ARGUMENTS 或 ccw 传播
const autoYes = /\b(-y|--yes)\b/.test($ARGUMENTS)

if (autoYes) {
  // Auto mode: Complete session automatically
  console.log(`[--yes] Auto-selecting: Complete Session`)
  Skill(skill="workflow:session:complete", args="--yes")
} else {
  // Interactive mode: Ask user
  AskUserQuestion({
    questions: [{
      question: "All tasks completed. What would you like to do next?",
      header: "Next Step",
      multiSelect: false,
      options: [
        {
          label: "Enter Review",
          description: "Run specialized review (security/architecture/quality/action-items)"
        },
        {
          label: "Complete Session",
          description: "Archive session and update manifest"
        }
      ]
    }]
  })
}

ユーザーの選択に応じて：

• 「レビューに進む」：フェーズ 6 を実行 → Ref: phases/06-review.md
• 「セッションを完了」：/workflow:session:complete を実行します

完了後の拡張

自動同期：/workflow:session:sync -y "{summary}" を実行して、specs/*.md と project-tech を更新します。

完了後、issue（test/enhance/refactor/doc）として拡張するかユーザーに確認し、選択された項目について /issue:new "{summary} - {dimension}" を呼び出します。

実行戦略（IMPL_PLAN 主導）

実行戦略の優先順位

IMPL_PLAN 主導の実行（推奨）：

1. IMPL_PLAN.md の実行戦略を読む（セクション 4：実装戦略）
2. 明示的な指示に従う：
   • 実行モデル（逐次／並列／フェーズ別／TDD）
   • 並列化の機会（並列実行できるタスク）
   • 逐次実行の要件（逐次実行が必須のタスク）
   • クリティカルパス（優先実行順序）
3. ステータスの追跡には TODO_LIST.md のみを使用する
4. 「どのように」実行するかは IMPL_PLAN が決定し、workflow-execute が実行する

インテリジェントなフォールバック（IMPL_PLAN に実行の詳細がない場合）：

1. タスク構造を分析する：
   • タスク JSON 内の meta.execution_group を確認する
   • depends_on の関係を分析する
   • タスクの複雑さとリスクを把握する
2. スマートなデフォルトを適用する：
   • 依存関係がなく、同じ execution_group に属する → 並列
   • 依存関係がある → 逐次（依存タスクを待つ）
   • クリティカルなタスク／リスクの高いタスク → 逐次
3. 保守的なアプローチ：不確かな場合は、逐次実行を優先する

実行モデル

1. 逐次実行

適用条件：IMPL_PLAN が「Sequential」を指定している場合、または並列化の明確な指示がない場合 パターン：TODO_LIST の順序に従い、タスクを1つずつ実行する TodoWrite：一度に in_progress としてマークするタスクは1つのみ

2. 並列実行

適用条件：IMPL_PLAN が「Parallel」を指定し、並列化の機会が明確な場合 パターン：複数のエージェントインスタンスを起動し、独立したタスクグループを同時に実行する TodoWrite：同じバッチ内の複数のタスクを同時に in_progress としてマークする エージェントの起動：タスクごとに1つのエージェントインスタンスを起動する（1つのエージェントにつき1つのタスク JSON というルールを遵守）

3. フェーズ別実行

適用条件：IMPL_PLAN がフェーズの内訳とともに「Phased」を指定している場合 パターン：フェーズごとにタスクを実行し、フェーズの境界を遵守する TodoWrite：各フェーズ内では、逐次実行または並列実行のルールに従う

4. インテリジェントなフォールバック

適用条件：IMPL_PLAN に実行戦略の詳細がない場合 パターン：タスク構造を分析し、スマートなデフォルトを適用する TodoWrite：分析に基づき、逐次実行または並列実行のルールに従う

タスクのステータスロジック

pending + dependencies_met → executable
completed → skip
blocked → skip until dependencies clear

TodoWrite の調整

TodoWrite のルール（統一版）

ルール 1：初期作成

• 通常モード：ワークフロー全体で見つかった保留中のタスクから TodoWrite を生成する
• 再開モード：既存のセッション状態と現在の進捗から生成する

ルール 2：進行中タスク数（実行モデルに依存）

• 逐次実行：一度に in_progress としてマークするタスクは1つのみ
• 並列バッチ実行：現在のバッチ内のすべてのタスクを同時に in_progress としてマークする
• 実行グループの表示：並列タスクには [execution_group: group-id] を表示する

ルール 3：ステータスの更新

• 即時更新：ユーザーを中断せずに、各タスク／バッチの完了後にステータスを更新する
• ステータスの同期：更新後、JSON タスクファイルと同期する
• 継続的な追跡：ワークフローの実行中は、完了まで TodoWrite を維持する

ルール 4：ワークフロー完了の確認

• すべてのタスクが completed としてマークされたら、レビューするかセッションを完了するかをユーザーに確認する

TodoWrite ツールの使用方法

例 1：逐次実行

TodoWrite({
  todos: [
    {
      content: "Execute IMPL-1.1: Design auth schema [code-developer] [FLOW_CONTROL]",
      status: "in_progress",  // ONE task in progress
      activeForm: "Executing IMPL-1.1: Design auth schema"
    },
    {
      content: "Execute IMPL-1.2: Implement auth logic [code-developer] [FLOW_CONTROL]",
      status: "pending",
      activeForm: "Executing IMPL-1.2: Implement auth logic"
    }
  ]
});

例 2：並列バッチ実行

TodoWrite({
  todos: [
    {
      content: "Execute IMPL-1.1: Build Auth API [code-developer] [execution_group: parallel-auth-api]",
      status: "in_progress",  // Batch task 1
      activeForm: "Executing IMPL-1.1: Build Auth API"
    },
    {
      content: "Execute IMPL-1.2: Build User UI [code-developer] [execution_group: parallel-ui-comp]",
      status: "in_progress",  // Batch task 2 (running concurrently)
      activeForm: "Executing IMPL-1.2: Build User UI"
    },
    {
      content: "Execute IMPL-1.3: Setup Database [code-developer] [execution_group: parallel-db-schema]",
      status: "in_progress",  // Batch task 3 (running concurrently)
      activeForm: "Executing IMPL-1.3: Setup Database"
    },
    {
      content: "Execute IMPL-2.1: Integration Tests [test-fix-agent] [depends_on: IMPL-1.1, IMPL-1.2, IMPL-1.3]",
      status: "pending",  // Next batch (waits for current batch completion)
      activeForm: "Executing IMPL-2.1: Integration Tests"
    }
  ]
});

エージェントの実行パターン

フロー制御の実行

[FLOW_CONTROL] マーカーは、タスク JSON にコンテキスト準備のための pre_analysis ステップが含まれていることを示します。

注：オーケストレーターはフロー制御のステップを実行しません。エージェントがそれらを自律的に解釈して実行します。

エージェントのプロンプトテンプレート

パスベースの呼び出し：パスとトリガーマーカーを渡し、エージェントにタスク JSON を自律的に解析させます。

Agent(subagent_type="{meta.agent}",
     run_in_background=false,
     prompt="Implement task {task.id}: {task.title}

     [FLOW_CONTROL]

     **Input**:
     - Task JSON: {session.task_json_path}
     - Context Package: {session.context_package_path}

     **Output Location**:
     - Workflow: {session.workflow_dir}
     - TODO List: {session.todo_list_path}
     - Summaries: {session.summaries_dir}

     **Execution**: Read task JSON → Execute pre_analysis → Check execution_config.method → (CLI: handoff to CLI tool | Agent: direct implementation) → Update TODO_LIST.md → Generate summary",
     description="Implement: {task.id}")

主要なマーカー：

• Implement キーワード：技術スタックの検出とガイドラインの読み込みをトリガーします
• [FLOW_CONTROL]：pre_analysis の実行をトリガーします

パスベースである理由：エージェント（code-developer.md）は自律的に次の処理を行います。

• タスク JSON（description、convergence、implementation、execution_config）を読み取り、解析します
• pre_analysis のステップを実行します（フェーズ 1：コンテキストの収集）
• execution_config.method を確認します（フェーズ 2：モードの判定）
• CLI モード：引き継ぎ用プロンプトを作成し、再開戦略を用いて ccw cli から実行します
• エージェントモード：modification_points と logic_flow を使用して直接実装します
• 統合ポイントを含む構造化された要約を生成します

プロンプトにタスクの内容を埋め込むと、重複が生じ、エージェントの解析ロジックと競合します。

エージェントの割り当てルール

meta.agent specified → Use specified agent
meta.agent missing → Infer from meta.type:
  - "feature" → @code-developer
  - "test-gen" → @code-developer
  - "test-fix" → @test-fix-agent
  - "review" → @universal-executor
  - "docs" → @doc-generator

フェーズ参照ドキュメント

フェーズ	ドキュメント	目的
6	phases/06-review.md	実装後の専門レビュー（セキュリティ／アーキテクチャ／品質／対応項目）

ワークフローファイル構成の参照

.workflow/active/WFS-[topic-slug]/
├── workflow-session.json     # Session state and metadata
├── plan.json                # Structured plan overview (machine-readable)
├── IMPL_PLAN.md             # Planning document and requirements (human-readable)
├── TODO_LIST.md             # Progress tracking (updated by agents)
├── .task/                   # Task definitions (JSON only)
│   ├── IMPL-1.json          # Main task definitions
│   └── IMPL-1.1.json        # Subtask definitions
├── .summaries/              # Task completion summaries
│   ├── IMPL-1-summary.md    # Task completion details
│   └── IMPL-1.1-summary.md  # Subtask completion details
└── .process/                # Planning artifacts
    ├── context-package.json # Smart context package
    └── ANALYSIS_RESULTS.md  # Planning analysis results

エラー処理と復旧

よくあるエラーと復旧方法

エラーの種類	原因	復旧方法	最大試行回数
検出エラー
アクティブなセッションがない	.workflow/active/ にセッションがない	セッションを作成または再開します：/workflow-plan "project"	N/A
複数のセッションがある	.workflow/active/ に複数のセッションがある	ユーザーに選択を求めます	N/A
セッションが破損している	JSON ファイルが無効	セッション構造を再作成するか、ファイルを検証します	N/A
実行エラー
エージェントの失敗	エージェントのクラッシュ／タイムアウト	コンテキストを簡略化して再試行します	2
フロー制御エラー	コマンドの失敗	任意のステップはスキップし、必須のステップは失敗とします	ステップごとに 1
コンテキスト読み込みエラー	依存関係の欠落	JSON から再読み込みし、デフォルトを使用します	3
JSON ファイルの破損	ファイルシステムの問題	バックアップから復元するか、再作成します	1

エラーの予防

• 実行前チェック：実行前にセッションの整合性を検証します
• バックアップ戦略：重要な操作の前にタスクのスナップショットを作成します
• アトミック更新：破損を防ぐため、JSON ファイルをアトミックに更新します
• 依存関係の検証：すべての depends_on 参照先が存在することを確認します
• コンテキストの検証：必要なコンテキストがすべて利用可能であることを確認します

自動コミットモード（--with-commit）

動作：各エージェントタスクの完了後、要約ドキュメントに基づいて変更を自動的にコミットします。

最小限の原則：完了したタスクによって変更されたファイルのみをコミットします。

コミットメッセージの形式：{type}: {task-title} - {summary}

タイプの対応関係（meta.type に基づく）：

• feature → feat | bugfix → fix | refactor → refactor
• test-gen → test | docs → docs | review → chore

実装：

# 1. Read summary from .summaries/{task-id}-summary.md
# 2. Extract files from "Files Modified" section
# 3. Commit: git add <files> && git commit -m "{type}: {title} - {summary}"

エラー処理：変更がない場合や要約が見つからない場合はコミットをスキップし、エラーを記録してワークフローを続行します。

関連スキル

前提スキル：

• workflow-plan スキル - 実装計画とタスク JSON を生成します

実行中に呼び出されるもの：

• /workflow:session:complete - すべてのタスク完了後にセッションをアーカイブします
• review-cycle スキル - 実装後のレビュー

後続のスキル：

• /issue:new - フォローアップの課題（テスト／機能強化／リファクタリング／ドキュメント）を作成します