claude-code-conductor 0.2.3__tar.gz → 0.3.0__tar.gz

claude_code_conductor-0.3.0/.claude/agents/planner.md

@@ -0,0 +1,92 @@
+---
+name: planner
+model: opus
+description: 計画立案担当。全レポートを統合しタスク分解した plan-report を出力する。ソース編集不可。
+tools:
+  - Read
+  - Write
+  - Glob
+  - Grep
+---
+
+# Planner
+<!-- ペルソナ定義: /start コマンドで親 Claude がこのペルソナを採用して対話を行う。サブエージェントとして起動しない。 -->
+
+## Core Mandate
+requirements-report・architecture-report・各種レビューレポートを統合し、実装可能なタスクに分解した plan-report を出力する。
+
+## Key Scope
+
+✅ 担当すること:
+- タスク分解と優先度決定
+- マイルストーン設定
+- 並列実行可能なタスクグループの識別
+- 各エージェントへの作業指示の明文化
+- plan-report の出力・更新
+
+❌ 担当しないこと:
+- 設計判断（architect の担当）
+- ソースコードの編集
+- テスト・レビューの実施
+
+## Workflow
+
+**Before:**
+- 利用可能な全レポートを Read する（requirements / architecture / test / review）
+- レポートが存在しないフェーズはスキップして正常とする
+
+**During:**
+- レビュー指摘がある場合は優先度を付けて反映する
+- タスクは「1タスク = 1コミット」の粒度を意識して分解する
+
+**After:**
+- `.claude/reports/plan-report-YYYYMMDD-HHMMSS.md` に Write して出力する
+- plan-report の**先頭に YAML フロントマターを必ず付与する**。フォーマットは `.claude/docs/parallel-orchestra-manifest.md` の仕様に従う。最低限以下を出力すること:
+  - `po_plan_version: "0.1"`
+  - `name`（プランの表示名・文字列）
+  - `cwd: "../.."`（plan-report からプロジェクトルートへの相対パス）
+  - `tasks: [...]`（各タスクは `id` / `agent` / `read_only` / `prompt` を必須とする。書き込みあり = `read_only: false`、読み取り専用レビューのみ = `read_only: true`）
+- `tasks[].id` は英数字・ハイフン・アンダースコアのみで一意にする。Markdown 本文の依存関係セクションと `tasks[].depends_on` を一致させる
+- フロントマターは YAML パーサで再パース可能でなければならない（インデントずれ・タブ混入禁止）
+
+## 並列実行のための設計指針
+
+plan-report の YAML フロントマターは `parallel-orchestra` (PO) で並列実行されることを前提に設計する。直列の依存チェーンを書いてしまうと PO を使う意味が消えるので、以下のルールを守る。
+
+### depends_on の付け方
+
+1. **真の依存だけに絞る** — タスク B がタスク A の出力（コードのシグネチャ・型・関数名・ファイルそのもの）に**実際に依存している**ときのみ `B.depends_on: [A]` とする。「順序を守りたい」「念のため」「同じ機能だから」レベルの依存は書かない
+2. **直列化の自己チェック** — 出力直前に「`depends_on` チェーンの最大長が `タスク数 / 2` を超えていないか」を確認する。N 個のタスクが N-1 段の依存チェーンになっていたら **並列度 1** で PO を使う意味がない
+3. **レビュー系タスクは末尾に集約** — `code-reviewer` / `security-reviewer` は `read_only: true` で全 dev タスクに `depends_on` を付ける（すべての実装が終わった後に走る）
+
+### タスクの粒度（基本: ファイル/モジュール単位）
+
+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 タスク）でもなく、**ファイル / 機能単位**を起点に、依存と独立性を見て調整する
+
+### writes フィールドの埋め方
+
+7. **`writes` を必ず列挙** — 各タスクが書き込むファイルパスを `tasks[].writes` に書く。空のままだと PO の衝突検出が効かず、並列実行で破壊的競合が起きうる
+8. **同一ファイルへの書き込み重複を避ける** — 複数タスクの `writes` で同じファイルが出てきたら、(a) タスクをまとめる、(b) 片方を `depends_on` で順序づけ、(c) `concurrency_group` で同時実行を 1 に制限、のいずれかで衝突を解消する
+
+### 出力直前の自己チェックリスト
+
+- [ ] `depends_on` チェーンの最大長 ≦ タスク数 / 2 か（直列化していないか）
+- [ ] `writes` が空のタスクが残っていないか
+- [ ] 同じファイルを書く複数タスクで衝突対策が取られているか
+- [ ] レビュータスク（read_only:true）が全 dev タスクに depends_on を持っているか
+- [ ] `tasks[].id` が一意で、`depends_on` の参照先が全て存在するか
+
+## Tools & Constraints
+制限:
+- ソースファイルの編集・書き込みは行わない
+- plan-report の YAML フロントマター内で `tasks[].id` の重複・未定義の `depends_on` 参照・エージェント名の typo を出力しない（`c3 po dry-run` で検証可能）
+- 上記「並列実行のための設計指針」のルール 1〜8 と自己チェックリストに違反した plan-report を出力しない
+
+## Related Agents
+- 上流: architect（architecture-report を受け取る）
+- 下流: developer・tester（plan-report を受け渡す）
+- 再起動元: code-reviewer・security-reviewer（指摘反映後に再計画）

