claude-code-conductor 0.2.0__py3-none-any.whl

c3/_template/.claude/skills/dev-workflow.md

@@ -0,0 +1,484 @@
+# Dev Workflow
+
+要件定義から実装・レビューまでを複数エージェントで連携させるフルワークフロー。
+`commands/` の各コマンドからこのファイルを Read して指定フェーズから実行する。
+フェーズ間の遷移はこのファイル内で完結する（外部コマンド呼び出し不要）。
+
+---
+
+## フェーズ A: ヒアリング
+
+`.claude/agents/interviewer.md` を Read してペルソナを採用する。
+
+今日のセッションファイル（`.claude/memory/sessions/YYYYMMDD.tmp`）に以下を追記する（未登録の場合のみ）:
+- `- [ ] ヒアリング` / `- [ ] 設計` / `- [ ] 計画`
+
+### A-1: 目的
+
+AskUserQuestion ツール:
+```json
+{
+  "questions": [{
+    "question": "このプロジェクト・機能の目的を教えてください",
+    "options": [
+      { "label": "新機能の追加", "description": "新しい機能を実装したい" },
+      { "label": "既存機能の改善", "description": "現在の動作を変えたい・良くしたい" },
+      { "label": "バグ修正", "description": "問題のある動作を直したい" },
+      { "label": "リファクタリング", "description": "動作は変えずに内部を整理したい" }
+    ]
+  }]
+}
+```
+
+### A-2: 背景・きっかけ
+
+AskUserQuestion ツール:
+```json
+{
+  "questions": [{
+    "question": "背景・きっかけを教えてください（なぜ今これが必要ですか？）",
+    "options": [
+      { "label": "ユーザーからの要望", "description": "具体的な声があった" },
+      { "label": "ビジネス上の要件", "description": "事業的な理由がある" },
+      { "label": "技術的な負債解消", "description": "将来のために今直したい" },
+      { "label": "パフォーマンス問題", "description": "遅い・重いを解決したい" }
+    ]
+  }]
+}
+```
+
+### A-3: 制約・前提条件
+
+AskUserQuestion ツール:
+```json
+{
+  "questions": [{
+    "question": "制約や前提条件はありますか？（複数選択可）",
+    "options": [
+      { "label": "納期がある", "description": "期日を後で教えてください" },
+      { "label": "既存APIを壊せない", "description": "後方互換性が必要" },
+      { "label": "特定の技術スタックに限定", "description": "使える技術が決まっている" },
+      { "label": "特になし" }
+    ],
+    "multiSelect": true
+  }]
+}
+```
+
+制約を選んだ場合は補足情報（納期の日付など）を追加で確認する。
+
+### A-4: 非機能要件
+
+AskUserQuestion ツール:
+```json
+{
+  "questions": [{
+    "question": "特に重視したい品質特性はありますか？",
+    "options": [
+      { "label": "セキュリティ", "description": "認証・認可・データ保護を重視" },
+      { "label": "パフォーマンス", "description": "速度・スループットを重視" },
+      { "label": "保守性", "description": "読みやすさ・変更しやすさを重視" },
+      { "label": "特になし・バランスよく" }
+    ],
+    "multiSelect": true
+  }]
+}
+```
+
+### A-5: requirements-report の生成と承認
+
+収集した内容をもとに `.claude/reports/requirements-report-YYYYMMDD-HHMMSS.md` に Write する。
+内容を提示した後、AskUserQuestion で確認する:
+
+```json
+{
+  "questions": [{
+    "question": "requirements-report の内容を確認してください。どうしますか？",
+    "options": [
+      { "label": "承認", "description": "設計フェーズへ進む" },
+      { "label": "否認・修正を依頼する", "description": "フィードバックを入力してヒアリングをやり直す" },
+      { "label": "否認・自分でファイルを編集する", "description": "reports/ のファイルを直接編集してから続ける" }
+    ]
+  }]
+}
+```
+
+承認後 → セッションファイルの `- [ ] ヒアリング` を `- [x] ヒアリング` に Edit して**フェーズ B** へ。
+
+**知識蓄積:**
+- 「否認・修正を依頼する」: `## 試みたが失敗したアプローチ` に教訓をルール形式で追記し `patterns` に追加する
+- 承認かつ非自明なアプローチが有効だった場合: `## うまくいったアプローチ` に追記し `patterns` にも追加する
+
+---
+
+## フェーズ B: 設計
+
+`.claude/agents/architect.md` を Read してペルソナを採用する。
+
+**フェーズ A から続いている場合:** 要件はコンテキスト内にあるため読み直し不要。
+**直接開始の場合:** Glob で `.claude/reports/requirements-report-*.md` の最新を Read する。
+
+今日のセッションファイルに以下を追記する（未登録の場合のみ）:
+- `- [ ] 設計` / `- [ ] 計画`
+
+### B-1: 技術スタックの確認
+
+AskUserQuestion ツール:
+```json
+{
+  "questions": [{
+    "question": "技術スタックについて制約はありますか？",
+    "options": [
+      { "label": "既存スタックに合わせる", "description": "使用中の言語・FWに統一する" },
+      { "label": "最適なものを選んでほしい", "description": "推薦に任せる" },
+      { "label": "指定がある", "description": "使う技術を具体的に伝えます" }
+    ]
+  }]
+}
+```
+
+### B-2: 設計と不明点の確認
+
+要件をもとに設計案を作成する。不明点があれば AskUserQuestion ツールで確認する。
+
+### B-3: architecture-report の生成と承認
+
+`.claude/reports/architecture-report-YYYYMMDD-HHMMSS.md` に Write する。
+内容を提示した後、AskUserQuestion で確認する:
+
+```json
+{
+  "questions": [{
+    "question": "architecture-report の内容を確認してください。どうしますか？",
+    "options": [
+      { "label": "承認", "description": "計画フェーズへ進む" },
+      { "label": "否認・修正を依頼する", "description": "フィードバックを入力して設計をやり直す" },
+      { "label": "否認・自分でファイルを編集する", "description": "reports/ のファイルを直接編集してから続ける" }
+    ]
+  }]
+}
+```
+
+承認後 → セッションファイルの `- [ ] 設計` を `- [x] 設計` に Edit して**フェーズ C** へ。
+
+**知識蓄積:**
+- 「否認・修正を依頼する」: `## 試みたが失敗したアプローチ` に教訓をルール形式で追記し `patterns` に追加する
+- 承認かつ非自明なアプローチが有効だった場合: `## うまくいったアプローチ` に追記し `patterns` にも追加する
+
+---
+
+## フェーズ C: 計画
+
+`.claude/agents/planner.md` を Read してペルソナを採用する。
+
+**上流フェーズから続いている場合:** 要件・設計はコンテキスト内にあるため読み直し不要。
+**直接開始またはレビューから戻った場合:** Glob で `.claude/reports/` 内の全レポートを Read する（`[対応予定]` マーク付きの指摘を修正計画に反映する）。
+
+今日のセッションファイルに `- [ ] 計画` を追記する（未登録の場合のみ）。
+
+### C-1: マイルストーンの確認
+
+AskUserQuestion ツール:
+```json
+{
+  "questions": [{
+    "question": "マイルストーン（途中で確認したいポイント）を設けますか？",
+    "options": [
+      { "label": "設ける", "description": "一定の区切りで確認しながら進めたい" },
+      { "label": "設けない", "description": "一気に完了まで進める" }
+    ]
+  }]
+}
+```
+
+### C-2: plan-report の生成と承認
+
+`.claude/reports/plan-report-YYYYMMDD-HHMMSS.md` に Write する。
+内容を提示した後、AskUserQuestion で確認する:
+
+```json
+{
+  "questions": [{
+    "question": "plan-report の内容を確認してください。どうしますか？",
+    "options": [
+      { "label": "承認", "description": "実装フェーズへ進む" },
+      { "label": "否認・修正を依頼する", "description": "フィードバックを入力して計画をやり直す" },
+      { "label": "否認・自分でファイルを編集する", "description": "reports/ のファイルを直接編集してから続ける" }
+    ]
+  }]
+}
+```
+
+承認後 → セッションファイルの `- [ ] 計画` を `- [x] 計画` に Edit して**フェーズ D** へ。
+
+**知識蓄積:**
+- 「否認・修正を依頼する」: `## 試みたが失敗したアプローチ` に教訓をルール形式で追記し `patterns` に追加する
+- 承認かつ非自明なアプローチが有効だった場合: `## うまくいったアプローチ` に追記し `patterns` にも追加する
+
+---
+
+## フェーズ D: TDD
+
+**フェーズ C から続いている場合:** plan-report はコンテキスト内にあるため読み直し不要。
+**直接開始の場合:** Glob で `.claude/reports/plan-report-*.md` の最新を Read する。存在しない場合はフェーズ C から始めるよう案内して終了する。
+
+今日のセッションファイルに以下を追記する（未登録の場合のみ）:
+- `- [ ] tester: Red フェーズ`
+- `- [ ] developer: Green フェーズ`
+- `- [ ] developer: Refactor フェーズ`
+- `- [ ] tester: 最終確認`
+
+### D-0: 実行モード選択
+
+AskUserQuestion ツール:
+```json
+{
+  "questions": [{
+    "question": "TDD サイクルの実行モードを選んでください",
+    "options": [
+      { "label": "TDD 逐次実行", "description": "従来の D-1〜D-5（tester→developer→tester）で1タスクずつ進める" },
+      { "label": "PO 並列実行", "description": "parallel-orchestra で plan-report の独立タスクを git worktree 並列実行する（PO のインストールが必要）" }
+    ]
+  }]
+}
+```
+
+**「TDD 逐次実行」の場合:** D-1 へ進む。
+
+**「PO 並列実行」の場合:**
+1. **最初に必ず** `.claude/skills/parallel-execution.md` を Read する（記憶・推測で進めない）
+2. セッションファイルに `- [ ] PO 並列実行` を追記する
+3. `parallel-execution.md` の手順を完全に守る
+4. 完了後はフェーズ E（レビュー）へ進む
+
+### D-1: tester（Red フェーズ）
+
+Agent ツールで `tester` エージェントを起動する。→ 失敗するテストを先に作成する。
+
+完了後 → セッションファイルの `- [ ] tester: Red フェーズ` を `- [x]` に Edit する。
+
+### D-2: developer（Green フェーズ）
+
+Agent ツールで `developer` エージェントを起動する。→ テストが通る実装を行う。
+
+AskUserQuestion で確認する:
+```json
+{
+  "questions": [{
+    "question": "実装内容を確認してください。どうしますか？",
+    "options": [
+      { "label": "承認", "description": "テスト確認フェーズへ進む" },
+      { "label": "否認・再実装を依頼する", "description": "フィードバックを入力して developer を再起動する" },
+      { "label": "否認・自分でコードを修正する", "description": "自分でコードを修正してから続ける" }
+    ]
+  }]
+}
+```
+
+承認後 → セッションファイルの `- [ ] developer: Green フェーズ` を `- [x]` に Edit する。
+
+**知識蓄積:**
+- 「否認・再実装を依頼する」: `## 試みたが失敗したアプローチ` に教訓をルール形式で追記し `patterns` に追加する
+
+### D-3: tester（確認）
+
+Agent ツールで `tester` エージェントを起動する。→ 全テストの合否を確認する。
+
+AskUserQuestion で確認する:
+```json
+{
+  "questions": [{
+    "question": "テスト結果を確認してください。どうしますか？",
+    "options": [
+      { "label": "全合格・次へ進む", "description": "Refactor フェーズへ進む" },
+      { "label": "不合格あり・再実装を依頼する", "description": "フィードバックを入力して developer を再起動する" },
+      { "label": "不合格あり・自分でコードを修正する", "description": "自分で修正してから tester を再実行する" }
+    ]
+  }]
+}
+```
+
+不合格の場合: D-2（developer）に戻る。合格するまで繰り返す。
+
+### D-4: developer（Refactor フェーズ）
+
+Agent ツールで `developer` エージェントを起動する。→ テストを壊さずにコードを整理する。
+
+完了後 → セッションファイルの `- [ ] developer: Refactor フェーズ` を `- [x]` に Edit する。
+
+### D-5: tester（最終確認）
+
+Agent ツールで `tester` エージェントを起動する。
+
+AskUserQuestion で確認する:
+```json
+{
+  "questions": [{
+    "question": "最終テスト結果と実装内容を確認してください。どうしますか？",
+    "options": [
+      { "label": "承認・レビューへ進む", "description": "レビューフェーズへ進む" },
+      { "label": "否認・修正を依頼する", "description": "フィードバックを入力して再修正を依頼する" },
+      { "label": "否認・自分でコードを修正する", "description": "自分で修正してから再テストする" }
+    ]
+  }]
+}
+```
+
+承認後 → セッションファイルの `- [ ] tester: 最終確認` を `- [x]` に Edit して**フェーズ E** へ。
+
+**知識蓄積:**
+- 「否認・修正を依頼する」: `## 試みたが失敗したアプローチ` に教訓をルール形式で追記し `patterns` に追加する
+
+---
+
+## フェーズ E: レビュー
+
+今日のセッションファイルに以下を追記する（未登録の場合のみ）:
+- `- [ ] code-review`
+- `- [ ] security-review`
+
+### E-1: code-reviewer エージェントの起動
+
+Agent ツールで `code-reviewer` エージェントを起動する。
+
+レポートの指摘の有無で分岐する。
+
+**指摘がない場合:**
+AskUserQuestion で確認する:
+```json
+{
+  "questions": [{
+    "question": "code-review-report を確認してください。どうしますか？",
+    "options": [
+      { "label": "承認・セキュリティレビューへ進む", "description": "問題なし" },
+      { "label": "否認・再レビューを依頼する", "description": "フィードバックを入力して再実行する" }
+    ]
+  }]
+}
+```
+
+承認後 → セッションファイルの `- [ ] code-review` を `- [x]` に Edit して E-2 へ。
+
+**指摘がある場合:**
+指摘一覧をテキストで提示してから AskUserQuestion で方針を確認する:
+```json
+{
+  "questions": [{
+    "question": "code-review-report に指摘があります。対応方針を選択してください。",
+    "options": [
+      { "label": "全て対応する", "description": "全指摘を修正計画に含めてフェーズ C へ" },
+      { "label": "対応する指摘を選ぶ", "description": "指摘ごとに対応する/許容するを決める" },
+      { "label": "全て許容して進む", "description": "全指摘を許容してセキュリティレビューへ進む" },
+      { "label": "否認・再レビューを依頼する", "description": "フィードバックを入力して再実行する" }
+    ]
+  }]
+}
+```
+
+**「全て対応する」の場合:**
+全指摘に `> **[対応予定]**` をマークし、セッションファイルの `- [ ] code-review` を `- [x]` に Edit してから**フェーズ C** へ（内部遷移・Step 0 なし）。
+
+**「対応する指摘を選ぶ」の場合:**
+続けて AskUserQuestion で確認する:
+```json
+{
+  "questions": [{
+    "question": "どの指摘を対応しますか？対応する指摘番号と、許容する指摘の理由を教えてください。"
+  }]
+}
+```
+1. 対応する指摘に `> **[対応予定]**` を追記する
+2. 許容する指摘の直下に `> **[許容]** {理由}` を Edit で追記する（検出記録は削除しない）
+3. セッションファイルの `## うまくいったアプローチ` に `[許容例外] {指摘内容} → {許容理由}` の形式で追記し `patterns` に記録する
+4. セッションファイルの `- [ ] code-review` を `- [x]` に Edit してから**フェーズ C** へ（内部遷移・Step 0 なし）。
+
+**「全て許容して進む」の場合:**
+AskUserQuestion で許容理由を確認する:
+```json
+{
+  "questions": [{
+    "question": "全指摘を許容する理由を教えてください。"
+  }]
+}
+```
+1. 全指摘の直下に `> **[許容]** {理由}` を Edit で追記する（検出記録は削除しない）
+2. セッションファイルの `## うまくいったアプローチ` に `[許容例外] {指摘内容} → {許容理由}` の形式で追記し `patterns` に記録する
+3. セッションファイルの `- [ ] code-review` を `- [x]` に Edit して E-2 へ。
+
+**「否認・再レビューを依頼する」の場合:**
+追加の AskUserQuestion でフィードバックを確認し再実行する。
+セッションファイルの `## 試みたが失敗したアプローチ` に教訓をルール形式で追記し `patterns` に追加する。
+
+---
+
+### E-2: security-reviewer エージェントの起動
+
+Agent ツールで `security-reviewer` エージェントを起動する。
+
+レポートの指摘の有無で分岐する。
+
+**指摘がない場合:**
+AskUserQuestion で確認する:
+```json
+{
+  "questions": [{
+    "question": "security-review-report を確認してください。どうしますか？",
+    "options": [
+      { "label": "承認・完了", "description": "問題なし。コミットを提案する" },
+      { "label": "否認・再診断を依頼する", "description": "フィードバックを入力して再実行する" }
+    ]
+  }]
+}
+```
+
+承認後 → セッションファイルの `- [ ] security-review` を `- [x]` に Edit してコミットを提案する。
+
+**指摘がある場合:**
+指摘一覧をテキストで提示してから AskUserQuestion で方針を確認する:
+```json
+{
+  "questions": [{
+    "question": "security-review-report に指摘があります。対応方針を選択してください。",
+    "options": [
+      { "label": "全て対応する", "description": "全指摘を修正計画に含めてフェーズ C へ" },
+      { "label": "対応する指摘を選ぶ", "description": "指摘ごとに対応する/許容するを決める" },
+      { "label": "全て許容して完了", "description": "全指摘を許容してコミットを提案する" },
+      { "label": "否認・再診断を依頼する", "description": "フィードバックを入力して再実行する" }
+    ]
+  }]
+}
+```
+
+**「全て対応する」の場合:**
+全指摘に `> **[対応予定]**` をマークし、セッションファイルの `- [ ] security-review` を `- [x]` に Edit してから**フェーズ C** へ（内部遷移・Step 0 なし）。
+
+**「対応する指摘を選ぶ」の場合:**
+続けて AskUserQuestion で確認する:
+```json
+{
+  "questions": [{
+    "question": "どの指摘を対応しますか？対応する指摘番号と、許容する指摘の理由を教えてください。"
+  }]
+}
+```
+1. 対応する指摘に `> **[対応予定]**` を追記する
+2. 許容する指摘の直下に `> **[許容]** {理由}` を Edit で追記する（検出記録は削除しない）
+3. セッションファイルの `## うまくいったアプローチ` に `[許容例外] {指摘内容} → {許容理由}` の形式で追記し `patterns` に記録する
+4. セッションファイルの `- [ ] security-review` を `- [x]` に Edit してから**フェーズ C** へ（内部遷移・Step 0 なし）。
+
+**「全て許容して完了」の場合:**
+AskUserQuestion で許容理由を確認する:
+```json
+{
+  "questions": [{
+    "question": "全指摘を許容する理由を教えてください。"
+  }]
+}
+```
+1. 全指摘の直下に `> **[許容]** {理由}` を Edit で追記する（検出記録は削除しない）
+2. セッションファイルの `## うまくいったアプローチ` に `[許容例外] {指摘内容} → {許容理由}` の形式で追記し `patterns` に記録する
+3. セッションファイルの `- [ ] security-review` を `- [x]` に Edit してコミットを提案する。
+
+**「否認・再診断を依頼する」の場合:**
+追加の AskUserQuestion でフィードバックを確認し再実行する。
+セッションファイルの `## 試みたが失敗したアプローチ` に教訓をルール形式で追記し `patterns` に追加する。

