workflow-tdd-plan-plan

TDD 計画（テストファースト開発構造を備えた Red-Green-Refactor タスクチェーンの生成）と TDD 検証（品質ゲートレポートを伴うコンプライアンス検証）を組み合わせた統合 TDD ワークフロースキルです。IMPL_PLAN.md、内部 TDD サイクルを持つタスク JSON、および TDD_COMPLIANCE_REPORT.md を生成します。「workflow-tdd-plan」（計画モード）または「workflow-tdd-verify」（検証モード）でトリガーされます。

1. アーキテクチャの概要

┌──────────────────────────────────────────────────────────────────┐
│  Workflow TDD Orchestrator (SKILL.md)                            │
│  → Route by mode: plan | verify                                  │
│  → Pure coordinator: Execute phases, parse outputs, pass context │
└──────────────────────────────────┬───────────────────────────────┘
                                │
        ┌───────────────────────┴───────────────────────┐
        ↓                                               ↓
  ┌─────────────┐                                ┌───────────┐
  │  Plan Mode  │                                │  Verify   │
  │  (default)  │                                │   Mode    │
  │ Phase 1-6   │                                │  Phase 7  │
  └──────┬──────┘                                └───────────┘
         │
   ┌─────┼─────┬─────┬─────┬─────┐
   ↓     ↓     ↓     ↓     ↓     ↓
 ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐
 │ 1 │ │ 2 │ │ 3 │ │ 4 │ │ 5 │ │ 6 │
 │Ses│ │Ctx│ │Tst│ │Con│ │Gen│ │Val│
 └───┘ └───┘ └───┘ └───┘ └─┬─┘ └───┘
                             ↓
                       ┌───────────┐
                       │ Confirm   │─── Verify ──→ Phase 7
                       │ (choice)  │─── Execute ─→ Skill("workflow-execute")
                       └───────────┘─── Review ──→ Display session status inline

2. 主要な設計原則

1. 純粋なオーケストレーター: SKILL.md はルーティングと調整のみを行い、実行の詳細はフェーズファイルに記述されます
2. 段階的なフェーズ読み込み: そのフェーズが実行される直前にのみ、フェーズドキュメントを読み込みます
3. マルチモードルーティング: 単一のスキルがモード検出によって plan/verify を処理します
4. タスクアタッチメントモデル: サブコマンドタスクはアタッチされ、順次実行された後、コラプスされます
5. 自動継続: 各フェーズが完了した後、次に保留中のフェーズを自動的に実行します
6. TDD 鉄則: 失敗するテストなしにプロダクションコードを書いてはならない - タスク構造で強制されます

3. インタラクティブな設定の収集

フェーズ実行にディスパッチする前に、AskUserQuestion を介してワークフローの設定を収集します:

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

if (autoYes) {
  // 自动模式：跳过所有询问，使用默认值
  workflowPreferences = { autoYes: true }
} else {
  const prefResponse = AskUserQuestion({
    questions: [
      {
        question: "是否跳过所有确认步骤（自动模式）？",
        header: "Auto Mode",
        multiSelect: false,
        options: [
          { label: "Interactive (Recommended)", description: "交互模式，包含确认步骤" },
          { label: "Auto", description: "跳过所有确认，自动执行" }
        ]
      }
    ]
  })

  workflowPreferences = {
    autoYes: prefResponse.autoMode === 'Auto'
  }
}

workflowPreferences はコンテキスト変数としてフェーズ実行に渡され、フェーズ内で workflowPreferences.autoYes として参照されます。

4. モード検出

const args = $ARGUMENTS
const mode = detectMode(args)

function detectMode(args) {
  // Skill trigger determines mode
  if (skillName === 'workflow-tdd-verify') return 'verify'
  return 'plan'  // default: workflow-tdd-plan
}

5. コンパクトリカバリ（フェーズの永続化）

複数フェーズにわたる TDD 計画（フェーズ 1～6/7）は長時間の会話に及びます。二重の保険を使用します: TodoWrite がアクティブフェーズを追跡して圧縮から保護し、sentinel がフォールバックとして機能します。

⚠️ コンパクト指令: コンテキスト圧縮は必ず TodoWrite のフェーズステータスを確認しなければなりません。 現在 in_progress とマークされているフェーズがアクティブな実行フェーズです — その完全な内容を保持してください。 completed または pending とマークされたフェーズのみを圧縮してください。

6. 実行フロー — 計画モード（デフォルト）

