claude-code-conductor 2.0.0__tar.gz → 2.1.0__tar.gz

{claude_code_conductor-2.0.0 → claude_code_conductor-2.1.0}/.claude/agents/planner.md

@@ -53,29 +53,46 @@ requirements-report・architecture-report・各種レビューレポートを統
 
 plan-report の YAML フロントマターは `parallel-agents` skill（親 Claude の Agent ツール並列起動 + 公式 `isolation: "worktree"`）で並列実行されることを前提に設計する。直列の依存チェーンを書いてしまうと並列実行の意味が消えるので、以下のルールを守る。
 
-**depth 1 制限の注意**: Claude Code のサブエージェントは更にサブエージェントを spawn できない。これにより `tdd-develop`（内部で tester / developer を Agent ツールで呼ぶ設計）は **`parallel-agents` skill の並列起動の対象外** で、親 Claude のペルソナ採用パターンで逐次実行される。よって **`tdd-develop` を含む wave は 1 タスクのみ** が望ましい（複数 tdd-develop を 1 wave に入れても並列度 1 で消化されるだけで意味が薄い）。
-
 ### depends_on の付け方
 
 1. **真の依存だけに絞る** — タスク B がタスク A の出力（コードのシグネチャ・型・関数名・ファイルそのもの）に**実際に依存している**ときのみ `B.depends_on: [A]` とする。「順序を守りたい」「念のため」「同じ機能だから」レベルの依存は書かない
 2. **直列化の自己チェック** — 出力直前に「`depends_on` チェーンの最大長が `タスク数 / 2` を超えていないか」を確認する。N 個のタスクが N-1 段の依存チェーンになっていたら **並列度 1** で並列実行を使う意味がない
 3. **レビュー系タスクは末尾に集約** — `code-reviewer` / `security-reviewer` は `read_only: true` で全 dev タスクに `depends_on` を付ける（すべての実装が終わった後に走る）
 
+### TDD タスクは 3-wave に分解する（v2.1.0+）
+
+v2.1.0 で `tdd-develop` エージェントを廃止した。TDD を伴う機能実装は、planner が以下の **3 タスクペア**に分解する:
+
+| 役割 | agent | 順序 | writes 例 |
+|---|---|---|---|
+| Red: 失敗するテストを書く | `tester` | 先行 | `tests/skills/test_foo.py`, `.claude/reports/test-report-test-foo.md` |
+| Green: 最小実装でテストを通す | `developer` | Red に depends_on | `src/c3/foo.py` |
+| Green 確認: 全テスト合格を確認 | `tester` | Green に depends_on | `.claude/reports/test-report-confirm-foo.md` |
+
+これにより:
+
+- **Red 並列**: 独立機能の Red を 1 wave で並列起動（例: `auth.py` の Red と `payment.py` の Red を同時に書く）
+- **Green 並列**: 各機能の Green を 1 wave で並列起動
+- **Green 確認並列**: 確認 tester を 1 wave で並列起動
+
+4. **TDD タスクの命名規約（推奨）** — `test-{機能}` / `impl-{機能}` / `confirm-{機能}` の 3 タスクで 1 機能を表現する。命名は強制ではないが、レポート整理と `depends_on` の見通しのために統一を推奨する
+5. **test-report ファイル名の衝突回避** — Red 用 tester と Green 確認用 tester は **別 worktree** で動くため物理衝突は起きないが、main 取り込み後の上書きを避けるため `writes` には `.claude/reports/test-report-{task_id}.md` のように **task_id ベース**のファイル名を宣言する。tester agent 内では `report-timestamp` Skill でタイムスタンプ取得 → 出力ファイル名を `writes` 宣言と一致させるよう、各 `prompt` に明記する
+6. **Stuck Signal の経路は変わらない** — developer が 3 回以上同じ問題で詰まった場合 `.claude/reports/debug-needed-*.md` を出力する仕様は維持。Green wave が失敗した場合は `parallel-agents` skill 2-E（リトライ / スキップ / 中断）で吸収する。リトライ時に親 Claude が後続 wave で `systematic-debugger` を呼ぶ運用に統一
+
 ### タスクの粒度（基本: ファイル/モジュール単位）
 
-4. **ファイル/モジュール境界で分解** — 互いに独立したファイル群を別タスクに分ける。例:
-   - `src/auth/login.py` の TDD と `src/payment/checkout.py` の TDD は独立 → 別タスクで並列可能
-   - `src/auth/login.py` と `src/auth/logout.py` は同じモジュール内なら 1 タスクにまとめる、または別タスクで `concurrency_group` を共有
-5. **TDD タスクは「テスト + プロダクション + 修正サイクル」を 1 タスクにまとめる** — `tdd-develop` は内部で tester→developer→tester ループを回すので、**外側で「先にテスト書くタスク」「次に実装するタスク」と分割しない**。1 機能 = 1 TDD タスク
-6. **粒度判断のデフォルト** — 細かすぎ（関数 1 個 = 1 タスク）でも粗すぎ（モジュール全体 = 1 タスク）でもなく、**ファイル / 機能単位**を起点に、依存と独立性を見て調整する
+7. **ファイル/モジュール境界で分解** — 互いに独立したファイル群を別タスクに分ける。例:
+   - `src/auth/login.py` の TDD と `src/payment/checkout.py` の TDD は独立 → 別の 3-wave ペアで並列可能
+   - `src/auth/login.py` と `src/auth/logout.py` は同じモジュール内なら 1 つの 3-wave ペアにまとめる、または別ペアで `concurrency_group` を共有
+8. **粒度判断のデフォルト** — 細かすぎ（関数 1 個 = 1 タスク）でも粗すぎ（モジュール全体 = 1 タスク）でもなく、**ファイル / 機能単位**を起点に、依存と独立性を見て調整する
 
 ### writes フィールドの埋め方
 