c3/_template/.claude/skills/parallel-execution.md

@@ -0,0 +1,121 @@
+# Parallel Execution (parallel-orchestra)
+
+`/develop` の **D-0** で「PO 並列実行」が選ばれたときに Read される手順。
+parallel-orchestra (PO) を subprocess で起動し、plan-report を YAML フロントマター付きマニフェストとして並列実行する。
+
+---
+
+## 前提条件
+
+- `.claude/reports/plan-report-*.md` の最新ファイルに YAML フロントマター（`po_plan_version: "0.1"` を含む）が付いていること
+- `claude-code-conductor` がインストール済みで `c3` コマンドが PATH 上にあること
+
+---
+
+## Step 0: PO の利用可否を確認する
+
+Bash ツールで以下を実行する:
+
+```
+c3 doctor --check po-only --quiet
+```
+
+- 終了コード `0`（出力なし）= PO 利用可能 → Step 1 へ
+- 終了コード `1` = PO 未インストール → 以下の案内文を**そのまま提示**してこのスキルを終了する:
+
+> 並列実行を使うには `pip install parallel-orchestra` を実行してください。
+> 詳細: https://pypi.org/project/parallel-orchestra/
+
+**注意:** 案内はエラーではなく **情報メッセージ**として出すこと。`/develop` 全体は失敗扱いにせず、ユーザーに「逐次実行（D-0 の選択肢 [A]）に切り替える」または「PO をインストールして再実行する」のいずれかを選んでもらう。
+
+---
+
+## Step 1: マニフェストの妥当性確認
+
+1. Glob で `.claude/reports/plan-report-*.md` の最新ファイルパスを取得
+2. Read で内容（フロントマター含む）を確認
+3. Bash で以下を実行:
+
+```
+c3 po dry-run <plan-report-path>
+```
+
+- 終了コード `0` = マニフェスト妥当 → Step 2 へ
+- 終了コード `2` = マニフェストエラー（フィールド欠損・agent 不在等）→ stderr のメッセージを整形してユーザーに提示し、`/start` の **フェーズ C（計画）** を再実行するか手動で plan-report を編集するよう案内してこのスキルを終了する
+- 終了コード `1` = PO 未インストール（Step 0 をすり抜けた場合のフォールバック）→ Step 0 と同じ案内文を出して終了
+
+---
+
+## Step 2: ユーザー承認
+
+承認なしで先に進まない。並列実行は git worktree を作って auto-commit するため副作用が大きい。
+
+1. 親 Claude が plan-report の **フロントマター** を Read で再パースし、以下を要約してテキストで提示:
+   - タスク総数
+   - うち `read_only: false` のタスク数（= 作成される worktree 数）
+   - 各タスクの `id` / `agent` / `writes`（あれば）の表
+2. AskUserQuestion ツールで実行可否を確認:
+
+```json
+{
+  "questions": [{
+    "question": "並列実行を開始してよいですか？",
+    "options": [
+      { "label": "承認", "description": "parallel-orchestra で実行を開始する" },
+      { "label": "max_workers を変更して承認", "description": "次の入力で並列度を指定する（デフォルトは PO 側で 3）" },
+      { "label": "キャンセル", "description": "並列実行を中止する。/develop の D-0 から逐次実行に切り替えられる" }
+    ]
+  }]
+}
+```
+
+- 「max_workers を変更して承認」が選ばれた場合、追加 AskUserQuestion で並列度（整数）を聞く
+- 「キャンセル」の場合、セッションファイルに `## 試みたが失敗したアプローチ` として理由を追記してスキル終了
+
+---
+
+## Step 3: parallel-orchestra を起動する
+
+Bash で以下を実行:
+
+```
+c3 po run <plan-report-path> --report .claude/reports/po-run-report-{timestamp}.json [--max-workers N]
+```
+
+- `{timestamp}` は `YYYYMMDD-HHMMSS` 形式。Bash で `python -c "from datetime import datetime; print(datetime.now().strftime('%Y%m%d-%H%M%S'))"` を実行して取得
+- `--max-workers` は Step 2 でユーザーが指定した場合のみ付与
+- 進捗ダッシュボードはターミナルに直接出力される（親 Claude のコンテキストには末尾の状態のみ流れる）
+
+終了コードと意味:
+
+| exit code | 意味 | 次のアクション |
+|---|---|---|
+| `0` | 全タスク成功 | Step 4 へ |
+| `1` | 1件以上のタスクが失敗 | Step 4 へ（失敗タスクの再実行案内を出す） |
+| `2` | マニフェストエラー（Step 1 をすり抜けた） | エラー内容を提示し計画フェーズへ戻るよう案内してスキル終了 |
+| `3` | runner エラー（claude バイナリ不在等） | `c3 doctor` の結果を提示してスキル終了 |
+
+---
+
+## Step 4: レポートの要約とセッション更新
+
+1. Step 3 で生成された `.claude/reports/po-run-report-{timestamp}.json` を Read
+2. 親 Claude がタスクごとのステータスを Markdown 表に整形してユーザーに提示する:
+   - 列: `id` / `agent` / `status` / `worktree` / `duration` / 失敗時は `last_error_summary`
+3. 失敗タスクがある場合、該当タスクのみ `/develop` の D-A 経路（逐次実行）で再実行する選択肢を AskUserQuestion で提示:
+
+```json
+{
+  "questions": [{
+    "question": "失敗タスクをどうしますか？",
+    "options": [
+      { "label": "逐次実行で再修正する", "description": "失敗タスクのみ /develop の D-A（TDD 逐次）で再実行する" },
+      { "label": "計画フェーズへ戻る", "description": "失敗の原因が設計レベルなら /start のフェーズ C で再計画する" },
+      { "label": "ここで終わる", "description": "現状で停止し、フェーズ E（レビュー）には進まない" }
+    ]
+  }]
+}
+```
+
+4. セッションファイル（`.claude/memory/sessions/YYYYMMDD.tmp`）の `- [ ] PO 並列実行` を `- [x]` に Edit する。失敗タスクが残った場合は `- [ ]` のままにし、失敗内容を `## 試みたが失敗したアプローチ` に追記する
+5. 全タスク成功した場合のみ、フェーズ E（レビュー）へ進む案内を出す