Input Parsing:
   └─ Convert user input to TDD structured format (GOAL/SCOPE/CONTEXT/TEST_FOCUS)

Phase 1: Session Discovery
   └─ Read("phases/01-session-discovery.md")
      └─ Output: sessionId (WFS-xxx)

Phase 2: Context Gathering
   └─ Read("phases/02-context-gathering.md")
      ├─ Tasks attached: Analyze structure → Identify integration → Generate package
      └─ Output: contextPath + conflictRisk

Phase 3: Test Coverage Analysis
   └─ Read("phases/03-test-coverage-analysis.md")
      ├─ Tasks attached: Detect framework → Analyze coverage → Identify gaps
      └─ Output: testContextPath

Phase 4: Conflict Resolution (conditional: conflictRisk ≥ medium)
   └─ Decision (conflictRisk check):
      ├─ conflictRisk ≥ medium → Read("phases/04-conflict-resolution.md")
      │   ├─ Tasks attached: Detect conflicts → Log analysis → Apply strategies
      │   └─ Output: conflict-resolution.json
      └─ conflictRisk < medium → Skip to Phase 5

Phase 5: TDD Task Generation
   └─ Read("phases/05-tdd-task-generation.md")
      ├─ Tasks attached: Discovery → Planning → Output
      └─ Output: IMPL_PLAN.md, IMPL-*.json, TODO_LIST.md

Phase 6: TDD Structure Validation
   └─ Read("phases/06-tdd-structure-validation.md")
      └─ Output: Validation report + Plan Confirmation Gate

Plan Confirmation (User Decision Gate):
   └─ Decision (user choice):
      ├─ "Verify TDD Compliance" (Recommended) → Route to Phase 7 (tdd-verify)
      ├─ "Start Execution" → Skill(skill="workflow-execute")
      └─ "Review Status Only" → Display session status inline

7. 実行フロー — 検証モード

Phase 7: TDD Verification
   └─ Read("phases/07-tdd-verify.md")
      └─ Output: TDD_COMPLIANCE_REPORT.md with quality gate recommendation

8. フェーズリファレンスドキュメント

フェーズ実行時に Read("phases/...") を使用してオンデマンドで読み込みます:

フェーズ	ドキュメント	目的	モード	コンパクト
1	phases/01-session-discovery.md	TDD ワークフローセッションの作成または検出	plan	TodoWrite 駆動
2	phases/02-context-gathering.md	プロジェクトコンテキストの収集とコードベースの分析	plan	TodoWrite 駆動
3	phases/03-test-coverage-analysis.md	テストカバレッジの分析とフレームワーク検出	plan	TodoWrite 駆動
4	phases/04-conflict-resolution.md	競合の検出と解決（条件付き）	plan	TodoWrite 駆動
5	phases/05-tdd-task-generation.md	Red-Green-Refactor サイクルを持つ TDD タスクの生成	plan	TodoWrite 駆動 + sentinel
6	phases/06-tdd-structure-validation.md	TDD 構造の検証と確認ゲートの提示	plan	TodoWrite 駆動 + sentinel
7	phases/07-tdd-verify.md	品質ゲートを伴う完全な TDD コンプライアンス検証	verify	TodoWrite 駆動

コンパクトルール:

1. TodoWrite in_progress → 完全な内容を保持し、圧縮を禁止します
2. TodoWrite completed → 要約に圧縮できます
3. sentinel フォールバック → フェーズ 5/6 には compact sentinel が含まれます。コンパクト後に sentinel のみが残り、完全な Step プロトコルが存在しない場合は、直ちに Read() で対応するフェーズファイルを復元しなければなりません

9. コア ルール

1. 即座に開始：最初のアクションでモードを検出して TaskCreate を初期化し、2 番目のアクションでフェーズを実行します
2. 事前分析を行わない：フェーズ 1 の前にファイルを読んだり、構造を分析したり、コンテキストを収集したりしないでください
3. すべての出力を解析：各フェーズの出力から次のフェーズに必要なデータを抽出します
4. TaskList による自動継続：TaskList のステータスを確認し、次の保留中のフェーズを自動的に実行します
5. 進捗を追跡：タスクの添付／折りたたみパターンを用いて、TaskCreate/TaskUpdate を動的に更新します
6. タスク添付モデル：スキルの実行では、サブタスクを現在のワークフローに添付します。オーケストレーターは、添付されたタスクを自ら実行し、完了後に折りたたみます
7. フェーズの段階的な読み込み：そのフェーズを実行する直前に限り、フェーズのドキュメントを読み込みます
8. 停止しない：複数フェーズにわたるワークフローを継続します。添付されたすべてのタスクを実行したら、直ちにそれらを折りたたみ、次のフェーズを実行します
9. TDD コンテキスト：すべての説明に「TDD:」の接頭辞を付けます