-7. **`writes` を必ず列挙（`read_only: true` タスクは除く）** — 各タスクが書き込むファイルパスを `tasks[].writes` に書く。`parallel-agents` skill が並列起動後に各 worktree から `writes` のファイルを取り込むため、欠落していると成果物が main に届かない。ただし `read_only: true`（レビュー系）タスクはファイルを書かないため `writes` フィールド自体を省略すること
-8. **同一ファイルへの書き込みは 1 タスクに集約する** — 複数タスクの `writes` で同じファイルを宣言すると、`parallel-agents` skill が各 worktree から取り込むときにどちらの版を採用すべきか決定不能になる。解消手段は実質的に以下の 2 つに限られる:
-   - **(a) タスクをまとめる** — 同一ファイルを書く処理を 1 タスクに統合する
-   - **(b) そのファイルを書く権限を 1 タスク専属にする** — 他のタスクの `writes` リストから除外する。先行タスクが stub / placeholder を作って後発タスクが上書きする設計は **採用しない**（取り込み時に衝突するため）
-9. **統合ファイル（エントリポイント等）は最後の wave 専属にする** — `main.js` のような「各機能を結線する統合ファイル」は、全機能 wave が出揃った後の最終 wave に専属で書かせる。先行 wave で stub を作る設計は採用しない。代わりに先行 wave は各機能ファイル（例: `calc.js` / `currency.js`）のみを書き、最終 wave がそれらを import して統合する
+9. **`writes` を必ず列挙（`read_only: true` タスクは除く）** — 各タスクが書き込むファイルパスを `tasks[].writes` に書く。`parallel-agents` skill が並列起動後に各 worktree から `writes` のファイルを取り込むため、欠落していると成果物が main に届かない。ただし `read_only: true`（レビュー系）タスクはファイルを書かないため `writes` フィールド自体を省略すること
+10. **同一ファイルへの書き込みは 1 タスクに集約する** — 複数タスクの `writes` で同じファイルを宣言すると、`parallel-agents` skill が各 worktree から取り込むときにどちらの版を採用すべきか決定不能になる。解消手段は実質的に以下の 2 つに限られる:
+    - **(a) タスクをまとめる** — 同一ファイルを書く処理を 1 タスクに統合する
+    - **(b) そのファイルを書く権限を 1 タスク専属にする** — 他のタスクの `writes` リストから除外する。先行タスクが stub / placeholder を作って後発タスクが上書きする設計は **採用しない**（取り込み時に衝突するため）
+11. **統合ファイル（エントリポイント等）は最後の wave 専属にする** — `main.js` のような「各機能を結線する統合ファイル」は、全機能 wave が出揃った後の最終 wave に専属で書かせる。先行 wave で stub を作る設計は採用しない。代わりに先行 wave は各機能ファイル（例: `calc.js` / `currency.js`）のみを書き、最終 wave がそれらを import して統合する
 
 ### 出力直前の自己チェックリスト
 
@@ -85,19 +102,20 @@ plan-report の YAML フロントマターは `parallel-agents` skill（親 Clau
 - [ ] レビュータスク（read_only:true）が全 dev タスクに depends_on を持っているか
 - [ ] `tasks[].id` が一意で、`depends_on` の参照先が全て存在するか
 - [ ] `depends_on` を空配列（`[]`）で書いていないか（無依存ならフィールド自体を省略）
+- [ ] TDD を伴う機能は Red tester / Green developer / 確認 tester の 3 タスクに分解しているか
 
 ### タスクあたりの所要時間制約
 
 `parallel-agents` skill は **親 Claude が Agent ツールで子 Agent の返却を待つ**間ブロックされる。長時間タスクが含まれると全 wave の完了が遅延し、ユーザー体験が著しく悪化する。
 
-10. **1 タスクは 15 分以内に終わる粒度で分解する** — `tdd-develop` の tester→developer→tester ループでも 15 分を上限の目安にする。長くなりそうな機能は (a) ファイル境界でタスク分割、(b) MVP と機能拡張で別タスク化、のいずれかで時間を切る
+12. **1 タスクは 15 分以内に終わる粒度で分解する** — 3-wave 分解した各 task（Red / Green / 確認）それぞれが 15 分以内に収まるよう機能を切る。長くなりそうな機能は (a) ファイル境界でさらに分割、(b) MVP と機能拡張で別 3-wave 化、のいずれかで時間を切る
 - 自己チェックリストに追加: `[ ] 想定実行時間が 15 分を超えるタスクがないか`
 
 ### YAML フロントマターの落とし穴
 
 実装時に踏みやすい入力ミス。dry-run で検出できるが、出力前に planner 側で潰しておく:
 
-11. **`depends_on: []` を空配列で書かない** — `c3 plan validate` の構造チェックで lint されるリスクがある（依存が無いタスクは `depends_on` フィールド**自体を省略**する慣習）
+13. **`depends_on: []` を空配列で書かない** — `c3 plan validate` の構造チェックで lint されるリスクがある（依存が無いタスクは `depends_on` フィールド**自体を省略**する慣習）
 
 ### 直列・並列交互パターンの取り扱い
 
@@ -122,15 +140,15 @@ Stage 1: dev_a, dev_b, dev_c (並列)
 
 ## 自動検査対象（PostToolUse hook）
 
-配布元では `.dev/hooks/_planner_check.py`（PostToolUse Write/Edit）が `.claude/reports/plan-report-*.md` の YAML frontmatter を機械検査する。以下 4 ルールに違反すると stderr に `[PlannerCheck WARN]` または `[PlannerCheck BLOCK]` が出る。planner は出力前に自己点検でこれらを潰すこと。
+配布元では `.dev/hooks/_planner_check.py`（PostToolUse Write/Edit）が `.claude/reports/plan-report-*.md` の YAML frontmatter を機械検査する。以下 3 ルールに違反すると stderr に `[PlannerCheck WARN]` または `[PlannerCheck BLOCK]` が出る。planner は出力前に自己点検でこれらを潰すこと。
+
+> **R1 は v2.1.0 で廃止**（`tdd-develop` agent 廃止に伴う）。`agent: tdd-develop` を含む既存 plan-report は `c3 plan validate` の `agent file not found` で検出される。
 
