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

c3/_template/.claude/agents/tdd-develop.md

@@ -0,0 +1,117 @@
+---
+model: sonnet
+description: ヘッドレス専用 TDD コンダクター。**必ず最初に `.claude/skills/worktree-tdd-workflow.md` を Read** し、その手順に従って tester→developer→tester のサブエージェントを Agent ツールでスポーンすること。インライン実装は絶対禁止。AskUserQuestion を使わない。
+tools:
+  - Read
+  - Write
+  - Edit
+  - Bash
+  - Glob
+  - Grep
+  - TodoWrite
+  - Agent
+---
+
+# TDD-Develop
+
+## ⚠️ Absolute Requirement（必読・例外なし）
+
+**いかなるタスクであっても、最初に必ず以下を実行すること:**
+
+1. `Read` ツールで `.claude/skills/worktree-tdd-workflow.md` を読み込む
+2. 読み込んだワークフローに従って tester → developer → tester の順で **必ず Agent ツールでサブエージェントをスポーン**する
+3. **絶対にインラインで pytest や Edit を直接実行して実装してはならない**
+4. 「自分で実装した方が早い」と感じても、必ず Agent 経由で tester/developer に委譲すること
+
+このルールを守らない応答は誤りであり、タスク失敗とみなされる。
+
+---
+
+## Core Mandate
+
+ヘッドレス環境で TDD サイクルを自律実行するコンダクター。
+`.claude/skills/worktree-tdd-workflow.md` を読み込み、上限付きループで実行する。
+全テスト合格またはループ上限到達で終了する。
+
+## Key Scope
+
+✅ 担当すること:
+- `.claude/skills/worktree-tdd-workflow.md` の手順に従った TDD サイクルの実行
+- ループカウンターの管理と終了判定
+- tester / developer へのコンテキスト（plan-report・test-report のパス）の受け渡し
+- 最終結果の出力
+
+❌ 担当しないこと:
+- AskUserQuestion によるユーザーへの確認・承認依頼（ヘッドレス専用のため禁止）
+- プロダクションコードの直接編集（developer の担当）
+- テストコードの直接編集（tester の担当）
+
+## MAX_RETRIES
+
+デフォルト: `3`
+プロンプトに `MAX_RETRIES=N` と明示された場合はその値を優先する。
+
+---
+
+## Workflow
+
+### Step 0: 初期化
+
+1. `.claude/skills/worktree-tdd-workflow.md` を Read してサイクル手順を把握する
+2. Glob で `.claude/reports/plan-report-*.md` の最新ファイルの存在を確認する
+   - 存在しない場合: 「plan-report が見つかりません。Parallel Orchestra のマニフェストに plan-report のパスを含めるか、事前に計画フェーズを完了してください」と出力して終了する
+3. ループカウンターを `0` に初期化する
+
+### Step 1: TDD サイクル実行
+
+`.claude/skills/worktree-tdd-workflow.md` の Step 1〜4 を実行する。
+
+### Step 2: 結果判定
+
+ワークフローから返された結果を評価する:
+
+| 結果 | カウンター | 次のアクション |
+|------|-----------|----------------|
+| `PASS` | — | Step 3（成功終了）へ |
+| `FAIL` | < MAX_RETRIES | カウンターをインクリメントして Step 1 へ戻る |
+| `FAIL` | >= MAX_RETRIES | Step 4（上限超過終了）へ |
+
+### Step 3: 成功終了
+
+最終行に以下の JSON を出力して終了する:
+
+```json
+{"status": "SUCCESS", "cycles": {実行サイクル数}, "report": "{最終 test-report パス}"}
+```
+
+### Step 4: 上限超過終了
+
+最終行に以下の JSON を出力して終了する:
+
+```json
+{"status": "FAILED", "cycles": {実行サイクル数}, "report": "{最終 test-report パス}", "reason": "MAX_RETRIES_EXCEEDED"}
+```
+
+**出力規約:**
+- JSON は必ず最終行に出力する（Parallel Orchestra が末尾から解析できるようにするため）
+- `status` フィールドは `"SUCCESS"` または `"FAILED"` の2値のみ
+- `report` フィールドは最新の test-report への相対パス
+- `reason` フィールドは失敗時のみ付与する
+
+**タイムアウトについて:**
+tdd-develop はタイムアウトを持たない。プロセス全体のタイムアウトは Parallel Orchestra が管理する。
+
+---
+
+## Worktree Guardrail
+
+Parallel Orchestra は `claude -p --agent tdd-develop` を起動する際に
+`PO_WORKTREE_GUARD=1` 環境変数をセットすること。
+これにより `.claude/hooks/worktree_guard.py` フックが有効化され、Write/Edit ツールによる
+worktree 外へのファイル操作が機械的にブロックされる。
+
+## Related Agents
+
+- サブエージェント: tester（worktree-tdd-workflow 経由で起動）
+- サブエージェント: developer（worktree-tdd-workflow 経由で起動）
+- 上流: Parallel Orchestra（`claude -p --agent tdd-develop` で起動される）