10. TDD 準拠要件

鉄則

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST

適用方法：

• フェーズ 5：implementation にテストファーストの手順（Red → Green → Refactor）を含めます
• Green フェーズ：テスト修正サイクルの設定を含めます（最大 3 回の反復）
• 自動復元：テストに合格しないまま最大反復回数に達した場合に実行されます

検証：フェーズ 6 では、生成されたすべてのタスクにおける Red-Green-Refactor の構造を検証します

TDD 準拠チェックポイント

チェックポイント	検証フェーズ	必要な証拠
テストファーストの構造	フェーズ 5	implementation に 3 つのステップがある
Red フェーズの存在	フェーズ 6	ステップ 1：tdd_phase: "red"
テスト修正を伴う Green フェーズ	フェーズ 6	ステップ 2：tdd_phase: "green" + テスト修正サイクル
Refactor フェーズの存在	フェーズ 6	ステップ 3：tdd_phase: "refactor"

TDD のコア原則

危険信号 — 停止して再評価してください：

• テストより先にコードを書く
• テストがすぐに合格する（Red フェーズを確認できていない）
• テストが失敗するはずの理由を説明できない
• 「今回だけは」という正当化
• 「後からテストしても同じ目標を達成できる」という考え方

順序が重要な理由：

• コードを書いた後にテストを書くとすぐに合格するため、何も証明できません
• テストファーストでは、実装前にエッジケースを見つける必要があります
• 後から書くテストで検証できるのは、必要なものではなく、構築したものです

11. 入力処理

ユーザー入力を TDD 構造化形式に変換：

1. 単純なテキスト → TDD コンテキストを追加：

   User: "Build authentication system"
   
   Structured:
   TDD: Authentication System
   GOAL: Build authentication system
   SCOPE: Core authentication features
   CONTEXT: New implementation
   TEST_FOCUS: Authentication scenarios
   

2. 詳細なテキスト → TEST_FOCUS を使って要素を抽出：

   User: "Add JWT authentication with email/password login and token refresh"
   
   Structured:
   TDD: JWT Authentication
   GOAL: Implement JWT-based authentication
   SCOPE: Email/password login, token generation, token refresh endpoints
   CONTEXT: JWT token-based security, refresh token rotation
   TEST_FOCUS: Login flow, token validation, refresh rotation, error cases
   

3. ファイル／Issue → 読み込んで TDD に沿って構成

12. データフロー — Plan モード

User Input (task description)
    ↓
[Convert to TDD Structured Format]
    ↓ Structured Description:
    ↓   TDD: [Feature Name]
    ↓   GOAL: [objective]
    ↓   SCOPE: [boundaries]
    ↓   CONTEXT: [background]
    ↓   TEST_FOCUS: [test scenarios]
    ↓
Phase 1: session:start --auto "TDD: structured-description"
    ↓ Output: sessionId
    ↓
Phase 2: context-gather --session sessionId "structured-description"
    ↓ Input: sessionId + structured description
    ↓ Output: contextPath (context-package.json) + conflictRisk
    ↓
Phase 3: test-context-gather --session sessionId
    ↓ Input: sessionId
    ↓ Output: testContextPath (test-context-package.json)
    ↓
Phase 4: conflict-resolution [conditional: conflictRisk ≥ medium]
    ↓ Input: sessionId + contextPath + conflictRisk
    ↓ Output: conflict-resolution.json
    ↓ Skip if conflictRisk is none/low → proceed directly to Phase 5
    ↓
Phase 5: task-generate-tdd --session sessionId
    ↓ Input: sessionId + all accumulated context
    ↓ Output: IMPL_PLAN.md, IMPL-*.json, TODO_LIST.md
    ↓
Phase 6: TDD Structure Validation (internal)
    ↓ Validate Red-Green-Refactor structure
    ↓ Present Plan Confirmation Gate
    ↓
Plan Confirmation (User Decision Gate):
    ├─ "Verify TDD Compliance" (Recommended) → Route to Phase 7
    ├─ "Start Execution" → Skill(skill="workflow-execute")
    └─ "Review Status Only" → Display session status inline

13. データフロー — Verify モード

Input: --session sessionId (or auto-detect)
    ↓