-- **R1 (tdd-develop writes 完備)** — `agent: tdd-develop` の task の `writes` に、(a) `tests/` で始まるテストファイルの具体的パス、(b) `.claude/reports/test-report-{任意}.md` の具体的パス、の両方を列挙する。glob (`*`) 入りは不可
 - **R2 (reviewer ファイル名は task_id ベース)** — `agent: code-reviewer` / `security-reviewer` の `writes` ファイル名は `task_id` を含む固定名にし、タイムスタンプ（`YYYYMMDD` / `YYYYMMDD-HHMMSS` 形式）を含めない。例: `.claude/reports/code-review-report-review1.md` ✓ / `.claude/reports/code-review-report-20260510.md` ✗。タイムスタンプを動的取得すると writes と実ファイル名が乖離して `parallel-agents` skill の成果物取り込みが破綻する
 - **R3 (`src/c3/_template/` 直接 writes 禁止)** — どの task も `writes` に `src/c3/_template/` パスを含めない（hook が exit 2 でブロック）。`_template/` は `hatch_build.py` がビルド時に `.claude/` から再生成する配布物実体で、直接編集してもビルド時に消失する
 - **R4 (同一 writes パスの順序付け)** — 同じ `writes` パスを複数 task が宣言する場合は、後発 task の `depends_on` で先発 task を参照して順序付けする。順序付けがないと `parallel-agents` skill の成果物取り込みでどちらの版を採用すべきか決定不能になる
 
 これらは hook により自動検出されるが、出力前の自己チェックリストにも追加して事前に潰すこと:
-- [ ] R1: tdd-develop の全 task で writes に test ファイルと test-report が両方含まれているか
 - [ ] R2: reviewer の writes ファイル名は task_id ベース・タイムスタンプなしか
 - [ ] R3: writes に `src/c3/_template/` パスが含まれていないか
 - [ ] R4: 同一 writes パスを宣言する task が depends_on で順序付けされているか
@@ -139,8 +157,8 @@ Stage 1: dev_a, dev_b, dev_c (並列)
 制限:
 - ソースファイルの編集・書き込みは行わない
 - plan-report の YAML フロントマター内で `tasks[].id` の重複・未定義の `depends_on` 参照・エージェント名の typo を出力しない（`c3 plan validate` で検証可能）
-- 上記「並列実行のための設計指針」のルール 1〜11 と自己チェックリストに違反した plan-report を出力しない
-- 自動検査対象 R1〜R4 に違反する plan-report を出力しない（`.dev/hooks/_planner_check.py` が PostToolUse で検出する）
+- 上記「並列実行のための設計指針」のルール 1〜13 と自己チェックリストに違反した plan-report を出力しない
+- 自動検査対象 R2〜R4 に違反する plan-report を出力しない（`.dev/hooks/_planner_check.py` が PostToolUse で検出する）
 
 ## Related Agents
 - 上流: architect（architecture-report を受け取る）

{claude_code_conductor-2.0.0 → claude_code_conductor-2.1.0}/.claude/hooks/session_utils.py

@@ -86,7 +86,7 @@ def extract_section(content: str, heading: str) -> str:
 def append_checkpoint(session_file: str, label: str, summary: str) -> None:
     """Append a checkpoint block to the session file.
 
-    Used by wave-execution (milestone snapshots) and pre_compact.py
+    Used by parallel-agents skill (wave milestone snapshots) and pre_compact.py
     (compaction markers). Checkpoint blocks are append-only — they record
     the state at a point in time and never overwrite earlier entries.
 

{claude_code_conductor-2.0.0 → claude_code_conductor-2.1.0}/.claude/hooks/worktree_guard.py

@@ -2,8 +2,8 @@
 """PreToolUse hook: worktree boundary guardrail.
 
 PO_WORKTREE_GUARD=1 が設定されている場合のみ動作する。