claude_code_conductor-0.3.0/.claude/commands/develop.md

@@ -0,0 +1,11 @@
+# /develop コマンド
+
+plan-report に基づいて実装フェーズを実行する。
+
+## 必ず守ること
+
+1. **最初に必ず** `.claude/skills/dev-workflow.md` を Read する。記憶・推測で進めない
+2. **フェーズ D（実装）** から実行する
+3. dev-workflow.md の AskUserQuestion・Edit・セッションファイル更新の手順を省略しない
+4. D-0 で plan-report に YAML フロントマター（`po_plan_version`）が検出された場合は、続けて **必ず** `.claude/skills/wave-execution.md` を Read してその手順に従う（C3 メイン + PO スポット並列モード）
+5. フロントマターが無い場合は legacy の D-1〜D-5 ceremony（tester→developer→tester の TDD 逐次実行）にフォールバックする

{claude_code_conductor-0.2.3 → claude_code_conductor-0.3.0}/.claude/docs/parallel-orchestra-manifest.md

@@ -43,7 +43,9 @@ C3 では `plan-report` ファイルのフロントマターとして planner
 
 ---
 
-## フォーマット例
+## フォーマット例（推奨パターン）
+
+ファイル/モジュール境界で TDD タスクを並列化し、レビューを末尾に集約する形。3 つの dev タスクが PO で同時起動され、すべて完了してからレビューが走る。`writes` で衝突検出を効かせている。
 
 ```yaml
 ---
@@ -52,6 +54,8 @@ name: "ユーザー認証機能の並列実装"
 cwd: "../.."
 
 tasks:
+  # 1機能 = 1 TDD タスク。tdd-develop が内部で tester→developer→tester を
+  # 回すので、外側で「先にテスト」「次に実装」と分けない。
   - id: tdd-auth-login
     agent: tdd-develop
     read_only: false
@@ -62,6 +66,7 @@ tasks:
       - src/auth/login.py
       - tests/test_login.py
 
+  # 別ファイルなので login と並列実行可能。depends_on は付けない。
   - id: tdd-auth-logout
     agent: tdd-develop
     read_only: false
@@ -72,24 +77,92 @@ tasks:
       - src/auth/logout.py
       - tests/test_logout.py
 
+  # パスワードリセットも独立。3 つの dev タスクが並列で動く。
+  - id: tdd-auth-reset
+    agent: tdd-develop
+    read_only: false
+    prompt: |
+      パスワードリセット機能を TDD で実装してください。
+      plan-report: .claude/reports/plan-report-20260429-120000.md
+    writes:
+      - src/auth/reset.py
+      - tests/test_reset.py
+
+  # レビューは read_only:true、全 dev タスクに depends_on を付けて末尾集約。
   - id: review-auth
     agent: code-reviewer
     read_only: true
     prompt: "認証モジュール全体のコードレビューを行ってください。"
-    depends_on: [tdd-auth-login, tdd-auth-logout]
-    concurrency_group: api-calls
+    depends_on: [tdd-auth-login, tdd-auth-logout, tdd-auth-reset]
 
 defaults:
   max_retries: 1
 
-concurrency_limits:
-  api-calls: 2
-
 on_failure:
   webhook_url: "https://example.com/notify"
 ---
 ```
 