Phase 7: Session discovery → Chain validation → Coverage analysis → Report
    ↓ Output: TDD_COMPLIANCE_REPORT.md with quality gate

セッションメモリのフロー：各フェーズにはセッション ID が渡され、次の情報にアクセスできます：

• 前のタスクの概要
• 既存のコンテキストと分析
• セッション固有の設定

14. TodoWrite パターン

コア概念：タスクを動的に添付して折りたたみ、TDD ワークフローの実行状況をリアルタイムで可視化します。

実装上の注意：フェーズファイルでは、概念的な追跡パターンを説明するために TodoWrite 構文を使用します。実行時には、これらは TaskCreate/TaskUpdate/TaskList ツールを使って実装されます。次のように対応付けてください：

• 初期リストの作成 → 各項目に対して TaskCreate
• ステータスの変更 → TaskUpdate({ taskId, status })
• サブタスクの添付 → TaskCreate + TaskUpdate({ addBlockedBy })
• サブタスクの折りたたみ → 折りたたんだサブ項目に対して TaskUpdate({ status: "completed" }) + TaskUpdate({ status: "deleted" })

主要な原則

1. タスクの追加（フェーズ実行時）：

   • サブタスクはオーケストレーターの TodoWrite に追加されます
   • フェーズ 3、4、5：複数のサブタスクを追加します
   • フェーズ 1、2、6：単一のタスク（アトミック）
   • 最初に追加されたタスクは in_progress、それ以外は pending に設定されます
   • オーケストレーターは、追加されたタスクを順番に実行します

2. タスクの集約（サブタスク完了後）：

   • フェーズ 3、4、5 に適用：詳細なサブタスクを TodoWrite から削除します
   • 上位レベルのフェーズ概要に集約します
   • フェーズ 1、2、6：集約は不要です（単一タスクなので、完了済みにするだけです）
   • オーケストレーターのビューを整理された状態に保ちます

3. 継続的な実行：完了後、次の保留中のフェーズに自動的に進みます

ライフサイクル：初期状態は保留中 → フェーズ実行（タスクを追加）→ サブタスクを順番に実行 → フェーズ完了（フェーズ 3、4、5 はタスクを集約、フェーズ 1、2、6 は完了済みに設定）→ 次のフェーズ → 繰り返し

初期状態（プランモード）：

[
  {"content": "Phase 1: Session Discovery", "status": "in_progress", "activeForm": "Executing session discovery"},
  {"content": "Phase 2: Context Gathering", "status": "pending", "activeForm": "Executing context gathering"},
  {"content": "Phase 3: Test Coverage Analysis", "status": "pending", "activeForm": "Executing test coverage analysis"},
  {"content": "Phase 5: TDD Task Generation", "status": "pending", "activeForm": "Executing TDD task generation"},
  {"content": "Phase 6: TDD Structure Validation", "status": "pending", "activeForm": "Validating TDD structure"}
]

注：フェーズ 4（競合解決）は、conflictRisk ≥ medium の場合、フェーズ 2 の後に動的に追加されます。

フェーズ 3（タスク追加済み）：

[
  {"content": "Phase 1: Session Discovery", "status": "completed"},
  {"content": "Phase 2: Context Gathering", "status": "completed"},
  {"content": "Phase 3: Test Coverage Analysis", "status": "in_progress"},
  {"content": "  → Detect test framework and conventions", "status": "in_progress"},
  {"content": "  → Analyze existing test coverage", "status": "pending"},
  {"content": "  → Identify coverage gaps", "status": "pending"},
  {"content": "Phase 5: TDD Task Generation", "status": "pending"},
  {"content": "Phase 6: TDD Structure Validation", "status": "pending"}
]

フェーズ 3（集約済み）：

[
  {"content": "Phase 1: Session Discovery", "status": "completed"},
  {"content": "Phase 2: Context Gathering", "status": "completed"},
  {"content": "Phase 3: Test Coverage Analysis", "status": "completed"},
  {"content": "Phase 5: TDD Task Generation", "status": "pending"},
  {"content": "Phase 6: TDD Structure Validation", "status": "pending"}
]

フェーズ 5（タスク追加済み）：

[
  {"content": "Phase 1: Session Discovery", "status": "completed"},
  {"content": "Phase 2: Context Gathering", "status": "completed"},
  {"content": "Phase 3: Test Coverage Analysis", "status": "completed"},
  {"content": "Phase 5: TDD Task Generation", "status": "in_progress"},
  {"content": "  → Discovery - analyze TDD requirements", "status": "in_progress"},
  {"content": "  → Planning - design Red-Green-Refactor cycles", "status": "pending"},
  {"content": "  → Output - generate IMPL tasks with internal TDD phases", "status": "pending"},
  {"content": "Phase 6: TDD Structure Validation", "status": "pending"}
]