-worktree 内で実装タスクを実行するワークフロー（tdd-develop など）が
-事前にこの env を設定して有効化する。
+worktree 内で実装タスクを実行するワークフロー（parallel-agents skill が
+isolation:"worktree" 付きで起動する agent など）が事前にこの env を設定して有効化する。
 Write / Edit ツールの対象パスが CWD（worktree ルート）外であればブロックする。
 """
 

{claude_code_conductor-2.0.0 → claude_code_conductor-2.1.0}/.claude/skills/dev-workflow/SKILL.md

@@ -1,5 +1,5 @@
 ---
-description: ヒアリング→設計→計画→実装→レビューの全フェーズワークフロー。/start・/develop・/code-review・wave-execution スキルが内部参照する。
+description: ヒアリング→設計→計画→実装→レビューの全フェーズワークフロー。/start・/develop・/code-review スキルが内部参照する。
 disable-model-invocation: false
 user-invocable: false
 ---
@@ -228,7 +228,7 @@ plan-report の全タスクを走査し、以下の形式でテキスト出力
 ...
 ```
 
-`read_only: false` のタスクに `tdd-develop` 以外の agent（例: `developer`）が使われている場合は、
+`read_only: false` のタスクに `tester` / `developer` 以外の agent が使われている場合は、
 その理由をテキストで説明した上で承認を求めること。
 
 内容を提示した後、AskUserQuestion で確認する:
@@ -264,8 +264,8 @@ plan-report の全タスクを走査し、以下の形式でテキスト出力
 plan-report の冒頭を Read し、YAML フロントマター（`---` で始まり `po_plan_version: "0.1"` を含む）の有無を確認する。
 
 **フロントマターありの場合:**
-1. **最初に必ず** `.claude/skills/wave-execution/SKILL.md` を Read する（記憶・推測で進めない）
-2. `.claude/skills/wave-execution/SKILL.md` の手順に完全に従って wave 単位で実装を進める
+1. **最初に必ず** `.claude/skills/parallel-agents/SKILL.md` を Read する（記憶・推測で進めない）
+2. `.claude/skills/parallel-agents/SKILL.md` の手順に完全に従って wave 単位で実装を進める
 3. 全 wave 完了後はフェーズ E（レビュー）へ進む（wave に reviewer タスクが含まれていれば E をスキップ可能と案内する）
 
 **フロントマターなしの場合（legacy フォールバック）:**

{claude_code_conductor-2.0.0 → claude_code_conductor-2.1.0}/.claude/skills/develop/SKILL.md

@@ -16,4 +16,7 @@ plan-report に基づいて実装フェーズを実行する。
 
 ## 移行注意（v1.12.0+）
 
-v1.12.0 で並列実行レイヤを PO（Parallel Orchestra）から `parallel-agents` skill に切り替えた。旧 `wave-execution.md` 経由の PO 委譲は v1.14.0 で削除予定。詳細は `~/.claude/plans/atomic-foraging-sprout.md`。
+- v1.12.0 で並列実行レイヤを PO（Parallel Orchestra）から `parallel-agents` skill に切り替えた
+- v1.14.0 で旧 `wave-execution.md` 経由の PO 委譲を削除
+- v2.0.0 で `parallel_orchestra` パッケージ本体を削除
+- v2.1.0 で `tdd-develop` agent と `worktree-tdd-workflow` skill を廃止し、planner が TDD を 3-wave (Red tester / Green developer / Green 確認 tester) に分解する設計に統一

{claude_code_conductor-2.0.0 → claude_code_conductor-2.1.0}/.claude/skills/parallel-agents/SKILL.md

@@ -17,21 +17,11 @@ permission race の構造的修正（2026-05-11 PoC で 15 並列・101 tool 呼
 
 ---
 
-## 重要な制約: depth 1 制限
+## depth 1 制限について
 
-Claude Code のサブエージェントは **更にサブエージェントを spawn できない**（公式仕様 depth 1 制限）。これにより:
+Claude Code のサブエージェントは **更にサブエージェントを spawn できない**（公式仕様 depth 1 制限）。v2.1.0 時点で配布されている全 agent（`developer` / `tester` / `code-reviewer` / `security-reviewer` / `architect` / `interviewer` / `planner` / `doc-writer` / `systematic-debugger` / `project-setup`）は内部で Agent ツールを使わない設計のため、**すべて並列起動可能**。
 
-| agent 種別 | 並列起動可否 | 理由 |
-|---|---|---|
-| `developer` / `tester` / `code-reviewer` / `security-reviewer` 等 | **可** | 内部で Agent ツールを使わない |
-| `tdd-develop` | **不可** | 内部で tester / developer を Agent ツールで spawn する設計 |
-
-`tdd-develop` を含むタスクは次のいずれかで実行する:
-
-- **ペルソナ採用パターン**: 親 Claude が `.claude/agents/tdd-develop.md` を Read して直接実行（並列度 1）
-- **PO 委譲フォールバック**: `c3 po run-wave` で claude -p --agent 起動（v1.14.0 までの暫定）
-
-planner エージェントが plan-report を生成する時点で「tdd-develop を含む wave は 1 タスクのみ」と粒度を制御することが望ましい。
+将来的に「内部で Agent ツールを使う agent」を追加する場合は、その agent を含む wave のタスク数を 1 に絞る運用ガードが必要になる（v2.0.0 まで存在した `tdd-develop` agent はこのパターンだった）。
 
 ---
 
@@ -92,7 +82,7 @@ stdout の JSON 形式:
 
 セッションファイル（`.claude/memory/sessions/YYYYMMDD.tmp`）に未登録の場合のみ以下を追記:
 - 各 wave につき `- [ ] Wave {N} ({task_count} tasks, parallel={M})` を 1 行ずつ
-  - `M` は wave 内で `tdd-develop` 以外の並列化可能タスク数
+  - `M` は wave 内のタスク数（全 agent が並列起動可能）
 
 ---
 
@@ -104,15 +94,13 @@ stdout の JSON 形式:
 
 親 Claude が wave のタスク一覧を Markdown 表で提示する:
 
-| id | agent | parallelizable | read_only | writes |
-|---|---|---|---|---|
-| dev-login | developer | yes | false | src/auth/login.py |
-| dev-logout | developer | yes | false | src/auth/logout.py |
-| tdd-mfa | tdd-develop | **no (depth 1)** | false | src/auth/mfa.py |
+| id | agent | read_only | writes |
+|---|---|---|---|
+| test-login | tester | false | tests/auth/test_login.py, .claude/reports/test-report-test-login.md |
+| impl-login | developer | false | src/auth/login.py |
+| confirm-login | tester | false | .claude/reports/test-report-confirm-login.md |
 
-`parallelizable` は agent 名で判定:
-- `tdd-develop` → `no (depth 1)`
-- それ以外 → `yes`
+v2.1.0 以降、全 agent が並列起動可能のため `parallelizable` 列は省略する。
 
 ### 2-B: 実行可否をユーザーに確認する
 
@@ -121,7 +109,7 @@ AskUserQuestion ツール:
 ```json
 {
   "questions": [{
-    "question": "Wave {N} を実行してよいですか？並列度 {M}、tdd-develop {K} 件は逐次実行。",
+    "question": "Wave {N} を実行してよいですか？並列度 {M}。",
     "options": [
       { "label": "承認・進む", "description": "この wave を実行する" },
       { "label": "中断", "description": "ここで wave 実行を停止する。完了済みの wave はそのまま残る" }
@@ -132,20 +120,7 @@ AskUserQuestion ツール:
 
 「中断」の場合、セッションファイルの `## 試みたが失敗したアプローチ` に中断理由を追記してスキル終了。
 
-### 2-C: タスクを実行する
-
-タスクごとに分岐:
-
-#### 2-C-1: `agent == "tdd-develop"` のとき（ペルソナ採用パターン、並列度 1）
-
-depth 1 制限により Agent ツール起動不可。親 Claude が直接実行する:
-
-1. `.claude/agents/tdd-develop.md` を Read してペルソナを採用する
-2. `.claude/skills/worktree-tdd-workflow/SKILL.md` を Read して TDD ループ手順（tester→developer→tester）を取得する
-3. タスクの `prompt` を実装内容として、worktree-tdd-workflow/SKILL.md の Step 1〜4 を **親 Claude が直接** 実行する。tester / developer は Agent ツールでスポーン可能（親 Claude depth 0 から depth 1 として完結）
-4. ループ完了後、結果を 2-D の集約に渡す
-
-#### 2-C-2: それ以外（並列化対象、Agent ツール並列起動）
+### 2-C: タスクを実行する（並列起動）
 
 並列化可能タスクを **1 ターン内で複数 Agent ツール呼び出し** として発行する。並列度の上限は **デフォルト 5、上限 15**（PoC で検証済み）。タスク数がそれ以上なら 5 件ずつのバッチに分割する。
 
@@ -168,6 +143,8 @@ depth 1 制限により Agent ツール起動不可。親 Claude が直接実行
     - error_summary: {失敗時のエラー要約、無ければ「なし」}
     ```
     」
+  - **tester タスクの場合の追加注入**: 「`.claude/reports/test-report-{task_id}.md` を Write し、writes 宣言と一致させること」
+  - **developer タスクの場合の追加注入**: 「`.claude/reports/debug-needed-*.md` 出力で Stuck Signal を返してよい。systematic-debugger は親 Claude が後続 wave で呼ぶ」
 
 全タスクを 1 メッセージ内で発行したあと、各 Agent の完了通知が `<task-notification>` で順次届く。全件揃うまで待つ。
 
@@ -184,7 +161,7 @@ worktree path は Agent ツール返り値の `<worktree><worktreePath>...</work
 
 ### 2-E: 失敗があったら方針を確認する
 
-並列タスクで 1 件以上失敗した場合（2-C-1 の tdd-develop が不合格の場合も含む）、AskUserQuestion で次を確認する:
+並列タスクで 1 件以上失敗した場合、AskUserQuestion で次を確認する（Green wave の失敗もここで吸収する）:
 
 ```json
 {
@@ -220,7 +197,6 @@ git checkout worktree-agent-{id2} -- src/auth/logout.py
 注意:
 - `writes` フィールドに列挙されたファイルのみを取り込む
 - worktree が touch したが本タスクの責務でない周辺ファイル（`CLAUDE.md` / `package.json` / `.claude/settings.local.json` / `.claude/reports/` 配下）は取り込まない
-- `tdd-develop` の場合は worktree-tdd-workflow.md 内で既に作業ツリーで実装されているため、追加の checkout は不要
 
 #### 2-F-2: 親 Claude が一括コミット
 
@@ -281,10 +257,10 @@ checkpoint の summary には KEEP ルール（設計判断・決定事項・解
 
 ---
 
-## PO 廃止移行期の注意（v1.12.0〜v2.0.0）
+## PO 廃止移行期の注意（v1.12.0〜v2.1.0）
 
 - 本 skill は v1.12.0 で導入された
 - v1.13.0 で `po-status` skill / `c3 status` CLI を削除
-- **v1.14.0 で `c3 po` CLI と `wave-execution` skill を削除し、Step 0/1 で `c3 plan validate` / `c3 plan waves`（純粋な YAML 検証 + DAG 分解、PO 非依存）に切り替えた**
+- v1.14.0 で `c3 po` CLI と `wave-execution` skill を削除し、Step 0/1 で `c3 plan validate` / `c3 plan waves`（純粋な YAML 検証 + DAG 分解、PO 非依存）に切り替えた
 - v2.0.0 で `parallel_orchestra` パッケージ本体を削除（互換破壊）
-- 詳細計画: `~/.claude/plans/atomic-foraging-sprout.md`
+- **v2.1.0 で `tdd-develop` agent と `worktree-tdd-workflow` skill を削除し、planner が 3-wave に分解する設計に統一**

{claude_code_conductor-2.0.0 → claude_code_conductor-2.1.0}/.claude/skills/promote-pattern/SKILL.md

@@ -84,7 +84,7 @@ trust_score: {スコア}
 ```markdown
 ---
 name: promoted-YYYYMMDD-{id}
-description: {昇格理由と期待効果を1文で。例: "wave 実行でのペルソナ採用パターン。tdd-develop を単独 wave で実行する際に自動適用される"}
+description: {昇格理由と期待効果を1文で。例: "security-audit における code-reviewer / security-reviewer の並列起動パターン。2 体のレビュアーを 1 メッセージで同時に当てる"}
 promoted_from: {pattern id}
 promoted_date: YYYY-MM-DD
 trust_score: {スコア}

{claude_code_conductor-2.0.0 → claude_code_conductor-2.1.0}/.claude/skills/start/SKILL.md

@@ -191,8 +191,8 @@ new: TASK_TYPE: {task_type}
     "question": "refactor の作業をどこから始めますか？",
     "header": "開始地点",
     "options": [
-      { "label": "計画", "description": "planner で po_plan_version 付き plan-report を生成して PO 並列実行に備える" },
-      { "label": "実装", "description": "既存 po_plan_version 付き plan-report を使って wave-execution に直接入る" }
+      { "label": "計画", "description": "planner で po_plan_version 付き plan-report を生成して parallel-agents skill 並列実行に備える" },
+      { "label": "実装", "description": "既存 po_plan_version 付き plan-report を使って parallel-agents skill に直接入る" }
     ]
   }]
 }
@@ -243,8 +243,8 @@ new: TASK_TYPE: {task_type}
 | bug-fix | systematic-debugger 直起動 | Agent ツールで `systematic-debugger` を起動 → `developer` → `tester` 完了後、`code-reviewer` と `security-reviewer` を 1 メッセージ内で並列起動 |
 | bug-fix | 計画から | `.claude/skills/dev-workflow/SKILL.md` を Read してフェーズ C から（既存 plan-report を利用） |
 
-| refactor | 計画 | Agent ツールで `planner` を起動して `po_plan_version` 付き plan-report を生成 → `.claude/skills/wave-execution/SKILL.md` を Read |
-| refactor | 実装 | `.claude/skills/wave-execution/SKILL.md` を Read して PO 並列実行に直接入る |
+| refactor | 計画 | Agent ツールで `planner` を起動して `po_plan_version` 付き plan-report を生成 → `.claude/skills/parallel-agents/SKILL.md` を Read |
+| refactor | 実装 | `.claude/skills/parallel-agents/SKILL.md` を Read して並列実行に直接入る |
 | security-audit | 即実行 | Agent ツールで `code-reviewer` と `security-reviewer` を **1 メッセージ内で並列起動** |
 | security-audit | 承認後 | Step 3（フェーズ F/G/H）へ進む（自動遷移） |
 | docs | 即実行 | Agent ツールで `doc-writer` を単独起動 |

{claude_code_conductor-2.0.0 → claude_code_conductor-2.1.0}/.claude/skills/task-routing/SKILL.md

@@ -74,22 +74,22 @@ AskUserQuestion ツール:
 | 1 | `interviewer` | A: ヒアリング |
 | 2 | `architect` | B: 設計 |
 | 3 | `planner` | C: 計画 |
-| 4 | `tester` → `developer` → `tester` → `developer` → `tester` | D: TDD |
+| 4 | `tester` (Red 並列) → `developer` (Green 並列) → `tester` (Green 確認 並列) | D: TDD |
 | 5 | `code-reviewer` → `security-reviewer` | E: レビュー |
 
 意図: 新機能追加は要件定義から計画まで全フェーズが必要。
 **この場合は `/start` を直接呼ぶ方がシンプル。** 本 skill は提示のみ。
 
-### refactor（並列・PO 推奨）
+### refactor（並列・parallel-agents skill 推奨）
 
 | 役割 | エージェント | 並列 |
 |---|---|---|
 | タスク分解 | `planner` | — |
-| 各リファクタタスク | `developer` + `tester` | PO で並列 |
+| 各リファクタタスク | `developer` + `tester` | `parallel-agents` skill で並列 |
 | 最終レビュー | `code-reviewer` | — |
 
 意図: 動作を変えないため、各リファクタを worktree で並列化できる。
-PO（Parallel Orchestra）の `c3 po run` で時間短縮を狙う。
+`parallel-agents` skill（親 Claude の Agent ツール並列起動 + 公式 `isolation: "worktree"`）で時間短縮を狙う。
 最終レビューは `code-reviewer` のみ（リファクタは動作変更を伴わないため新たな攻撃面が生まれにくく、security-reviewer は省略可）。
 
 ### security-audit（並列・レビュアー 2 体）
@@ -148,7 +148,7 @@ AskUserQuestion ツール:
   - `args` 指定なし/`from_start=false` のとき: `.claude/skills/start/SKILL.md` を Read して `/start` フローに合流する
 - **bug-fix**: `systematic-debugger` → `developer` → `tester` の順に Agent ツールで順次起動し、完了後に `code-reviewer` と `security-reviewer` を 1 メッセージ内で並列起動する
 - **docs**: Agent ツールで `doc-writer` を起動する
-- **refactor**: planner で `po_plan_version` 付き plan-report を生成 → `.claude/skills/wave-execution/SKILL.md` を Read して PO 並列実行に合流する
+- **refactor**: planner で `po_plan_version` 付き plan-report を生成 → `.claude/skills/parallel-agents/SKILL.md` を Read して並列実行に合流する
 - **security-audit**: code-reviewer と security-reviewer を **1 メッセージ内で並列起動**（複数 Agent ツール呼び出し）
 
 各エージェント完了後は通常の Approval Flow（AskUserQuestion で承認 / 否認・修正依頼 / 否認・自分で修正）に従う。
@@ -193,7 +193,6 @@ AskUserQuestion ツール:
 - `project-setup` — プロジェクト初期設定
 - `security-reviewer` — セキュリティ診断
 - `systematic-debugger` — デバッグ調査
-- `tdd-develop` — ヘッドレス TDD コンダクター（PO 専用）
 - `tester` — テスト設計・実行
 
 新しいエージェントが `.claude/agents/` に追加された場合は、この skill の編成

{claude_code_conductor-2.0.0 → claude_code_conductor-2.1.0}/.gitignore

@@ -52,10 +52,17 @@ site/
 .claude/docs/c3追加予定機能リスト.md
 .claude/docs/ruflo_research_result.md
 
+# codex 対応調査メモ (個人作業ノート、配布・コミット対象外)
+.claude/docs/codex対応/
+
 # C3 distributor-only (配布元固有の開発支援、配布されない)
 .dev/
 /CLAUDE.md
 
+# v2.1.0: tdd-develop / worktree-tdd-workflow 廃止後の復活防止
+.claude/agents/tdd-develop.md
+.claude/skills/worktree-tdd-workflow/
+
 # Personal Claude Code overrides (per-user / per-worktree, never committed)
 # wheel からは _excludes.py / hatch_build.py で既に除外済み。git でも tracking しない方針。
 .claude/settings.local.json

{claude_code_conductor-2.0.0 → claude_code_conductor-2.1.0}/CHANGELOG.md

@@ -1,5 +1,126 @@
 # Changelog
 
+## [2.1.0] - 2026-05-12
+
+### 概要
+
+v2.0.0 直後の機能整理リリース。**`tdd-develop` agent と `worktree-tdd-workflow` skill を廃止**し、TDD を planner が **3-wave（Red tester 並列 → Green developer 並列 → Green 確認 tester 並列）に分解する**設計に統一した。これにより depth 1 制限で逐次実行に縛られていた TDD タスクが独立機能間で完全並列化される。
+
+v2.0.0 で残っていた PO / `wave-execution` / `c3 po` 言及の移行漏れ（`task-routing` / `start` / `dev-workflow` / `develop` / `promote-pattern` 各 skill、`docs/skills.md` / `docs/cli-reference.md` / `docs/index.md` / `docs/getting-started.md` / `README.md`、`worktree_guard.py` / `session_utils.py` の docstring）も併せて修正した。
+
+### 削除（minor、利用先での手動 cleanup 必要）
+
+| パス | 代替 |
+|---|---|
+| `.claude/agents/tdd-develop.md` | planner が 3-wave に分解して `tester` / `developer` を並列起動 |
+| `.claude/skills/worktree-tdd-workflow/SKILL.md` | `parallel-agents` skill が直接 tester / developer を起動 |
+
+### 変更
+
+#### planner エージェント
+- 「並列実行のための設計指針」を 3-wave 分解指針に書き換え（旧ルール「TDD は 1 タスクにまとめる」を削除）
+- 命名規約 `test-` / `impl-` / `confirm-` を推奨（強制ではない）
+- `writes` の test-report ファイル名は `.claude/reports/test-report-{task_id}.md` のように task_id ベースを推奨
+- depth 1 制限の tdd-develop 言及を削除
+- R1 自動検査の説明を削除（hook 本体も削除）
+
+#### parallel-agents skill
+- depth 1 制限テーブルから tdd-develop 行削除し、全 agent 並列起動可能になった旨を明記
+- 「2-C-1 tdd-develop ペルソナ採用」ブロック削除し、並列起動を単一手順に統合
+- tester / developer 向けのプロンプト注入を強化
+
+#### 自動検査 hook（配布元）
+- `.dev/hooks/_planner_check.py`: R1（tdd-develop writes 検査）を削除。R2/R3/R4 は維持
+- `tests/hooks/test_planner_check.py`: R1 系テストクラスを削除、R3 テストの tdd-develop 依存を除去
+
+#### 配布除外（3 ファイル同期）
+- `src/c3/_excludes.py` / `hatch_build.py` / `.gitignore` に `agents/tdd-develop.md` と `skills/worktree-tdd-workflow/*` を追加
+
+#### v2.0.0 移行漏れの hotfix
+- `task-routing/SKILL.md`: refactor 編成の `c3 po run` / PO 推奨を `parallel-agents` skill に置換、`wave-execution` 参照を更新、tdd-develop 行削除、feature の TDD 表記を 3-wave に更新
+- `start/SKILL.md`: PO 並列実行 / wave-execution.md 参照を `parallel-agents` に置換
+- `dev-workflow/SKILL.md`: description / 本文の `wave-execution` 参照を `parallel-agents` に修正、tdd-develop 言及削除
+- `develop/SKILL.md`: PO 廃止履歴と v2.1.0 の tdd-develop 廃止を追記
+- `promote-pattern/SKILL.md`: description 例文の tdd-develop 言及を別例に差し替え
+- `worktree_guard.py` / `session_utils.py`: docstring から tdd-develop / wave-execution 言及を更新
+- `docs/skills.md` / `docs/cli-reference.md` / `docs/index.md` / `docs/getting-started.md` / `README.md`: PO / wave-execution / tdd-develop / `c3 po` の陳腐化記述を削除・修正
+
+### 移行ガイド
+
+#### 利用先プロジェクトでの手動 cleanup
+
+`c3 update` は **ファイル削除を検出しない**ため、利用先で以下を手動実行する:
+
+```bash
+rm -f .claude/agents/tdd-develop.md
+rm -rf .claude/skills/worktree-tdd-workflow
+```
+
+#### 既存 plan-report の書き換え
+
+`agent: tdd-develop` を含む plan-report は `c3 plan validate` が `agent file not found` で失敗するため、以下のように 3 タスクに展開する:
+
+**Before（v2.0.0）:**
+```yaml
+tasks:
+  - id: tdd-login
+    agent: tdd-develop
+    writes:
+      - tests/auth/test_login.py
+      - src/auth/login.py
+      - .claude/reports/test-report-tdd-login.md
+    prompt: "ログイン機能を TDD で実装する"
+```
+
+**After（v2.1.0+）:**
+```yaml
+tasks:
+  - id: test-login
+    agent: tester
+    writes:
+      - tests/auth/test_login.py
+      - .claude/reports/test-report-test-login.md
+    prompt: |
+      Red フェーズ。ログイン機能の失敗テストを書き、機能未実装で正しく失敗することを確認する。
+      writes 宣言と一致するファイル名で test-report を Write すること。
+  - id: impl-login
+    agent: developer
+    depends_on: [test-login]
+    writes:
+      - src/auth/login.py
+    prompt: |
+      Green フェーズ。test-login の test-report の不合格テストを通す最小実装を行う。
+      テストコードは編集しない。
+  - id: confirm-login
+    agent: tester
+    depends_on: [impl-login]
+    writes:
+      - .claude/reports/test-report-confirm-login.md
+    prompt: |
+      Green 確認。全テストを実行して合格を確認する。
+      writes 宣言と一致するファイル名で test-report を Write すること。
+```
+
+3-wave 化により、独立した複数機能（auth / payment 等）の Red を 1 wave で並列起動できる。
+
+#### Green wave 失敗時の運用
+
+`impl-*` タスクが失敗した場合は `parallel-agents` skill の 2-E（リトライ / スキップ / 中断）で吸収する。developer 内の Stuck Signal（`.claude/reports/debug-needed-*.md` 出力）は引き続き機能する。リトライ時に親 Claude が後続 wave で `systematic-debugger` を呼ぶ運用に統一。
+
+### LTS / 互換性
+
+- v1.x からのアップグレードは引き続き v2.0.0 経由で行う（v1.x → v2.1.0 直接は未検証）
+- v2.0.x 系を維持したい場合は `pip install "claude-code-conductor>=2.0,<2.1"`
+- SemVer minor: agent / skill 削除はあるが、利用先 API（CLI / Python import）は無変更
+
+### 検証
+
+- `pytest -x` 572 passed / 2 skipped
+- wheel に `agents/tdd-develop.md` / `skills/worktree-tdd-workflow/` のエントリ 0 件
+- `_planner_check.py` が 3-wave plan-report に対して R1 警告を出さない（R1 自体が削除されている）
+
+---
+
 ## [2.0.0] - 2026-05-12
 
 ### 概要（互換破壊リリース）

{claude_code_conductor-2.0.0 → claude_code_conductor-2.1.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: claude-code-conductor
-Version: 2.0.0
+Version: 2.1.0
 Summary: Multi-agent orchestration framework for Claude Code (C3)
 Project-URL: Homepage, https://github.com/satoh-y-0323/claude-code-conductor
 Project-URL: Repository, https://github.com/satoh-y-0323/claude-code-conductor
@@ -188,11 +188,9 @@ C3 のスラッシュコマンドはすべてスキル（`skills/{name}/SKILL.md
 | `c3 init` | 利用先プロジェクトに `.claude/` を展開する |
 | `c3 update` | `.claude/` をパッケージ最新版へ更新する（個人ファイルはスキップ） |
 | `c3 list-agents` / `list-skills` | 設置済みアセットを一覧表示 |
-| `c3 doctor` | 環境診断（`.claude/`・settings.json・claude バイナリ・parallel-orchestra） |
-| `c3 po dry-run <plan-report>` | plan-report をマニフェストとして検証 |
-| `c3 po waves <plan-report>` | plan-report の wave 分解結果を JSON で出力 |
-| `c3 po run <plan-report>` | plan-report を parallel-orchestra で全 wave 並列実行 |
-| `c3 po run-wave <plan-report> --wave-index N` | 指定 wave のみ実行 |
+| `c3 doctor` | 環境診断（`.claude/`・settings.json・claude バイナリ） |
+| `c3 plan validate <plan-report>` | plan-report の YAML フロントマターと agent 存在を検証 |
+| `c3 plan waves <plan-report>` | plan-report の wave 分解結果を JSON で出力 |
 
 ### 基本的な使い方
 
@@ -217,7 +215,6 @@ C3 のスラッシュコマンドはすべてスキル（`skills/{name}/SKILL.md
 | planner | opus | plan-report | 親 Claude がペルソナ採用 |
 | developer | sonnet | 実装コード | Agent ツールで起動 |
 | tester | sonnet | テスト・test-report | Agent ツールで起動 |
-| tdd-develop | sonnet | - | Agent ツールで起動（PO 並列時のみ）|
 | code-reviewer | sonnet | code-review-report | Agent ツールで起動 |
 | security-reviewer | sonnet | security-review-report | Agent ツールで起動 |
 | doc-writer | sonnet | ドキュメント各種 | Agent ツールで起動 |
@@ -343,19 +340,19 @@ Copy-Item -Recurse claude-code-conductor\.claude your-project\
 
 ---
 
-## 並列実行 (parallel-orchestra)
+## 並列実行 (parallel-agents skill)
 
-計画フェーズで生成した plan-report を YAML フロントマター付きマニフェストとして parallel-orchestra (PO) に渡し、独立タスクを git worktree で並列実行できます。
+計画フェーズで生成した plan-report を YAML フロントマター付きマニフェストとして読み込み、独立タスクを親 Claude の Agent ツール並列起動 + 公式 `isolation: "worktree"` で並列実行できます（v2.0.0 以降は外部プロセス不要）。
 
-PO は C3 に同梱されているため、`pip install claude-code-conductor` だけで利用可能です。別途のインストールは不要。要件は Python ≥ 3.10、PATH に `claude` バイナリ、PyYAML（C3 の依存として自動インストール）。
+要件は Python ≥ 3.10、PATH に `claude` バイナリ、PyYAML（C3 の依存として自動インストール）。
 
 **使い方:**
 
-1. `/start` で要件→設計→計画フェーズを完走させる（planner が plan-report の先頭に PO 用 YAML フロントマターを自動付与します）
-2. `/develop` を起動 → **D-0** で plan-report のフロントマターを自動検出し PO 並列モードへ切り替わる
-3. C3 が `c3 po dry-run` でマニフェスト妥当性を検証、wave ごとにユーザー承認を取りながら `c3 po run-wave` で実行します
+1. `/start` で要件→設計→計画フェーズを完走させる（planner が plan-report の先頭に YAML フロントマターを自動付与します）
+2. `/develop` を起動 → **D-0** で plan-report のフロントマターを自動検出し `parallel-agents` skill へ切り替わる
+3. C3 が `c3 plan validate` でマニフェスト妥当性を検証、wave ごとにユーザー承認を取りながら Agent ツールで並列実行します
 
-マニフェスト仕様の詳細は `.claude/docs/parallel-orchestra-manifest.md` を参照してください。
+TDD を伴う機能実装は、planner が「test- → impl- → confirm-」の 3 タスクペアに分解し、各 wave 内で独立機能間で並列起動されます（v2.1.0+、旧 `tdd-develop` agent はこのリリースで廃止）。
 
 ---