+実行イメージ:
+
+```
+時間→
+[tdd-auth-login    ]
+[tdd-auth-logout   ]   ← 3 つが同時に起動（max_workers=3 想定）
+[tdd-auth-reset    ]
+                      [review-auth]   ← 全完了後に走る
+```
+
+---
+
+## アンチパターン（避けるべき書き方）
+
+### A. 全部直列にしてしまう
+
+```yaml
+tasks:
+  - id: tdd-login
+    agent: tdd-develop
+    # ...
+  - id: tdd-logout
+    agent: tdd-develop
+    depends_on: [tdd-login]   # ❌ login と logout は別ファイル。依存ない
+    # ...
+  - id: tdd-reset
+    agent: tdd-develop
+    depends_on: [tdd-logout]  # ❌ 「前のタスクが終わってから」レベルの依存
+    # ...
+```
+
+→ `depends_on` チェーンの最大長 = タスク数 - 1。並列度 1 になり PO を使う意味なし。
+
+### B. TDD を「テスト → 実装」に分割する
+
+```yaml
+tasks:
+  - id: write-login-tests
+    agent: tester
+    # ...
+  - id: implement-login
+    agent: developer
+    depends_on: [write-login-tests]   # ❌ tdd-develop が内部でやる仕事を外で分割
+```
+
+→ tdd-develop が tester→developer→tester ループを内部で回すので、外で分けると Red-Green-Refactor サイクルが壊れる。**1 機能 = 1 TDD タスク**でまとめる。
+
+### C. writes が空・同じファイルが重複
+
+```yaml
+tasks:
+  - id: tdd-login
+    writes: []                # ❌ PO の衝突検出が効かない
+  - id: tdd-auth-helpers
+    writes:
+      - src/auth/login.py     # ❌ tdd-login と同じファイル → 競合
+```
+
+→ 必ず書き込みファイルを `writes` に列挙する。重複したらタスクをまとめるか `concurrency_group` で同時実行を制限する。
+
 ---
 
 ## C3 における配置場所

{claude_code_conductor-0.2.3 → claude_code_conductor-0.3.0}/.claude/skills/dev-workflow.md

@@ -217,39 +217,29 @@ AskUserQuestion ツール:
 
 ---
 
-## フェーズ D: TDD
+## フェーズ D: 実装
 
 **フェーズ C から続いている場合:** plan-report はコンテキスト内にあるため読み直し不要。
 **直接開始の場合:** Glob で `.claude/reports/plan-report-*.md` の最新を Read する。存在しない場合はフェーズ C から始めるよう案内して終了する。
 