c3/_template/.claude/agents/tester.md

@@ -0,0 +1,48 @@
+---
+model: sonnet
+description: テスト設計・実行担当。テスト仕様の設計・実行・test-report を出力する。ソース編集不可。
+tools:
+  - Read
+  - Write
+  - Bash
+  - Glob
+  - Grep
+---
+
+# Tester
+
+## Core Mandate
+テスト仕様の設計・テストコード作成・テスト実行を行い、品質状況を test-report として出力する。
+
+## Key Scope
+
+✅ 担当すること:
+- テスト仕様の設計（TDD の Red フェーズ）
+- テストコードの新規作成
+- テストの実行と結果の記録
+- test-report の出力
+
+❌ 担当しないこと:
+- プロダクションコードの実装・編集（developer の担当）
+- コード品質・セキュリティの評価（各 reviewer の担当）
+
+## Workflow
+
+**Before:**
+- plan-report を Read してテスト対象と受け入れ条件を把握する
+
+**During:**
+- 失敗するテストを先に書く（Red）
+- developer の実装後にテストを再実行して Green を確認する
+- テスト結果は合格・不合格・スキップの件数を記録する
+
+**After:**
+- `.claude/reports/test-report-YYYYMMDD-HHMMSS.md` に Write して出力する
+
+## Tools & Constraints
+制限: プロダクションコードのソースファイルを編集・書き込みしない
+
+## Related Agents
+- 上流: planner（plan-report を受け取る）
+- ピア: developer（TDD サイクルで Red → Green → Refactor を繰り返す）
+- 下流: code-reviewer・security-reviewer（test-report を受け渡す）

c3/_template/.claude/commands/develop.md

@@ -0,0 +1,10 @@
+# /develop コマンド
+
+plan-report に基づき TDD サイクルで実装を進める。
+
+## 必ず守ること
+
+1. **最初に必ず** `.claude/skills/dev-workflow.md` を Read する。記憶・推測で進めない
+2. **フェーズ D（TDD）** から実行する
+3. dev-workflow.md の AskUserQuestion・Edit・セッションファイル更新の手順を省略しない
+4. D-0 で「PO 並列実行」が選ばれた場合は、続けて **必ず** `.claude/skills/parallel-execution.md` を Read してその手順に従う

c3/_template/.claude/commands/doc.md

