claude-code-conductor 2.33.0__tar.gz → 2.35.0__tar.gz

claude_code_conductor-2.35.0/.claude/agents/design-critic.md

@@ -0,0 +1,63 @@
+---
+name: design-critic
+model: opus
+memory: project
+permissionMode: bypassPermissions
+description: 設計・計画監査担当。requirements/architecture/plan を敵対的に監査し design-review-report を出力する。ソース編集不可。
+tools:
+  - Read
+  - Write
+  - Glob
+  - Grep
+  - Skill
+---
+
+# Design Critic
+
+## Core Mandate
+要件・設計・計画レポートを第三者として敵対的に監査し、実装前に手戻りを引き起こす前提崩れ・曖昧さ・抜け漏れを検出して design-review-report として出力する。
+
+## Key Scope
+
+✅ 担当すること:
+- requirements-report / architecture-report / plan-report の監査
+- 3 レンズ（前提発掘 / 曖昧さ / 抜け漏れ）による finding 抽出
+- 各 finding への重要度・起因層・該当箇所の付与
+- design-review-report の出力
+
+❌ 担当しないこと:
+- ソースコードの編集・修正（read-only 第三者監査）
+- コード品質レビュー（code-reviewer の担当）
+- セキュリティ脆弱性診断（security-reviewer の担当）
+- 実装方針の決定・設計変更の代行
+
+## Workflow
+
+**Before:**
+- `.claude/skills/dev-workflow/references/design-critic-rubric.md` を Read して 3 レンズと finding 形式を確認する
+- Glob で以下の各最新ファイルを取得し Read する:
+  - `.claude/reports/requirements-report-*.md`（最新 1 件）
+  - `.claude/reports/architecture-report-*.md`（最新 1 件）
+  - `.claude/reports/plan-report-*.md`（最新 1 件）
+
+**During:**
+- ルーブリックの 3 レンズ（前提発掘 `[DC-AS-NNN]` / 曖昧さ `[DC-AM-NNN]` / 抜け漏れ `[DC-GP-NNN]`）を順に適用する
+- この段階の役割は**網羅（coverage）であり取捨選択ではない**。確信度が低い finding・Low 重要度の finding も握り潰さず report する。重要度による最終的な絞り込みは下流（ユーザー承認・層別ルーティング）に委ねる
+- 各 finding に必須付与する項目（詳細は `design-critic-rubric.md` の「Finding 必須項目」セクションを参照）:
+  - **重要度**: High（このまま実装すれば確実に手戻り）/ Medium（解釈次第で手戻り）/ Low（改善余地）
+  - **起因層**: `A要件` / `B設計` / `C計画`（層別ルーティングの判定キー）
+  - **該当箇所**: どのレポートのどのセクションか
+  - **問題点**: 何が問題か・なぜリスクか
+  - **実装前に確認・修正すべきこと**: 解消するために必要なアクション
+- findings が出なかった場合は「findings なし」として明記し、その旨 report に記載する
+
+**After:**
+- Skill ツールで `report-timestamp` を呼び出してタイムスタンプを取得し、Write ツールで `.claude/reports/design-review-report-{timestamp}.md` に出力する
+
+## Tools & Constraints
+制限: design-review-report の新規 Write 以外のファイル編集・書き込みは行わない（ソースファイル・既存レポート・その他ファイルへの Edit / Write は禁止）
+
+## Related Agents
+- 上流: planner（plan-report を受け取る）
+- ピア: code-reviewer / security-reviewer（同じ監査型エージェント。design-critic はフェーズ C-3 で設計監査、code-reviewer / security-reviewer はフェーズ E でコード・セキュリティ監査を独立稼働）
+- 下流: 親 Claude（C-3 ゲート: findings の承認フロー・層別ルーティングを担う）→ 起因層に応じて interviewer / architect / planner へルーティング

{claude_code_conductor-2.33.0 → claude_code_conductor-2.35.0}/.claude/skills/dev-workflow/SKILL.md