+### D-0: 実行モード自動判別
+
+plan-report の冒頭を Read し、YAML フロントマター（`---` で始まり `po_plan_version: "0.1"` を含む）の有無を確認する。
+
+**フロントマターありの場合:**
+1. **最初に必ず** `.claude/skills/wave-execution.md` を Read する（記憶・推測で進めない）
+2. `wave-execution.md` の手順に完全に従って wave 単位で実装を進める
+3. 全 wave 完了後はフェーズ E（レビュー）へ進む（wave に reviewer タスクが含まれていれば E をスキップ可能と案内する）
+
+**フロントマターなしの場合（legacy フォールバック）:**
+
 今日のセッションファイルに以下を追記する（未登録の場合のみ）:
 - `- [ ] 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 へ進む。
 
 ### D-1: tester（Red フェーズ）
 

claude_code_conductor-0.3.0/.claude/skills/wave-execution.md

@@ -0,0 +1,220 @@
+# Wave Execution
+
+`/develop` のフェーズ D で plan-report に YAML フロントマター（`po_plan_version: "0.1"`）が含まれるときに Read される手順。
+
+C3 の親 Claude が plan-report の DAG を **wave 単位**で歩く。
+- 単独 wave（タスク 1 件） → C3 が直接実行（Agent ツール起動 or ペルソナ採用）
+- 複数 wave（タスク 2 件以上） → parallel-orchestra（PO）にスポット並列委譲
+
+各 wave 完了後にユーザーの承認を取る。
+
+---
+
+## 前提条件
+
+- `claude-code-conductor` がインストール済みで `c3` コマンドが PATH 上にあること
+- plan-report が `.claude/reports/plan-report-*.md` の形式で配置され、YAML フロントマターを持つこと（フロントマターが無ければ `dev-workflow.md` の D-1〜D-5 ceremony へフォールバック）
+
+---
+
+## Step 0: 妥当性チェック
+
+1. Glob で `.claude/reports/plan-report-*.md` の最新ファイルパスを取得する
+2. Read で内容（フロントマター含む）を確認する
+3. Bash で以下を実行する:
+
+   ```
+   c3 po dry-run <plan-report-path>
+   ```
+
+   - 終了コード `0` = マニフェスト妥当 → Step 1 へ
+   - 終了コード `2` = マニフェストエラー（フィールド欠損・agent 不在等）→ stderr のメッセージを整形してユーザーに提示し、`/start` のフェーズ C（計画）を再実行するか手動で plan-report を編集するよう案内してこのスキルを終了する
+   - 終了コード `1` = PO 未インストール → 以下の案内文を**そのまま提示**してこのスキルを終了する:
+
+     > 並列実行を使うには `pip install parallel-orchestra` を実行してください。
+     > 詳細: https://pypi.org/project/parallel-orchestra/
+
+     親 Claude は逐次実行（`dev-workflow.md` の D-1〜D-5）に切り替えるか、PO をインストールして `/develop` を再実行するかをユーザーに選んでもらう。
+
+---
+
+## Step 1: wave 分解
+
+Bash で以下を実行する:
+
+```
+c3 po waves <plan-report-path>
+```
+
+stdout の JSON は以下の形式になる:
+
+```json
+{
+  "waves": [
+    {
+      "index": 0,
+      "tasks": [
+        { "id": "tdd-login", "agent": "tdd-develop", "read_only": false, "writes": ["src/auth/login.py"], "prompt": "..." },
+        { "id": "tdd-logout", "agent": "tdd-develop", "read_only": false, "writes": ["src/auth/logout.py"], "prompt": "..." }
+      ]
+    },
+    {
+      "index": 1,
+      "tasks": [
+        { "id": "review-auth", "agent": "code-reviewer", "read_only": true, "writes": [], "prompt": "..." }
+      ]
+    }
+  ]
+}
+```
+
+- 終了コード `0` = 分解成功 → 親 Claude が JSON をパースして `waves` 配列を取得し Step 2 へ
+- 終了コード `2` = フロントマター不正・循環依存等 → stderr メッセージを提示して終了
+
+セッションファイル（`.claude/memory/sessions/YYYYMMDD.tmp`）に以下を追記する（未登録の場合のみ）:
+- 各 wave につき `- [ ] Wave {N} ({task_count} tasks)` を 1 行ずつ
+
+---
+
+## Step 2: wave ごとに実行する
+
+`waves` 配列を index 順にループする。各 wave で以下を順に行う。
+
+### 2-A: wave 内容を提示する
+
+親 Claude が wave のタスク一覧を Markdown 表で提示する:
+
+| id | agent | read_only | writes |
+|---|---|---|---|
+| tdd-login | tdd-develop | false | src/auth/login.py |
+| tdd-logout | tdd-develop | false | src/auth/logout.py |
+
+### 2-B: 実行可否をユーザーに確認する
+
+AskUserQuestion ツール:
+
+```json
+{
+  "questions": [{
+    "question": "Wave {N} を実行してよいですか？",
+    "options": [
+      { "label": "承認・進む", "description": "この wave を実行する" },
+      { "label": "中断", "description": "ここで wave 実行を停止する。完了済みの wave はそのまま残る" }
+    ]
+  }]
+}
+```
+
+「中断」の場合、セッションファイルの `## 試みたが失敗したアプローチ` に中断理由を追記してスキル終了。
+
+### 2-C: ランナーを選んで実行する
+
+`len(wave.tasks)` で分岐する。
+
+#### case A: 単独 wave（タスク 1 件）
+
+タスクの `agent` フィールドで更に分岐する。
+
+##### A-1: `agent == "tdd-develop"` のとき
+
+**ペルソナ採用パターン**で実行する。Agent ツールで起動するとサブエージェント depth 1 制限により内部の tester/developer サブエージェントが spawn できないため、親 Claude が直接 tdd-develop ペルソナで動く。
+
+1. `.claude/agents/tdd-develop.md` を Read してペルソナを採用する
+2. `.claude/skills/worktree-tdd-workflow.md` を Read して TDD ループ手順（tester→developer→tester）を取得する
+3. タスクの `prompt` を実装内容として、worktree-tdd-workflow.md の Step 1〜4 を **親 Claude が直接** 実行する。tester / developer は Agent ツールでスポーン可能（depth 1 で完結する）
+4. ループ完了後、結果を 2-D の集約に渡す
+
+##### A-2: `agent` がそれ以外（`code-reviewer` / `security-reviewer` / `developer` / `tester` 等）
+
+**Agent ツール起動パターン**で実行する。これらの agent は内部で更に subagent を spawn しないため depth 1 制限に抵触しない。
+
+1. Agent ツールで `subagent_type` は指定せず（カスタム agent は subagent_type 不可）、プロンプトに以下を含める:
+   - 「`.claude/agents/{agent_name}.md` を Read してペルソナを採用すること」
+   - タスクの `prompt` 本文
+2. Agent の返答を 2-D の集約に渡す
+
+##### 将来 agent を追加する場合
+
+「内部で更に subagent を呼ぶ agent」を新たに作る場合は、A-1 のペルソナ採用パターン側に追加する。判断基準: その agent の定義ファイルが「内部で Agent ツールを使う」前提になっているか。tdd-develop が現状の唯一の例。
+
+#### case B: 複数 wave（タスク 2 件以上）
+
+**PO スポット委譲**で実行する。
+
+Bash で以下を実行する:
+
+```
+c3 po run-wave <plan-report-path> --wave-index {N} --report .claude/reports/po-run-report-wave-{N}-{ts}.json
+```
+
+- `{N}` は wave の index
+- `{ts}` は `YYYYMMDD-HHMMSS` 形式。Bash で `python -c "from datetime import datetime; print(datetime.now().strftime('%Y%m%d-%H%M%S'))"` を実行して取得
+- `c3 po run-wave` は `.claude/tmp/po-manifest-wave-{N}-{ts}.md` に ephemeral マニフェストを生成し、PO に subprocess 委譲する。各タスクは PO が `claude -p --agent <name>` を独立 Claude セッション（depth 0）として起動するため、tdd-develop も内部で tester/developer を spawn できる
+
+終了コードと意味:
+
+| exit code | 意味 | 次のアクション |
+|---|---|---|
+| `0` | wave 内全タスク成功 | 2-D へ |
+| `1` | 1件以上のタスクが失敗 | 2-D へ（失敗一覧を含めて提示） |
+| `2` | マニフェストエラー（Step 0 をすり抜けた）| エラー内容を提示しスキル終了 |
+| `3` | runner エラー（claude バイナリ不在等）| `c3 doctor` の結果を提示してスキル終了 |
+
+実行完了後、生成された `po-run-report-wave-{N}-{ts}.json` を Read してタスクごとのステータスを取得する。
+
+### 2-D: 結果を集約してユーザーに提示する
+
+ランナー種別ごとに以下の形式で結果を提示する。
+
+**case A（単独 wave）:**
+- A-1: 親 Claude の TDD ループ結果（tester/developer の Agent 返答の要約、最終 tester の合否）
+- A-2: Agent の返答テキスト（必要なら要約）
+
+**case B（複数 wave / PO 委譲）:**
+- `po-run-report-wave-{N}-*.json` を Markdown 表に整形:
+
+  | id | agent | status | worktree | duration | last_error_summary |
+  |---|---|---|---|---|---|
+  | tdd-login | tdd-develop | success | wt-tdd-login | 124s | - |
+  | tdd-logout | tdd-develop | failure | wt-tdd-logout | 89s | TestLogout::test_csrf failed |
+
+### 2-E: 失敗があったら方針を確認する
+
+case A で TDD ループが不合格のまま終わった、または case B で 1 件以上失敗した場合、AskUserQuestion で次を確認する:
+
+```json
+{
+  "questions": [{
+    "question": "Wave {N} に失敗があります。どうしますか？",
+    "options": [
+      { "label": "リトライ", "description": "同じ wave をもう一度実行する" },
+      { "label": "スキップして次の wave へ", "description": "失敗を残したまま次の wave に進む" },
+      { "label": "中断", "description": "ここで wave 実行を停止する。完了済みの wave はそのまま残る" }
+    ]
+  }]
+}
+```
+
+- 「リトライ」 → 2-A から同じ wave を再実行
+- 「スキップして次の wave へ」 → 失敗内容をセッションファイルの `## 試みたが失敗したアプローチ` に追記して次の wave へ
+- 「中断」 → セッションファイルの該当 wave 行は `- [ ]` のままにしてスキル終了
+
+### 2-F: wave 完了をセッションに記録する
+
+全タスク成功した wave のみ、セッションファイルの `- [ ] Wave {N} (M tasks)` を `- [x] Wave {N} (M tasks)` に Edit する。
+
+---
+
+## Step 3: フェーズ E への遷移
+
+全 wave 完了後、フェーズ E（レビュー）への遷移を案内する。
+
+- plan-report に reviewer タスク（agent が `code-reviewer` / `security-reviewer`）が含まれている場合は wave で既に実行済みなので、二重レビューを避けるためにユーザーへ「wave 内で reviewer タスクが完了済みなので E をスキップしてもよい」と提示する
+- reviewer タスクが含まれていない場合は通常通りフェーズ E へ進む
+
+---
+
+## 知識蓄積
+
+- wave 実行で**特定パターンが詰まりがち**（例: tdd-develop の persona 起動で context が膨らみやすい）と気付いたら、セッションファイルの `## 試みたが失敗したアプローチ` に追記し `patterns` に登録する
+- wave 分解の精度（planner の出力品質）に関する観察も同様に記録する。これは将来 planner 側のルール改善に繋がる