@@ -0,0 +1,174 @@
+# /doc コマンド
+
+ドキュメントを対話形式でヒアリングして生成する。
+対話部分は親 Claude が担当し、生成は doc-writer エージェントが行う。
+
+---
+
+## Step 1: ドキュメント種類の選択
+
+AskUserQuestion ツール:
+```json
+{
+  "questions": [{
+    "question": "作成するドキュメントの種類を選択してください",
+    "options": [
+      { "label": "mermaid図", "description": "フロー図・クラス図・ER図・シーケンス図など" },
+      { "label": "README", "description": "プロジェクト概要・セットアップ手順・使い方など" },
+      { "label": "操作手順書・運用手順書", "description": "画面操作・コマンド手順など" },
+      { "label": "API仕様書", "description": "エンドポイント・リクエスト/レスポンス定義など" }
+    ]
+  }]
+}
+```
+
+「その他」が選ばれた場合（Other 入力）: 自由記述の内容をそのまま記録する。
+
+---
+
+## Step 2: 対象ファイル・ディレクトリの指定
+
+AskUserQuestion ツール:
+```json
+{
+  "questions": [{
+    "question": "ドキュメント化する対象ファイル・ディレクトリを教えてください（例: src/api/、models/user.py）"
+  }]
+}
+```
+
+---
+
+## Step 3: 読み手の確認
+
+AskUserQuestion ツール:
+```json
+{
+  "questions": [{
+    "question": "このドキュメントの読み手は誰ですか？",
+    "options": [
+      { "label": "開発チームの新メンバー", "description": "コードを読み始める人" },
+      { "label": "開発チーム内", "description": "既存メンバーへの共有・引継ぎ" },
+      { "label": "運用・保守担当", "description": "エンジニアだがコードを書かない" },
+      { "label": "業務担当・非エンジニア", "description": "システムの利用者・管理者" }
+    ]
+  }]
+}
+```
+
+「外部レビュアー・顧客・発注者」や「その他」が選ばれた場合（Other 入力）: 自由記述の内容をそのまま記録する。
+
+---
+
+## Step 4: 目的の確認
+
+AskUserQuestion ツール:
+```json
+{
+  "questions": [{
+    "question": "このドキュメントを作る目的を教えてください",
+    "options": [
+      { "label": "全体把握・初見理解のため" },
+      { "label": "引継ぎ・担当交代のため" },
+      { "label": "レビュー・承認を得るため" },
+      { "label": "障害時の調査・対応のため" }
+    ]
+  }]
+}
+```
+
+「新メンバーのオンボーディング」や「その他」が選ばれた場合（Other 入力）: 自由記述の内容をそのまま記録する。
+
+---
+
+## Step 5: 粒度の確認
+
+**mermaid図が選ばれた場合: 必須。**
+**それ以外の場合: AskUserQuestion で確認する（不要であれば Other で「指定なし」と入力してもらう）。**
+
+AskUserQuestion ツール:
+```json
+{
+  "questions": [{
+    "question": "どのレベルの粒度で記述しますか？",
+    "options": [
+      { "label": "高レベル", "description": "モジュール・サービス単位。全体の流れを一目で把握できる" },
+      { "label": "中レベル", "description": "クラス・関数単位。主要な処理の繋がりがわかる" },
+      { "label": "低レベル", "description": "メソッド・フィールド単位。詳細な実装がわかる" }
+    ]
+  }]
+}
+```
+
+---
+
+## Step 6: 出力先の確認
+
+AskUserQuestion ツール:
+```json
+{
+  "questions": [{
+    "question": "ドキュメントの出力先を選択してください",
+    "options": [
+      { "label": "レポートとして保存", "description": ".claude/reports/doc-{名前}.md に保存（一時保管）" },
+      { "label": "プロジェクト内の指定パスに保存", "description": "次の入力でパスを指定する（例: docs/architecture.md）" },
+      { "label": "ここに表示するだけ", "description": "ファイル保存せずチャットに出力" }
+    ]
+  }]
+}
+```
+
+「プロジェクト内の指定パスに保存」が選ばれた場合: 続けて出力パスを確認する:
+```json
+{
+  "questions": [{
+    "question": "保存先のパスを入力してください（例: docs/architecture.md）"
+  }]
+}
+```
+
+---
+
+## Step 7: 確認・承認
+
+収集した内容を以下の形式で提示する:
+
+```
+ドキュメント種類 : {種類}
+対象            : {ファイル・ディレクトリ}
+読み手          : {読み手}
+目的            : {目的}
+粒度            : {粒度 / 指定なし}
+出力先          : {出力先とパス}
+```
+
+AskUserQuestion で確認する:
+```json
+{
+  "questions": [{
+    "question": "内容を確認してください。どうしますか？",
+    "options": [
+      { "label": "承認・ドキュメント生成", "description": "このまま doc-writer エージェントを起動する" },
+      { "label": "否認・最初からやり直す", "description": "Step 1 に戻る" }
+    ]
+  }]
+}
+```
+
+---
+
+## Step 8: doc-writer エージェントの起動
+
+Agent ツールで `doc-writer` エージェントを起動する。
+プロンプトに収集した全要件を含める:
+
+```
+以下の要件でドキュメントを生成してください。
+
+ドキュメント種類: {種類}
+対象ファイル・ディレクトリ: {パス}
+読み手: {読み手}
+目的: {目的}
+粒度: {粒度 / 指定なし}
+出力先: {出力先とパス}
+```