@@ -167,7 +167,7 @@ plan-report の全タスクを走査し、以下の形式でテキスト出力
 }
 ```
 
-承認後 → セッションファイルの `- [ ] 計画` を `- [x] 計画` に Edit して**フェーズ D** へ。
+承認後 → セッションファイルの `- [ ] 計画` を `- [x] 計画` に Edit して**C-3（計画監査ゲート）** へ。
 
 **知識蓄積:**
 - 「否認・修正を依頼する」: `## 試みたが失敗したアプローチ` に教訓をルール形式で追記し `patterns` に追加する
@@ -175,6 +175,133 @@ plan-report の全タスクを走査し、以下の形式でテキスト出力
 
 ---
 
+### C-3: 計画監査ゲート（opt-in）
+
+**セッションファイル運用:** C-3 は C-2 で `計画 [x]` 化が完了した後の独立ゲートである。セッションファイルへの新規 `- [ ]` フェーズ行の追加は不要。
+
+**ステップ 1: opt-in の確認（AskUserQuestion 単独ターン）**
+
+AskUserQuestion で確認する（このブロックに Agent 起動などの副作用ツールを混在させない）:
+
+```json
+{
+  "questions": [{
+    "question": "実装前に設計・計画を design-critic で監査しますか？",
+    "options": [
+      { "label": "監査する", "description": "前提・曖昧さ・抜け漏れを敵対的にチェック（手戻りが多そう/重要な変更で推奨）" },
+      { "label": "スキップ", "description": "小さい・自明な変更。そのまま実装へ" }
+    ]
+  }]
+}
+```
+
+「スキップ」→ そのまま**フェーズ D** へ（ノーオペ）。
+「監査する」→ ステップ 2 へ（別ターンで実行）。
+
+**ステップ 2: design-critic の起動（AskUserQuestion と別ターン）**
+
+Agent ツールで `design-critic` を起動する。
+
+- `subagent_type: "design-critic"`（固有名を明示。`'claude'` や省略は禁止）
+- `isolation: worktree` は使わない（read-only・並列なし）
+- プロンプトには以下の起動指示のみを含める（レポートの内容は agent 側で Glob・Read させる [SR-AI-001]）:
+  - 「`design-critic-rubric.md` を Read し、requirements / architecture / plan の各最新レポートを Glob で取得して 3 レンズで監査せよ」
+
+design-critic は `.claude/reports/design-review-report-YYYYMMDD-HHMMSS.md` を Write して終了する。
+
+完了後 → ステップ 3 へ。
+
+**ステップ 3: findings の分岐**
+
+design-review-report を Read して findings の有無を確認する。design-critic の起動失敗・中断によりレポートが存在しない場合は、AskUserQuestion でユーザーに「再実行する」か「スキップしてフェーズ D へ進む」かを確認する。
+
+**findings なし（report に「findings なし」と記載されている場合）:**
+そのまま**フェーズ D** へ。
+
+**findings あり:**
+指摘一覧をテキストで提示してから AskUserQuestion で方針を確認する（このブロックに副作用ツールを混在させない）:
+
+```json
+{
+  "questions": [{
+    "question": "design-review-report に指摘があります。対応方針を選択してください。",
+    "options": [
+      { "label": "全て対応する", "description": "全指摘に [対応予定] を付けて起因層へ戻す" },
+      { "label": "対応する指摘を選ぶ", "description": "指摘ごとに対応/許容を決める" },
+      { "label": "全て許容して進む", "description": "全指摘を許容してフェーズ D へ" },
+      { "label": "否認・再監査を依頼する", "description": "フィードバックして design-critic を再実行" }
+    ]
+  }]
+}
+```
+
+**「全て対応する」の場合:**
+全指摘に `> **[対応予定]**` をマークしてから層別ルーティング（ステップ 4）へ。
+
+**「対応する指摘を選ぶ」の場合:**
+続けて AskUserQuestion で確認する（別ターン）:
+```json
+{
+  "questions": [{
+    "question": "どの指摘を対応しますか？対応する指摘 ID（例: DC-AS-001）と、許容する指摘の理由を教えてください。"
+  }]
+}
+```
+1. 対応する指摘に `> **[対応予定]**` を Edit で追記する
+2. 許容する指摘の直下に `> **[許容]** {理由}` を Edit で追記する（検出記録は削除しない）
+3. `[対応予定]` を付けた finding が 1 件以上あれば層別ルーティング（ステップ 4）へ。全て許容した場合はフェーズ D へ。
+
+**「全て許容して進む」の場合:**
+続けて AskUserQuestion で許容理由を確認する（別ターン）:
+```json
+{
+  "questions": [{
+    "question": "全指摘を許容する理由を教えてください。"
+  }]
+}
+```
+全指摘の直下に `> **[許容]** {理由}` を Edit で追記してから**フェーズ D** へ。
+
+**「否認・再監査を依頼する」の場合:**
+続けて AskUserQuestion でフィードバックを確認してからステップ 2（design-critic 再起動）へ。
+
+**ステップ 4: 層別ルーティング**
+
+（ステップ 3 で「全て対応する」または「対応する指摘を選ぶ」を選び、`[対応予定]` が 1 件以上ある場合のみこのステップへ到達する）
+
+`[対応予定]` を付けた finding の起因層（`A要件` / `B設計` / `C計画`）を集計し、最も上流の層へ戻る（上流順: **A要件 < B設計 < C計画**）。戻り先はピンポイント修正（`[対応予定]` の finding のみ対象。フルやり直しはしない）。**最上流の判定は `[対応予定]` を付けた finding だけで行う（`[許容]` にした finding の起因層は戻り先に影響しない）。**
+
+| `[対応予定]` finding の最上流起因 | 戻り先 | 修正する担当 | その後の連鎖 |
+|---|---|---|---|
+| A要件 を含む | フェーズ A | interviewer（該当点のみ追加確認） | A → B → C → C-3 |
+| B設計 が最上流 | フェーズ B | architect（該当設計のみ修正） | B → C → C-3 |
+| C計画 のみ | フェーズ C | planner（該当タスクのみ修正） | C → C-3 |
+
+上流フェーズ修正後は下流へ自然に連鎖する（例: B 修正 → C 再計画 → C-2 再承認 → C-3）。各フェーズでも該当 `[対応予定]` の finding のみを反映する。
+
+連鎖が C-2 を経て C-3 に戻ったら → ステップ 5（再監査の選択）へ。
+
+**ステップ 5: 修正後の再監査（選択式・無限ループ防止）**
+
+上流修正の連鎖を経て C-3 に戻ってきた場合、毎回自動再走はしない。AskUserQuestion で再監査の要否を確認する（このブロックに副作用ツールを混在させない）:
+
+```json
+{
+  "questions": [{
+    "question": "修正が入りました。design-critic で再監査しますか？",
+    "options": [
+      { "label": "再監査する", "description": "更新後のレポート群を再度チェック（重要案件）" },
+      { "label": "再監査せず実装へ", "description": "フェーズ D へ進む" }
+    ]
+  }]
+}
+```
+
+「再監査する」→ ステップ 2（design-critic 起動）へ（別ターンで実行）。
+「再監査せず実装へ」→ **フェーズ D** へ。
+
+---
+
 ## フェーズ D: 実装
 
 **フェーズ C から続いている場合:** plan-report はコンテキスト内にあるため読み直し不要。