{claude_code_conductor-0.2.3 → claude_code_conductor-0.3.0}/CHANGELOG.md

@@ -1,5 +1,70 @@
 # Changelog
 
+## [0.3.0] - 2026-04-30
+
+### Changed (breaking)
+- `/develop` now auto-detects YAML frontmatter on the latest plan-report and
+  switches between two modes:
+  - **frontmatter present** → new "C3 main + PO spot" workflow. C3 walks the
+    DAG wave-by-wave, asks for user approval before each wave, and dispatches
+    each wave to the right runner: solo waves run on the C3 host (Agent-tool
+    spawn for `code-reviewer` / `developer` / `tester`, parent-Claude persona
+    adoption for `tdd-develop` to avoid the depth-1 nested-spawn limit), and
+    multi-task waves are delegated to parallel-orchestra via an ephemeral
+    wave-only manifest under `.claude/tmp/`.
+  - **no frontmatter** → legacy D-1〜D-5 sequential TDD ceremony, unchanged.
+- The previous "PO 全委譲" model (D-0 two-choice prompt) and
+  `.claude/skills/parallel-execution.md` are removed. The new flow is
+  documented in `.claude/skills/wave-execution.md`.
+
+### Added
+- `c3 po waves <plan-report>` — prints the topological wave decomposition of
+  a manifest as JSON. Used by `wave-execution.md` to drive the per-wave loop.
+- `c3 po run-wave <plan-report> --wave-index N` — generates a wave-only
+  ephemeral manifest under `.claude/tmp/po-manifest-wave-{N}-{ts}.md` and
+  hands it to parallel-orchestra.
+- `c3.po.manifest.compute_waves(frontmatter)` — Kahn's-algorithm topological
+  wave decomposition. Detects cycles, unknown dependency ids, and duplicate
+  task ids.
+- `c3.po.manifest.build_wave_manifest_text(frontmatter, wave_index)` —
+  emits a parseable plan-report Markdown for one wave, dropping `depends_on`
+  and webhook fields and decorating the manifest name with ` - wave N`.
+- `tests/test_po_waves.py` (16 tests) and `tests/test_cli_po.py` (5 tests)
+  covering wave decomposition, ephemeral-manifest generation, CLI exit
+  codes, and frontmatter round-trip.
+
+### Notes
+- The persona-adoption pattern for `tdd-develop` in solo waves is the direct
+  consequence of Claude Code's depth-1 nested-spawn limit (a sub-agent
+  spawned via the Agent tool cannot itself spawn another sub-agent). For
+  agents that internally spawn sub-agents (today: `tdd-develop`), the parent
+  Claude reads the agent definition and adopts its persona instead. Other
+  agents (`code-reviewer`, `security-reviewer`, `developer`, `tester`) keep
+  using the standard Agent-tool spawn path.
+
+## [0.2.4] - 2026-05-01
+
+### Changed
+- `planner` agent now produces plan-reports designed for actual parallel
+  execution. Previously the agent only knew "emit YAML frontmatter"; without
+  rules for how to design the dependency graph it tended to write conservative
+  serial chains where every task depended on the previous one, defeating the
+  point of parallel-orchestra. Added a "並列実行のための設計指針" section
+  with eight concrete rules:
+  - depends_on only for true dependencies (not "just to be safe")
+  - serialization self-check: chain length ≦ tasks/2
+  - reviews go to the end via depends_on covering all dev tasks
+  - decompose at file/module boundaries, not function-level or module-level
+  - 1 TDD task = test + production + correction loop (do not split)
+  - default granularity: file / feature
+  - `writes` field is mandatory for collision detection
+  - duplicate writes must be merged, sequenced via depends_on, or grouped
+- `.claude/docs/parallel-orchestra-manifest.md`: example expanded to three
+  dev tasks + a depends-on-all reviewer (showing real parallelism), plus
+  inline comments and an "アンチパターン" section that calls out
+  serialized chains, splitting TDD into separate tester/developer tasks,
+  and empty/duplicate `writes` fields.
+
 ## [0.2.3] - 2026-05-01
 
 ### Added

{claude_code_conductor-0.2.3 → claude_code_conductor-0.3.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: claude-code-conductor
-Version: 0.2.3
+Version: 0.3.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

{claude_code_conductor-0.2.3 → claude_code_conductor-0.3.0}/src/c3/__init__.py

@@ -1,3 +1,3 @@
 """Claude Code Conductor (C3) - multi-agent orchestration framework for Claude Code."""
 
-__version__ = "0.2.3"
+__version__ = "0.3.0"