c3/_template/.claude/commands/extract-lib.md

@@ -0,0 +1,292 @@
+# /extract-lib コマンド
+
+複数プロジェクトのコードを横断解析し、共通要素を抽出してライブラリ設計・スケルトン生成を行う。
+
+---
+
+## Step 0: 規約ファイルを読み込む
+
+`.claude/rules/coding-standards.md` と `.claude/rules/project-conventions.md` を Read する。
+
+**どちらも存在しない場合:** 以下を表示して終了する:
+```
+規約ファイルが見つかりません。先に /setup を実行してプロジェクト規約を設定してください。
+```
+
+**存在する場合:** 以下を抽出して以降のステップで使用する:
+- 使用言語・フレームワーク（ファイル拡張子含む）
+- 命名規則（クラス名・関数名・定数名のパターン）
+- ファイル・ディレクトリ構成の慣習
+- その他の重要な規約
+
+---
+
+## Step 1: 解析対象プロジェクトのパスを収集する
+
+### 1回目のパス入力
+
+AskUserQuestion ツール:
+```json
+{
+  "questions": [{
+    "question": "解析対象の1つ目のプロジェクトの絶対パスを入力してください（例: C:/work/project-a）"
+  }]
+}
+```
+
+Glob で `{入力パス}/**` を検索してパスが存在するか確認する。存在しない場合は「パスが見つかりません」と伝えて再入力させる。
+
+### 2回目以降のパス追加
+
+AskUserQuestion ツール:
+```json
+{
+  "questions": [{
+    "question": "別のプロジェクトを追加しますか？",
+    "header": "パス追加",
+    "options": [
+      { "label": "追加する", "description": "さらに別のプロジェクトパスを入力する" },
+      { "label": "これで完了", "description": "入力済みのプロジェクトで解析を開始する" }
+    ]
+  }]
+}
+```
+
+「追加する」の場合は続けてパスを入力・検証し、「これで完了」になるまで繰り返す。
+入力済みプロジェクトが1つのみの状態で「これで完了」が選ばれた場合は「最低2プロジェクト必要です」と伝えて再度選択させる。
+
+---
+
+## Step 2: 出力形式を確認する
+
+AskUserQuestion ツール:
+```json
+{
+  "questions": [{
+    "question": "解析結果をどの形式で出力しますか？",
+    "header": "出力形式",
+    "options": [
+      { "label": "設計のみ", "description": "共通化候補リストとライブラリ設計案をレポートとして出力する" },
+      { "label": "設計 + スケルトン生成", "description": "設計案に加えてライブラリのスケルトンコードも生成する" }
+    ]
+  }]
+}
+```
+
+「設計 + スケルトン生成」が選ばれた場合、続けて出力先を確認する:
+```json
+{
+  "questions": [{
+    "question": "生成するライブラリの出力先ディレクトリの絶対パスを入力してください（例: C:/work/shared-lib）"
+  }]
+}
+```
+
+---
+
+## Step 3: 解析エージェントを起動する
+
+Agent ツールで解析を実行する。以下のプロンプトを使用する:
+
+```
+あなたはコードベース横断解析エージェントです。
+以下の複数プロジェクトを解析し、共通化すべき要素を抽出してください。
+
+## 解析対象プロジェクト
+{収集したプロジェクトパスのリスト}
+
+## プロジェクト規約（coding-standards.md / project-conventions.md より）
+{Step 0 で抽出した言語・フレームワーク・命名規則・その他規約}
+
+## 解析手順
+
+各プロジェクトについて順に以下を調査する。
+
+### 1. ディレクトリ構造の把握
+Glob で `{パス}/**/*.{言語の拡張子}` を検索してファイル一覧を取得する。
+規約で複数言語が使われている場合はそれぞれの拡張子で検索する。
+
+### 2. 定数・設定値の収集
+規約に合わせた定数定義パターンで Grep する。
+検索例（言語に合わせて調整すること）:
+- TypeScript/JavaScript: `const [A-Z_]+ =`
+- Java/C#: `static final|const|static readonly`
+- Python: `^[A-Z_]+ =`
+
+マジック値として使われる文字列・数値・タイムアウト値・URL パターン等も収集する。
+
+### 3. ユーティリティ関数の収集
+小規模ヘルパー関数を Grep で特定する。
+特に以下に注目する:
+- 文字列操作・日付操作・数値フォーマット
+- バリデーション処理（入力検証・型チェック等）
+- 変換処理（型変換・フォーマット変換・エンコード等）
+
+類似した関数が複数プロジェクトに存在する場合は内容を Read して比較する。
+
+### 4. 共通ロジックの収集
+ビジネスロジック上の繰り返しパターンを調査する:
+- エラーハンドリングの共通パターン
+- ログ出力のラッパー処理
+- 外部APIコール・HTTP通信の共通処理
+- ページネーション・ソート・フィルタリングの共通処理
+
+### 5. 型・インターフェース定義の収集（静的型付き言語の場合）
+型定義・インターフェース・データクラス・DTO等を Grep で収集し、
+複数プロジェクトで同一概念のものが個別定義されていないか確認する。
+
+## 出力形式
+
+以下の形式で結果をまとめること。
+
+---
+
+## 共通化候補リスト
+
+### 高優先度（完全一致・ほぼ同一のコードが複数プロジェクトに存在）
+| 種別 | 内容 | 発見場所（プロジェクト名:ファイルパス） |
+|---|---|---|
+| 定数 | ... | ProjectA: path, ProjectB: path |
+
+### 中優先度（類似ロジック・命名が異なるが同一目的）
+| 種別 | 内容 | 発見場所 | 差異の概要 |
+|---|---|---|---|
+
+### 低優先度（概念的共通・共通化は任意）
+| 種別 | 内容 | 備考 |
+|---|---|---|
+
+## ライブラリ設計案
+
+**推奨ライブラリ名**: {プロジェクト規約の命名規則に基づいた名前}
+
+**ディレクトリ構成**:
+```
+{ライブラリ名}/
+├── {モジュール1}/
+│   ├── {ファイル}
+│   └── ...
+├── {モジュール2}/
+└── ...
+```
+
+**公開API一覧**:
+| モジュール | 名前 | 種別 | 責務 |
+|---|---|---|---|
+
+**移行時の注意点**: {既存プロジェクトからライブラリへ移行する際の注意事項}
+
+---
+```
+
+解析結果を `.claude/reports/lib-extract-{YYYYMMDD}.md` に Write で保存する。
+
+---
+
+## Step 4: 解析結果の提示・承認
+
+レポートの主要な発見事項（高優先度の候補数・推奨ライブラリ構成）を要約してテキストで提示する。
+
+AskUserQuestion ツール:
+```json
+{
+  "questions": [{
+    "question": "解析結果を確認してください。どうしますか？",
+    "header": "確認",
+    "options": [
+      { "label": "承認・次へ進む", "description": "この設計案でスケルトン生成または完了する" },
+      { "label": "設計案を修正する", "description": "フィードバックを入力して設計を見直す" },
+      { "label": "ここで終了する", "description": "レポートのみ保存して終了する" }
+    ]
+  }]
+}
+```
+
+**「承認・次へ進む」の場合:**
+セッションファイル（`.claude/memory/sessions/*.tmp` の最新）の `## うまくいったアプローチ` に以下を追記する:
+```
+- [extract-lib] {承認された設計アプローチの要点（ライブラリ名・モジュール分割方針・特に有効だった抽出種別）}
+```
+
+**「設計案を修正する」の場合:**
+フィードバックを収集する:
+```json
+{
+  "questions": [{
+    "question": "どのように修正してほしいですか？（例: この定数は除外したい・命名を変えたい・モジュール分割を変えたい）"
+  }]
+}
+```
+セッションファイルの `## 試みたが失敗したアプローチ` に以下を追記する:
+```
+- [extract-lib] {否認された設計案の何が問題だったか（フィードバック内容を要約）}
+```
+フィードバックを追加指示としてプロンプトに加えて Step 3 の解析エージェントを再起動する。
+
+**「ここで終了する」の場合:**
+Step 6 の完了メッセージ（スケルトンなし）を表示して終了する。
+
+---
+
+## Step 5: スケルトン生成（Step 2 で「設計 + スケルトン生成」を選んだ場合のみ）
+
+Agent ツールでスケルトンコード生成を行う:
+
+```
+あなたはライブラリスケルトン生成エージェントです。
+以下の設計案に基づいてライブラリのスケルトンコードを生成してください。
+
+## 設計案
+{Step 3 で生成したレポートのライブラリ設計案セクション全体}
+
+## プロジェクト規約
+{Step 0 で抽出した規約}
+
+## 出力先
+{Step 2 で入力した出力先パス}
+
+## 生成方針
+- 実際のロジックは TODO コメントを残した空実装にする（シグネチャと型は完成状態で）
+- 公開APIのドキュメントコメント（JSDoc / Javadoc / docstring 等）は完成状態で生成する
+- 出力先ディレクトリ直下に README.md を生成する
+  - 概要・インストール方法・使い方（基本的な呼び出し例）を記載する
+  - 既存プロジェクトからの移行例を1つ記載する
+- 言語の標準的なパッケージ管理ファイル（package.json / build.gradle / pyproject.toml 等）も生成する
+```
+
+---
+
+## Step 6: セッション記録・完了メッセージ
+
+### セッションファイルへの記録
+
+セッションファイル（`.claude/memory/sessions/*.tmp` の最新）の JSON ブロック `"patterns"` 配列に、
+今回の解析で発見した共通化パターンを追記する。
+
+記録する内容（1〜3件に絞る）:
+- 高優先度で発見された共通要素の傾向（例: 「このプロジェクト群では日付フォーマット関数が全プロジェクトに重複する」）
+- 有効だったモジュール分割のアプローチ（例: 「定数・ユーティリティ・型を別モジュールに分けると承認されやすい」）
+
+記録形式:
+```json
+{
+  "id": "extract_lib_{内容を表す英数字ID}",
+  "description": "どんなプロジェクト群でどんな共通化パターンが見つかるかを1文で"
+}
+```
+
+### 完了メッセージ
+
+以下を表示して終了する:
+
+```
+完了しました。
+
+レポート  : .claude/reports/lib-extract-{YYYYMMDD}.md
+スケルトン: {出力先パス}（生成した場合）
+
+次のステップ:
+1. レポートの設計案を確認し、必要に応じて調整する
+2. 各プロジェクトの該当箇所をライブラリに置き換える
+3. /review でライブラリのコードレビューを実施する
+```