注：TodoWrite の更新例の詳細については、各フェーズの説明を参照してください。

15. フェーズ後の更新

メモリ状態の確認

負荷の高いフェーズ（フェーズ 2～3）の後に、コンテキストウィンドウの使用状況を評価します：

• メモリ使用量が多い場合（>110K トークン、またはコンテキスト上限に近づいている場合）：

  Skill(skill="memory-capture")
  

• 分析フェーズの後は、メモリの圧縮が特に重要です

計画メモ（任意）

workflow-plan と同様に、必要に応じて planning-notes.md にフェーズ間のコンテキストを蓄積できます。初期化についてはフェーズ 1 を参照してください。

16. エラー処理

• 解析の失敗：出力の解析に失敗した場合、コマンドを 1 回再試行してからエラーを報告します
• 検証の失敗：不足または無効なファイル／データを報告します
• コマンドの失敗：フェーズを in_progress のままにし、ユーザーにエラーを報告して、先へ進まないでください
• TDD 検証の失敗：不完全なチェーンや誤った依存関係を報告します
• セッションが見つからない（検証モード）：利用可能なセッションの一覧とともにエラーを報告します

エラー処理のクイックリファレンス

エラーの種類	検出方法	回復操作
解析の失敗	出力が空、または形式が不正	1 回再試行してから報告
context-package が見つからない	ファイル読み取りエラー	フェーズ 2（コンテキスト収集）を再実行
タスク JSON が無効	jq の解析エラー	形式が不正なファイルパスを報告
タスク数が 18 を超過	件数の検証結果が ≥19	スコープの再設定を依頼し、複数のセッションに分割
cli_execution.id がない	すべてのタスクに ID がない	フェーズ 0 のユーザー設定を使ってタスクを再生成
test-context がない	ファイルが見つからない	フェーズ 3（テストカバレッジ分析）を再実行
フェーズのタイムアウト	応答なし	フェーズを再試行し、CLI の接続状況を確認
CLI ツールが利用できない	cli-tools.json にツールがない	代替の優先ツールにフォールバック

TDD の警告パターン

パターン	警告メッセージ	推奨される対応
タスク数が >10	タスク数が多いことを検出	複数のセッションへの分割を検討
test-fix-cycle がない	Green フェーズに自動取り消しがない	タスク設定に max_iterations: 3 を追加
Red フェーズにテストパスがない	テストファイルのパスが指定されていない	テストファイルのパスを明示的に追加
汎用的なタスク名	「機能を追加」のような曖昧な名前	具体的な動作の説明を使う
リファクタリングの基準がない	リファクタリングフェーズに完了基準がない	リファクタリングの範囲を明確に定義

実行を妨げない警告ポリシー

警告はすべて助言であり、実行を停止しません：

1. 警告は .process/tdd-warnings.log に記録されます
2. 要約はフェーズ 6 の出力に表示されます
3. workflow-execute スキルの前に対処するかどうかは、ユーザーが判断します

17. コーディネーターのチェックリスト — 計画モード

• フェーズ前：ユーザー入力をTDDの構造化形式（TDD/GOAL/SCOPE/CONTEXT/TEST_FOCUS）に変換します
• コマンドを実行する前にTaskCreateを初期化します（フェーズ4はフェーズ2の後に動的に追加されます）
• フェーズ1を構造化された説明とともに直ちに実行します
• フェーズ1の出力からセッションIDを解析し、メモリに保存します
• セッションIDと構造化された説明をフェーズ2のコマンドに渡します
• フェーズ2の出力からコンテキストパスを解析し、メモリに保存します
• context-package.jsonからconflictRiskを抽出します：フェーズ4を実行するかどうかを判断します
• sessionIdを指定してフェーズ3（テストカバレッジ分析）を実行します
• フェーズ3の出力からtestContextPathを解析し、メモリに保存します
• conflictRisk ≥ mediumの場合：sessionIdとcontextPathを指定してフェーズ4の競合解決を開始します
• フェーズ4の実行が完了するまで待ち（実行した場合）、conflict-resolution.jsonが作成されたことを確認します
• conflictRiskがnone/lowの場合：フェーズ4をスキップし、フェーズ5に直接進みます
• セッションIDをフェーズ5のコマンド（TDDタスク生成）に渡します
• フェーズ5のすべての出力（IMPL_PLAN.md、IMPL-*.json、TODO_LIST.md）を確認します
• フェーズ6（内部TDD構造検証）を実行します
• 計画確認ゲート：ユーザーに選択肢を提示します（検証 → フェーズ7／実行／ステータス確認）
• ユーザーが検証を選択した場合：Read("phases/07-tdd-verify.md")を読み込み、プロセス内でフェーズ7を実行します
• ユーザーが実行を選択した場合：Skill(skill="workflow-execute")
• ユーザーが確認を選択した場合：セッションのステータスをその場で表示します
• 自動モード（workflowPreferences.autoYes）：「TDD準拠を検証」を自動選択し、APPROVEDの場合はその後、自動的に実行へ進みます
• 各フェーズの後にTaskCreate/TaskUpdateを更新します
• 各フェーズの後、TaskListのステータスに基づいて自動的に次のフェーズに進みます