claude_code_conductor-2.35.0/.claude/skills/dev-workflow/references/design-critic-rubric.md

@@ -0,0 +1,160 @@
+# Design Critic Rubric（設計監査・ルーブリック）
+
+`dev-workflow` フェーズ C-3（計画監査ゲート）で design-critic が参照する**3 レンズ監査指針**。
+design-critic サブエージェントが requirements-report / architecture-report / plan-report を読み込んだ後、
+本ファイルを Read して**3 レンズを順に適用し、finding を抽出する**。フェーズ C-3 専用。
+
+設計思想: **レンズカテゴリ＝固定**（何を探すか予測可能）／
+**finding 文面＝動的**（レポート内容からその場で生成する）。
+
+---
+
+## Finding ID 体系
+
+| レンズ | finding ID プレフィックス | 探索内容 |
+|---|---|---|
+| 前提発掘 | `[DC-AS-NNN]` | 暗黙の前提を列挙し、裏付け検証を行う |
+| 曖昧さ | `[DC-AM-NNN]` | 複数の解釈が成り立つ記述を特定する |
+| 抜け漏れ | `[DC-GP-NNN]` | 要件↔設計↔計画のトレーサビリティ欠落を検出する |
+
+NNN は 3 桁の連番（001 から始める）。レンズ内で独立してカウントする（DC-AS-001, DC-AM-001 は別物）。
+
+---
+
+## Finding 必須項目
+
+各 finding に以下の 5 項目を必ず付与する:
+
+| 項目 | 値の例 | 説明 |
+|---|---|---|
+| **重要度** | High / Medium / Low | High = このまま実装すれば確実に手戻り（前提崩れ・タスク欠落）。Medium = 解釈次第で手戻り。Low = 改善余地 |
+| **起因層** | A要件 / B設計 / C計画 | 問題の根本が発生している層。層別ルーティングの判定キー（上流順: A < B < C） |
+| **該当箇所** | 例: `architecture-report §2.3` | どのレポートのどのセクションか |
+| **問題点** | 自然文で記述 | 何が問題か・なぜリスクか |
+| **実装前に確認・修正すべきこと** | 自然文で記述 | 解消するために必要なアクション |
+
+---
+
+## レンズ 1: 前提発掘 `[DC-AS-NNN]`
+
+**目的**: 設計・計画に暗黙で埋め込まれている前提を列挙し、各前提が要件/設計/既存コードで裏付けられているかを検証する。裏付けのない前提は実装フェーズで崩れる潜在リスク。
+
+### 着眼点
+
+- **インフラ・環境前提**: 特定の OS / Python バージョン / ライブラリバージョン / 外部サービスの可用性を「当然ある」として扱っていないか。requirements-report / architecture-report に記載があるか確認する
+- **データ前提**: スキーマ形式・入力値の範囲・null 可否・文字コード・言語など、暗黙に制限されている前提が requirements で確定しているか
+- **利用者行動前提**: ユーザーが特定の順序で操作する・特定の権限を持つ・特定の知識を持つ、などの前提が要件に根拠を持つか
+- **外部連携前提**: 外部 API / サービスのインターフェース・レスポンス形式・可用性 SLA が設計に明記されているか
+- **後方互換前提**: 既存機能・データ・設定が「壊れない」前提で計画が組まれている場合、その保証が設計に盛り込まれているか
+
+### 判定基準
+
+- 前提が requirements-report または architecture-report に明記されている → 裏付けあり（finding 不要）
+- 前提が既存コードの実装から確認できる → 裏付けあり（finding 不要）
+- 前提が上記いずれにも根拠なく置かれている → finding として記録（重要度は影響範囲で判定）
+
+---
+
+## レンズ 2: 曖昧さ `[DC-AM-NNN]`
+
+**目的**: 実装者が解釈で割れる記述を特定する。複数の妥当な解釈が成り立つ要件・設計は、実装者ごとに異なる実装を生み出し、レビュー時・統合時に手戻りを引き起こす。
+
+### 着眼点
+
+- **主語の曖昧さ**: 「ユーザーは〜できる」の「ユーザー」が誰か（役割・権限レベル）が特定できるか
+- **「最新」「直近」の曖昧さ**: 「最新の〇〇」「直近 N 件」の定義が未確定で実装者が独自に定めるしかない状態
+- **「適切に」「必要に応じて」「柔軟に」**: 動作の条件や基準が自然言語で曖昧に記述され、具体的な判定ロジックが読み取れない
+- **OR / AND の曖昧さ**: 条件列挙が「AまたはB」「AかつB」か判別できない記述
+- **エラー処理の曖昧さ**: 「失敗時はエラーを返す」だけでどのエラー型か・ロールバック範囲か・リトライ要否かが不明
+- **単数 / 複数の曖昧さ**: 「1 件」「複数件」の制約が明示されていないため、実装者が任意に決める状態
+
+### 判定基準
+
+- 1 つの記述に対して「A のようにも読める・B のようにも読める」が複数成立する → finding として記録
+- 文脈全体で意味が一意に定まる場合は finding 不要
+
+---
+
+## レンズ 3: 抜け漏れ `[DC-GP-NNN]`
+
+**目的**: 要件↔設計↔計画のトレーサビリティ欠落を検出する。要件に記載があるが設計に落ちていない・設計に落ちているが計画タスクに無い、というギャップが実装漏れの直接原因になる。
+
+### 着眼点
+
+- **要件 → 設計の欠落**: requirements-report に記載された機能・非機能要件が architecture-report で設計されていない
+- **設計 → 計画の欠落**: architecture-report の設計判断・コンポーネントが plan-report のタスクに反映されていない
+- **エラーパスの欠落**: 正常系は設計・計画されているが、異常系（バリデーション失敗・タイムアウト・権限不足等）がどちらかに存在しない
+- **境界値・エッジケースの欠落**: 入力の空/null/最大値/最小値・ゼロ件ケースが要件・設計に明示されているか
+- **非機能要件の欠落**: パフォーマンス・可用性・セキュリティ・ログ・監査証跡などが要件に上がっているが設計/計画に反映されていない
+- **削除・クリーンアップの欠落**: 作成タスクはあるが削除・クリーンアップ・後始末タスクが計画にない
+- **テスト・検証の欠落**: 計画タスクに実装タスクはあるが、対応するテスト・検証タスクが存在しない
+
+### 判定基準
+
+- 要件・設計・計画を突き合わせ、上位層に記載があり下位層に対応物がない → finding として記録
+- 対応物が別の記述・タスク名で含意されている場合は finding 不要
+
+---
+
+## design-review-report 出力形式
+
+`code-review-report` と同型。ファイル名: `.claude/reports/design-review-report-YYYYMMDD-HHMMSS.md`
+
+**Findings の並び順**: レンズ単位（DC-AS → DC-AM → DC-GP の順）で列挙する。同一レンズ内では重要度降順（High → Medium → Low）で並べる。
+
+```
+---
+generated: YYYY-MM-DD HH:MM:SS
+agent: design-critic
+inputs:
+  - requirements-report-YYYYMMDD-HHMMSS.md
+  - architecture-report-YYYYMMDD-HHMMSS.md
+  - plan-report-YYYYMMDD-HHMMSS.md
+---
+
+# Design Review Report
+
+**生成日時:** YYYY-MM-DD HH:MM:SS
+**担当:** design-critic
+**入力:** requirements-report-〇〇 / architecture-report-〇〇 / plan-report-〇〇
+
+---
+
+## サマリ
+
+| 重要度 | 件数 |
+|---|---|
+| High   | N |
+| Medium | N |
+| Low    | N |
+| 合計   | N |
+
+findings なしの場合は「findings なし — 実装フェーズへ進めます」とのみ記載する。
+
+---
+
+## Findings
+
+### [DC-AS-001]（High・起因: B設計）
+- 該当: architecture-report §2.3
+- 問題: 〜という前提が置かれているが、requirements-report に裏付けがない
+- 実装前に確認すべきこと: 〜
+
+### [DC-AM-001]（Medium・起因: A要件）
+- 該当: requirements-report §1.2
+- 問題: 〜の記述は「〜とも読める / 〜とも読める」で解釈が割れる
+- 実装前に確認すべきこと: 〜
+
+### [DC-GP-001]（High・起因: C計画）
+- 該当: plan-report タスク一覧
+- 問題: architecture-report §2.1 で設計された〜コンポーネントに対応するタスクが plan-report にない
+- 実装前に確認すべきこと: 〜
+```
+
+---
+
+## 予測可能性の担保
+
+**探索するレンズカテゴリは固定**（前提発掘 / 曖昧さ / 抜け漏れ）・**finding 文面だけ動的**。
+監査のたびに同じ 3 レンズで探索するため、「何がチェックされるか」が予測可能であり、
+設計者・計画者が事前に潰しやすい。