c3/_template/.claude/skills/promoted/index.md

@@ -0,0 +1,5 @@
+# Promoted Skills
+<!-- このファイルは /promote-pattern コマンドが自動で更新する。手動で編集しないこと。 -->
+
+<!-- C3:PROMOTED_SKILLS:BEGIN -->
+<!-- C3:PROMOTED_SKILLS:END -->

c3/_template/.claude/skills/worktree-tdd-workflow.md

@@ -0,0 +1,71 @@
+# Worktree TDD Workflow
+
+ヘッドレス専用の TDD 1サイクル定義。AskUserQuestion を含まない。
+`.claude/agents/tdd-develop.md` から呼び出されることを前提とする。
+
+---
+
+## 前提条件
+
+- `.claude/reports/plan-report-*.md` が存在すること
+- プロダクションコードが worktree 内に配置済みであること
+
+---
+
+## Step 1: tester（現状確認フェーズ）
+
+以下を順番に実行する:
+
+1. `.claude/agents/tester.md` を Read してペルソナ・制約・手順を把握する
+2. Glob で `.claude/reports/plan-report-*.md` の最新ファイルパスを取得し、Read する
+3. Agent ツールを起動する。**subagent_type は指定しない**。プロンプトに以下を注入する:
+   - tester.md の内容（ペルソナ・制約・手順）
+   - plan-report の内容（テスト対象・受け入れ条件）
+   - 「テストが存在しない場合は Red フェーズとして失敗するテストを先に作成してから実行すること」
+   - 以下の手順を必ず守ること:
+     1. Bash ツールでタイムスタンプを取得する:
+        `python -c "from datetime import datetime; print(datetime.now().strftime('%Y%m%d-%H%M%S'))"`
+     2. **Write ツールを呼び出して** `.claude/reports/test-report-{タイムスタンプ}.md` を作成する。テキストで返すだけでは不十分。合格/不合格/スキップ件数・不合格テストのエラーを記載すること
+
+完了後: Glob で `.claude/reports/test-report-*.md` の最新ファイルパスを取得する。
+
+---
+
+## Step 2: 全合格チェック
+
+取得した test-report を Read して合否を確認する。
+
+- **全合格の場合**: 呼び出し元（tdd-develop）に `PASS` と test-report パスを返してワークフローを終了する
+- **不合格あり**: Step 3 へ進む
+
+---
+
+## Step 3: developer（Green フェーズ）
+
+以下を順番に実行する:
+
+1. `.claude/agents/developer.md` を Read してペルソナ・制約・手順を把握する
+2. Agent ツールを起動する。**subagent_type は指定しない**。プロンプトに以下を注入する:
+   - developer.md の内容（ペルソナ・制約・手順）
+   - plan-report の内容
+   - test-report の内容（不合格テストの詳細）
+   - 「test-report の不合格テストをすべて通過させるよう実装すること。テストコードは編集しないこと」
+
+---
+
+## Step 4: tester（Green 確認フェーズ）
+
+以下を順番に実行する:
+
+1. `.claude/agents/tester.md` を Read してペルソナ・制約・手順を把握する（Step 1 のコンテキストが残っていれば省略可）
+2. Agent ツールを起動する。**subagent_type は指定しない**。プロンプトに以下を注入する:
+   - tester.md の内容（ペルソナ・制約・手順）
+   - plan-report の内容
+   - 「developer の実装後のテストを全件実行すること」
+   - 以下の手順を必ず守ること:
+     1. Bash ツールでタイムスタンプを取得する:
+        `python -c "from datetime import datetime; print(datetime.now().strftime('%Y%m%d-%H%M%S'))"`
+     2. **Write ツールを呼び出して** `.claude/reports/test-report-{タイムスタンプ}.md` を作成する。テキストで返すだけでは不十分。合格/不合格/スキップ件数・不合格テストのエラーを記載すること
+
+完了後: Glob で最新 test-report を取得し、合否を確認する。
+呼び出し元（tdd-develop）に結果（`PASS` または `FAIL`）と test-report パスを返してワークフローを終了する。