18. コーディネーターのチェックリスト — 検証モード

• セッションを検出／検証します（--sessionフラグまたは自動検出を使用）
• 検証タスクを指定してTaskCreateを初期化します
• すべてのサブフェーズ（セッション検証 → チェーン検証 → カバレッジ分析 → レポート生成）を通じてフェーズ7を実行します
• 品質ゲートの結果と次のステップの選択肢を提示します

19. 関連スキル

前提となるスキル：

• なし - TDD 計画は単独で完結します（必要に応じて、事前にブレインストーミングコマンドを実行できます）

Plan Mode から呼び出されます（6 フェーズ）：

• /workflow:session:start - フェーズ 1：TDD ワークフローセッションを作成または検出します
• phases/02-context-gathering.md - フェーズ 2：プロジェクトのコンテキストを収集し、コードベースを分析します（インライン）
• phases/03-test-coverage-analysis.md - フェーズ 3：既存のテストパターンとカバレッジを分析します（インライン）
• phases/04-conflict-resolution.md - フェーズ 4：競合を検出して解決します（インライン、条件付き）
• memory-capture スキル - フェーズ 4：メモリを最適化します（コンテキストが上限に近づいている場合）
• phases/05-tdd-task-generation.md - フェーズ 5：Red-Green-Refactor サイクルに基づいて TDD タスクを生成します（インライン）

Verify Mode から呼び出されます：

• phases/07-tdd-verify.md - フェーズ 7：テストカバレッジとサイクルを分析します（インライン）

後続のスキル：

• workflow-tdd-plan スキル（tdd-verify フェーズ）- TDD への準拠を検証します（verify mode から呼び出すこともできます）
• workflow-plan スキル（plan-verify フェーズ）- 計画の品質と依存関係を検証します
• セッションのステータスをインラインで表示 - TDD タスクの内訳を確認します
• Skill(skill="workflow-execute") - TDD の実装を開始します

<auto_mode> workflowPreferences.autoYes が true の場合（-y／--yes フラグで有効）：

• 対話形式の確認プロンプトをすべて省略します
• すべての設定に関する質問でデフォルト値を使用します
• Plan Confirmation Gate で「TDD への準拠を検証」を自動選択します
• 検証後、品質ゲートが APPROVED を返した場合は実行に自動で進みます
• ユーザーの介入なしに、すべてのフェーズを連続して実行します </auto_mode>

<success_criteria>

• スキルのトリガー名からモード（plan または verify）が正しく検出される
• 6 つの plan フェーズが、適切なデータフローを維持して順番に実行される
• フェーズファイルは、各フェーズの実行直前にのみ Read() で段階的に読み込まれる
• TaskCreate/TaskUpdate が attachment/collapse パターンで全フェーズを追跡する
• TDD の鉄則が徹底される：すべてのタスクに Red-Green-Refactor の構造がある
• フェーズ 4（競合の解決）は、conflictRisk レベルに応じて条件付きで実行される
• フェーズ 6 の後に、Plan Confirmation Gate で 3 つの選択肢が提示される
• Verify mode（フェーズ 7）で、品質ゲートを含む TDD_COMPLIANCE_REPORT.md が生成される
• すべての出力が生成される：IMPL_PLAN.md、IMPL-*.json、TODO_LIST.md
• TodoWrite のステータスを通じて、簡潔な復旧時にも実行中のフェーズの内容が保持される
• エラー処理では、解析に失敗した場合に 1 回再試行し、エラーが継続する場合は報告される </success_criteria>