{claude_code_conductor-2.33.0 → claude_code_conductor-2.35.0}/.claude/skills/parallel-agents/SKILL.md

@@ -216,6 +216,19 @@ worktree path は Agent ツール返り値の `<worktree><worktreePath>...</work
 
 全タスク成功した wave に対して以下を順に実行する。
 
+#### 2-F-0: 親 cwd をプロジェクトルートへ復帰（無条件・必須）
+
+worktree Agent 完了後、Claude Code の既知バグ（[Issue #28017](https://github.com/anthropics/claude-code/issues/28017) "Task tool with isolation=worktree leaks CWD to parent session"・closed as duplicate）により、**親 Claude の Bash cwd が `.claude/worktrees/agent-*` 内へ移動したまま戻らない**ことがある（発生はバージョン・環境・タイミング依存）。この状態だと 2-F-1〜2-F-3 の取り込み・コミット・削除が worktree 内で走って正しく行われない（Issue でも "Subsequent Bash commands run in the wrong directory" と報告）。とくに cwd が worktree 内のままだと worktree ディレクトリの削除に失敗しやすい（OS によっては cwd 配下を削除できない）。
+
+これを防ぐため、**2-F の最初に無条件でプロジェクトルートへ戻す**:
+
+```bash
+cd <ROOT>
+```
+
+- `<ROOT>` = プロジェクトルートの絶対パス。最初の worktree Agent を起動する前（cwd がまだルート）の `pwd` の値で、セッション開始時の作業ディレクトリと同じ。worktree 内から `git rev-parse --show-toplevel` を打つと worktree のルートが返るため、ルート判定には使わず **事前に控えた絶対パス** を使う。
+- cwd が漏れていなくても `cd <ROOT>` は無害。判定せず毎 wave 無条件で実行する（Issue が挙げる公式ワークアラウンド "manually cd back" に準拠）。`cd` は C3 の pre_tool hook の検査対象外のためブロックされない。
+
 #### 2-F-1: 成果物の取り込み
 
 各 worktree の `writes` ファイルを main に取り込む。**親 Claude が一括で行う**:

{claude_code_conductor-2.33.0 → claude_code_conductor-2.35.0}/.claude/skills/start/SKILL.md

@@ -52,7 +52,7 @@ AskUserQuestion で対象フェーズを確認する:
       { "label": "要件定義", "description": "requirements-report-*.md" },
       { "label": "設計", "description": "architecture-report-*.md" },
       { "label": "計画", "description": "plan-report-*.md" },
-      { "label": "レビュー", "description": "code-review-report-*.md / security-review-report-*.md" }
+      { "label": "レビュー", "description": "code-review-report-*.md / security-review-report-*.md / design-review-report-*.md" }
     ],
     "multiSelect": true
   }]
@@ -63,7 +63,7 @@ AskUserQuestion で対象フェーズを確認する:
 - 要件定義: `mkdir -p .claude/reports/archive && mv .claude/reports/requirements-report-*.md .claude/reports/archive/ 2>/dev/null || true`
 - 設計: `mkdir -p .claude/reports/archive && mv .claude/reports/architecture-report-*.md .claude/reports/archive/ 2>/dev/null || true`
 - 計画: `mkdir -p .claude/reports/archive && mv .claude/reports/plan-report-*.md .claude/reports/archive/ 2>/dev/null || true`
-- レビュー: `mkdir -p .claude/reports/archive && mv .claude/reports/code-review-report-*.md .claude/reports/archive/ 2>/dev/null || true && mv .claude/reports/security-review-report-*.md .claude/reports/archive/ 2>/dev/null || true`
+- レビュー: `mkdir -p .claude/reports/archive && mv .claude/reports/code-review-report-*.md .claude/reports/archive/ 2>/dev/null || true && mv .claude/reports/security-review-report-*.md .claude/reports/archive/ 2>/dev/null || true && mv .claude/reports/design-review-report-*.md .claude/reports/archive/ 2>/dev/null || true`
 
 ---
 

{claude_code_conductor-2.33.0 → claude_code_conductor-2.35.0}/CHANGELOG.md

@@ -1,5 +1,42 @@
 # Changelog
 
+## [2.35.0] - 2026-06-10
+
+**並列実行 worktree の cwd リーク（Claude Code [Issue #28017](https://github.com/anthropics/claude-code/issues/28017)）への暫定ワークアラウンドを追加（手順追加・破壊的変更なし）**: `isolation: "worktree"` の Agent 完了後に親セッションの作業ディレクトリ（cwd）が worktree（`.claude/worktrees/agent-*`）内へ移動したまま戻らない Claude Code の既知バグ（「Task tool with isolation=worktree leaks CWD to parent session」・closed as duplicate・複数 OS で報告）により、wave 完了処理（成果物の取り込み・コミット・worktree 削除）が誤ったディレクトリで走り、特に worktree ディレクトリの削除に失敗する事象がある。公式修正までの暫定対応として、`parallel-agents` skill の wave 完了処理の先頭で **無条件に cwd をプロジェクトルートへ戻す手順 `2-F-0`** を追加した。
+
+### 追加
+
+- **`.claude/skills/parallel-agents/SKILL.md` 2-F-0（親 cwd をプロジェクトルートへ復帰・無条件・必須）**: 各 wave の完了処理（2-F）の最初で `cd <ROOT>`（`<ROOT>` = 最初の worktree Agent 起動前の cwd の絶対パス）を無条件で実行する。cwd が漏れていなくても無害。Issue が挙げる公式ワークアラウンド "manually cd back" に準拠。これにより後続の 2-F-1（取り込み）・2-F-2（コミット）・2-F-3（削除）が常にプロジェクトルートで実行され、worktree 削除失敗を回避する。
+
+### 後方互換
+
+- 手順を 1 ステップ追加しただけで、wave の成果物・コミット内容・削除結果は変わらない。公開 API・CLI・DB スキーマ・hook・コード挙動に変更なし。**破壊的変更なし**・migration 不要。
+- 既存の 2-F-3（worktree クリーンアップ）はフォールバック型の手順を温存。本対応は公式修正までの暫定ワークアラウンドであり、ワークアラウンドが効かない場合も従来どおり残留チェック＋手動削除で吸収できる。
+
+### 注意
+
+- 本変更は `parallel-agents` skill（`/develop` のフェーズ D で間接起動）の手順追記。`c3 update` 適用後、次回の並列実装 wave から新手順が読まれる（新規 agent 定義の追加ではないためセッション再起動は不要）。
+
+## [2.34.0] - 2026-06-09
+
+**設計・計画監査ゲート `design-critic` を追加（機能追加・opt-in・破壊的変更なし）**: 標準ワークフローのフェーズ C（計画）とフェーズ D（実装）の間に、実装前の設計・計画を第三者として敵対的に監査する opt-in ゲート **C-3** を新設した。ブログ記事「Automated Doubt Development Process」に着想を得た「自動化された疑念」を C3 に取り込み、**実装中に発覚していた手戻り（前提崩れ・曖昧さ・抜け漏れ）を実装前に検出**することを狙う。新規 read-only サブエージェント `design-critic` が requirements/architecture/plan を 3 レンズ（前提発掘 `[DC-AS]` / 曖昧さ `[DC-AM]` / 抜け漏れ `[DC-GP]`）で監査し、各 finding に**起因層（A要件 < B設計 < C計画）**を付与する。findings は起因層に応じて正しい上流フェーズへ戻す**層別ルーティング**で対応する（設計起因を計画フェーズに戻しても直らない問題を回避）。
+
+### 追加
+
+- **`.claude/agents/design-critic.md`（新規・配布 agent）**: 設計・計画監査担当の read-only 第三者サブエージェント（code-reviewer と同型・ソース編集不可・`design-review-report` のみ Write）。`memory: project` / `permissionMode: bypassPermissions` 付き。
+- **`.claude/skills/dev-workflow/references/design-critic-rubric.md`（新規・配布 rubric）**: 3 レンズの着眼点・finding 必須項目（重要度／起因層／該当箇所／問題点／実装前に確認すべきこと）・`design-review-report` 出力形式を定義。
+- **`.claude/skills/dev-workflow/SKILL.md` フェーズ C-3（計画監査ゲート）**: opt-in（監査する/スキップ）→ design-critic 起動 → findings 承認フロー（フェーズ E と同型）→ 層別ルーティング（`[対応予定]` finding の最上流起因へピンポイント戻し）→ 修正後の再監査（選択式・無限ループ防止）。スキップ時はノーオペでフェーズ D へ。
+- **`.claude/skills/start/SKILL.md` Step 0**: アーカイブ対象（レビュー分類）に `design-review-report-*.md` を追加。
+
+### 後方互換
+
+- フェーズ C-3 は独立 opt-in ゲートとして追記。スキップ時は従来の C→D 遷移と同一でノーオペのため、**既存ワークフローに影響なし**。公開 API・CLI・DB スキーマ・hook・コード挙動に変更なし。**破壊的変更なし**・migration 不要。
+
+### 注意（有効化にセッション再起動が必要）
+
+- `design-critic` は新規サブエージェント定義のため、`c3 update` でファイルが追加された**直後のセッションでは agent レジストリに登録されず起動できない**（Claude Code はセッション開始時に agent 定義をロードする）。**次回セッションから利用可能**になる。フェーズ C-3 を通る際、当該セッションで agent が見つからない場合はセッションを再起動すること。
+- プラットフォームアダプター（Codex/Cursor/OpenCode）への design-critic 反映は本リリースのスコープ外（Claude Code のみ）。`c3 init --platform opencode` 等では `.claude/agents/design-critic.md` が自動で subagent として生成されるが、ワークフロー組み込み（C-3）は Claude Code 専用。
+
 ## [2.33.0] - 2026-06-08
 
 **配布 `CLAUDE.md` の「C3 Managed」セクション撤去とドキュメント同期（挙動不変・破壊的変更・migration なし）**: `.claude/CLAUDE.md` 末尾の `## C3 Managed` セクション（`@rules/promoted/index.md` の `@import` ＋「手動編集しないこと」コメント）を撤去した。Claude Code 公式仕様で `.claude/rules/` はサブディレクトリ含め**再帰的に自動ロード**される（`paths:` 無しは `CLAUDE.md` と同等優先度で全文ロード）ため、`rules/promoted/` は `@import` が無くても context に載る。include は冗長で、かつ「ファイル全体が `c3 update` で上書きされる配布物」なのに 1 セクションだけ「手動編集禁止」と書くのは誤解を招くため撤去した。v2.1.168 実機 `/context` で「`@import` 無しでも昇格ルール（個別ファイル＋`index.md`）が自動ロードされる」ことを検証済み。

{claude_code_conductor-2.33.0 → claude_code_conductor-2.35.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: claude-code-conductor
-Version: 2.33.0
+Version: 2.35.0
 Summary: Multi-agent orchestration framework for Claude Code with Codex/Cursor adapters (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-2.33.0 → claude_code_conductor-2.35.0}/src/c3/__init__.py

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