claude-code-conductor 2.2.0__tar.gz → 2.3.0__tar.gz

{claude_code_conductor-2.2.0 → claude_code_conductor-2.3.0}/.claude/agents/code-reviewer.md

@@ -47,7 +47,8 @@ tools:
 
 **During:**
 - 指摘は重大度（High / Medium / Low）で分類する
-- **指摘ごとに該当する checklist_id を `[CR-XX-NNN]` 形式で併記する**（`.claude/rules/code-review-checklist.md` の各項目に付与済み）。F-001 レビュー判断ヒント機能の照合キーになるため、必須とする。複数該当する場合は最も近いものを 1 つ選ぶ
+- **指摘ごとに該当する checklist_id を `[CR-XX-NNN]` 形式で併記する**（`.claude/rules/code-review-checklist.md` の各項目に付与済み）。review-hint（レビュー判断ヒント機能）の照合キーになるため、必須とする。複数該当する場合は最も近いものを 1 つ選ぶ
+- **該当 ID がない場合は `[CR-NEW]` で出す**（チェックリスト追加候補として扱う）。無理やり近い既存 ID にマッピングしないこと。review-hint の照合精度が落ち、チェックリストの成長機会も失われるため
 - 良い実装は明示的に記録する（削除しないよう伝える）
 - 修正必須と推奨の2段階で提示する
 

{claude_code_conductor-2.2.0 → claude_code_conductor-2.3.0}/.claude/agents/security-reviewer.md

@@ -48,7 +48,8 @@ SQLインジェクション・XSS・認証認可・秘密情報漏洩などの
 
 **During:**
 - 指摘は深刻度（Critical / High / Medium / Low）で分類する
-- **指摘ごとに該当する checklist_id を `[SR-XX-NNN]` 形式で併記する**（`.claude/rules/security-review-checklist.md` の各項目に付与済み）。F-001 レビュー判断ヒント機能の照合キーになるため、必須とする。複数該当する場合は最も近いものを 1 つ選ぶ
+- **指摘ごとに該当する checklist_id を `[SR-XX-NNN]` 形式で併記する**（`.claude/rules/security-review-checklist.md` の各項目に付与済み）。review-hint（レビュー判断ヒント機能）の照合キーになるため、必須とする。複数該当する場合は最も近いものを 1 つ選ぶ
+- **該当 ID がない場合は `[SR-NEW]` で出す**（チェックリスト追加候補として扱う）。無理やり近い既存 ID にマッピングしないこと。review-hint の照合精度が落ち、チェックリストの成長機会も失われるため
 - 悪用シナリオを具体的に記述して再現可能な形で報告する
 - 修正方法の例を提示する
 

{claude_code_conductor-2.2.0 → claude_code_conductor-2.3.0}/.claude/agents/tester.md

@@ -59,7 +59,6 @@ tools:
 
 ## Tools & Constraints
 制限: プロダクションコードのソースファイルを編集・書き込みしない
-必須: Skill ツールで `report-timestamp` を呼び出しタイムスタンプを取得し、test-report を `.claude/reports/test-report-{timestamp}.md` に Write すること（出力なしでの終了は不可）
 
 ## Related Agents
 - 上流: planner（plan-report を受け取る）

{claude_code_conductor-2.2.0 → claude_code_conductor-2.3.0}/.claude/agents/wt_developer.md

@@ -3,7 +3,7 @@ name: wt_developer
 model: sonnet
 memory: project
 permissionMode: bypassPermissions
-description: 並列 worktree 専用 developer。parallel-agents skill が isolation:"worktree" 付きで起動する用途。本文は developer.md と同一。permission プロンプトを worktree 内でスキップする。
+description: 並列 worktree 専用 developer。parallel-agents skill が isolation:"worktree" 付きで起動する用途。Stuck Signal のファイル名を task_id ベースにし、permission プロンプトを worktree 内でスキップする。
 tools:
   - Read
   - Write
@@ -73,11 +73,11 @@ plan-report に基づき実装・デバッグ・リファクタリングを行
 
 同じ問題に対して3回以上アプローチを変えても解決できない場合:
 
-1. Skill ツールで `report-timestamp` を呼び出してタイムスタンプを取得する
-2. `.claude/reports/debug-needed-{timestamp}.md` を Write する。記載内容:
+1. **必ず** プロンプトで指定された `task_id` をもとに `.claude/reports/debug-needed-{task_id}.md` を Write する（並列実行時の衝突回避 + 親 Claude が後続 wave で systematic-debugger を呼ぶ際に対象 task を特定するため）。記載内容:
    - 実装しようとしていたこと
    - 試みたアプローチと失敗の内容（エラーメッセージ・スタックトレース含む）
    - 現在のコードの状態（関連する箇所の抜粋）
+2. 保険（task_id がプロンプトから読み取れない異常系のみ）: Skill ツールで `report-timestamp` を呼び出してタイムスタンプを取得し、`.claude/reports/debug-needed-{timestamp}.md` を Write する。通常運用ではこの経路に入ってはいけない
 3. 作業を止めて呼び出し元に返す。コミット・Edit は不要
 
 ## Tools & Constraints

{claude_code_conductor-2.2.0 → claude_code_conductor-2.3.0}/.claude/agents/wt_systematic-debugger.md

@@ -3,7 +3,7 @@ name: wt_systematic-debugger
 model: sonnet
 memory: project
 permissionMode: bypassPermissions
-description: 並列 worktree 専用 systematic-debugger。parallel-agents skill が isolation:"worktree" 付きで起動する用途。本文は systematic-debugger.md と同一。permission プロンプトを worktree 内でスキップする。
+description: 並列 worktree 専用 systematic-debugger。parallel-agents skill が isolation:"worktree" 付きで起動する用途。debug-analysis のファイル名を task_id ベースにし、permission プロンプトを worktree 内でスキップする。
 tools:
   - Read
   - Write
@@ -85,9 +85,9 @@ developer が詰まった問題の根本原因を調査し、debug-analysis-repo
 
 ### Step 4: debug-analysis-report の出力
 
-Skill ツールで `report-timestamp` を呼び出してタイムスタンプを取得する。
+**必ず** プロンプトで指定された `task_id` をもとに `.claude/reports/debug-analysis-{task_id}.md` に Write する。これは `parallel-agents` skill の `writes` 宣言と一致させ、並列実行時のファイル名衝突を避けるために必須。
 
-`.claude/reports/debug-analysis-{timestamp}.md` を Write する。
+保険（task_id がプロンプトから読み取れない異常系のみ）: Skill ツールで `report-timestamp` を呼び出してタイムスタンプを取得し、`.claude/reports/debug-analysis-{timestamp}.md` を Write する。通常運用ではこの経路に入ってはいけない。
 
 レポートの構成:
 

{claude_code_conductor-2.2.0 → claude_code_conductor-2.3.0}/.claude/agents/wt_tester.md

@@ -3,7 +3,7 @@ name: wt_tester
 model: sonnet
 memory: project
 permissionMode: bypassPermissions
-description: 並列 worktree 専用 tester。parallel-agents skill が isolation:"worktree" 付きで起動する用途。本文は tester.md と同一。permission プロンプトを worktree 内でスキップする。
+description: 並列 worktree 専用 tester。parallel-agents skill が isolation:"worktree" 付きで起動する用途。test-report のファイル名を task_id ベースにし、permission プロンプトを worktree 内でスキップする。
 tools:
   - Read
   - Write
@@ -58,13 +58,13 @@ tools:
 - テスト結果は合格・不合格・スキップの件数を記録する
 
 **After:**
-- **必ず** Skill ツールで `report-timestamp` を呼び出しタイムスタンプを取得し、`.claude/reports/test-report-YYYYMMDD-HHMMSS.md` に Write して出力する
+- **必ず** プロンプトで指定された `task_id` をもとに `.claude/reports/test-report-{task_id}.md` に Write して出力する。これは `parallel-agents` skill の `writes` 宣言と一致させ、並列実行時のファイル名衝突を避けるために必須
+- 保険（task_id がプロンプトから読み取れない異常系のみ）: Skill ツールで `report-timestamp` を呼び出してタイムスタンプを取得し、`.claude/reports/test-report-{timestamp}.md` に Write する。通常運用ではこの経路に入ってはいけない
 - test-report を Write せずにターンを終了することは禁止
 - Red フェーズの test-report には失敗理由（機能未実装による失敗であること）を明記する
 
 ## Tools & Constraints
 制限: プロダクションコードのソースファイルを編集・書き込みしない
-必須: Skill ツールで `report-timestamp` を呼び出しタイムスタンプを取得し、test-report を `.claude/reports/test-report-{timestamp}.md` に Write すること（出力なしでの終了は不可）
 
 ## Related Agents
 - 上流: planner（plan-report を受け取る）

{claude_code_conductor-2.2.0 → claude_code_conductor-2.3.0}/.claude/hooks/consolidate_memory.py

@@ -1,7 +1,7 @@
 #!/usr/bin/env python3
 """Stop hook: consolidate the last N days of session memory into a summary.
 
-F-004 MVP: 過去 N 日分の `.claude/memory/sessions/YYYYMMDD.tmp` から
+memory-consolidation MVP: 過去 N 日分の `.claude/memory/sessions/YYYYMMDD.tmp` から
 - ``## うまくいったアプローチ``
 - ``## 試みたが失敗したアプローチ``
 の各セクションを集約し、`.claude/memory/consolidated_summary.md` に出力する。
@@ -47,7 +47,7 @@ except AttributeError:
 # 集約ウィンドウ（直近何日分の session ファイルを対象にするか）
 DEFAULT_WINDOW_DAYS = 7
 
-# F-004 Phase 2-A: archive 機能の生存期間（日）。
+# memory-consolidation Phase 2-A: archive 機能の生存期間（日）。
 # DEFAULT_WINDOW_DAYS の 3 倍。要約ウィンドウから外れた直後すぐに archive せず、
 # 過去サマリ再生成のための猶予を確保する。
 # 環境変数 ``C3_CONSOLIDATE_ARCHIVE_TTL_DAYS`` で上書き可能。
@@ -56,7 +56,7 @@ DEFAULT_ARCHIVE_TTL_DAYS = DEFAULT_WINDOW_DAYS * 3
 # 出力先（プロジェクトローカル）
 OUTPUT_FILE_NAME = "consolidated_summary.md"
 
-# F-004 Phase 2-B: 半自動 promotion 候補ログの出力ファイル名
+# memory-consolidation Phase 2-B: 半自動 promotion 候補ログの出力ファイル名
 PROMOTION_CANDIDATES_FILE_NAME = "promotion-candidates.md"
 
 # 候補ログの description 列の最大文字数（表セルの可読性確保）
@@ -65,7 +65,7 @@ _PROMOTION_DESC_MAX_LEN = 80
 # 候補ログの ID 列の最大文字数（表セル幅を抑える、id が極端に長い場合の保険）
 _PROMOTION_CID_MAX_LEN = 60
 
-# F-004 Phase 2-C: LLM 要約パラメータ
+# memory-consolidation Phase 2-C: LLM 要約パラメータ
 # LLM プロンプトに渡す入力テキストの最大文字数（「うまくいった」「失敗した」各セクション合計）
 _LLM_INPUT_MAX_CHARS = 6000
 # LLM 応答の最大文字数（超過時は末尾を切り詰めマーカーで上書き）
@@ -97,7 +97,7 @@ LOCK_STALE_SEC = 120
 # `--llm-only` モードのフラグ
 LLM_ONLY_FLAG = "--llm-only"
 
-# F-004 消費側: CLAUDE.md @include 用の小ファイル（LLM 要約セクションのみ抽出）。
+# memory-consolidation 消費側: CLAUDE.md @include 用の小ファイル（LLM 要約セクションのみ抽出）。
 # 毎セッション開始時に Claude のコンテキストに自動注入されるため、
 # サイズを LLM 要約の最大 4KB 程度に抑える。
 LLM_SUMMARY_FILE_NAME = "llm_summary.md"
@@ -232,11 +232,11 @@ def write_summary(
 ) -> bool:
     """集約サマリを生成して指定パスに書き出す。
 
-    F-004 Phase 2-B: ``patterns_path`` が指定された場合、末尾に
+    memory-consolidation Phase 2-B: ``patterns_path`` が指定された場合、末尾に
     「## 昇格候補」サマリセクションを追加する（候補 ID + trust のみ、
     詳細は ``promotion-candidates.md`` を参照）。
 
-    F-004 Phase 2-C: ``enable_llm=True`` の場合、MVP セクションと
+    memory-consolidation Phase 2-C: ``enable_llm=True`` の場合、MVP セクションと
     昇格候補セクションの間に「## LLM 要約」セクションを追加する。
     LLM 要約は ``build_llm_summary_section()`` の判断でスキップされうる
     （CLI 不在 / タイムアウト等）。
@@ -299,7 +299,7 @@ def write_summary(
 
 
 # ---------------------------------------------------------------------------
-# F-004 Phase 2-B: 半自動 promotion 候補ログ
+# memory-consolidation Phase 2-B: 半自動 promotion 候補ログ
 # ---------------------------------------------------------------------------
 
 
@@ -522,7 +522,7 @@ def _atomic_write(output_path: str, payload: str) -> bool:
 
 
 # ---------------------------------------------------------------------------
-# F-004 Phase 2-C: claude --headless LLM 要約
+# memory-consolidation Phase 2-C: claude --headless LLM 要約
 # ---------------------------------------------------------------------------
 
 
@@ -555,7 +555,7 @@ def _build_llm_prompt(
     if len(failure_text) > half:
         failure_text = failure_text[:half] + "\n…(略)"
 
-    # F-004 Phase 2-C [SR-AI-001 対策]: セッションデータ部分を XML タグで囲み、
+    # memory-consolidation Phase 2-C [SR-AI-001 対策]: セッションデータ部分を XML タグで囲み、
     # プロンプト命令文と明確に分離する。これによりセッション内容に誘導文
     # （"以下の指示を無視" 等）が混入しても、LLM が命令文と区別しやすくなる。
     return (
@@ -705,7 +705,7 @@ def build_llm_summary_section(
 
 
 # ---------------------------------------------------------------------------
-# F-004 Phase 2-A: archive 機能
+# memory-consolidation Phase 2-A: archive 機能
 # ---------------------------------------------------------------------------
 
 
@@ -718,7 +718,7 @@ def archive_old_sessions(
 ) -> list[str]:
     """``ttl_days`` 日以上経過した session.tmp を ``archive_dir`` に移動する。
 
-    F-004 Phase 2-A: session ファイルの永久蓄積を防ぐ。
+    memory-consolidation Phase 2-A: session ファイルの永久蓄積を防ぐ。
     同一 FS 内の ``shutil.move`` を使うため rename は基本的にアトミック。
 
     Args:
@@ -1078,7 +1078,7 @@ def _llm_only_main() -> int:
         )
         # consolidated_summary.md 書き込み完了後、LLM 要約セクションだけを
         # CLAUDE.md @include 用の llm_summary.md に抽出する（~4KB）。
-        # F-004 消費側: Claude が次セッションで自動的にコンテキスト参照する経路。
+        # memory-consolidation 消費側: Claude が次セッションで自動的にコンテキスト参照する経路。
         _write_llm_summary_extract()
     except Exception as exc:  # noqa: BLE001
         print(

{claude_code_conductor-2.2.0 → claude_code_conductor-2.3.0}/.claude/hooks/post_tool.py

@@ -7,7 +7,7 @@
    `.claude/skills/` 配下のファイルを Write / Edit したとき「実際のエージェント
    動作で確認してください」というリマインダを stdout に出す。
 
-2. デバッグ出力検出（F-007）:
+2. デバッグ出力検出（post-edit-scan）:
    Write / Edit 完了後に対象ファイルへ console.log / print( / TODO /
    FIXME / XXX を検出して stderr に警告する。code-review-checklist.md の
    「不要なデバッグ出力が残っていないか」項目を自動化する位置付け。

{claude_code_conductor-2.2.0 → claude_code_conductor-2.3.0}/.claude/hooks/pre_tool.py

@@ -38,7 +38,7 @@ def _is_rm_rf(tokens: list[str], rm_idx: int) -> bool:
     return has_r and has_f
 
 
-# 秘密情報パターン (F-006)
+# 秘密情報パターン (secret-scan)
 # 検出値そのものは警告に含めない（二次漏洩防止）。パターン名のみを返す。
 # 初期パターンは「= で続く値」を必須とすることで、シェルコメント
 # （# password reset 等）の誤爆を回避する。
@@ -104,7 +104,7 @@ def main():
                 print(f'[PreToolUse BLOCK] 危険なコマンドをブロックしました: {cmd_preview}', file=sys.stderr)
                 sys.exit(2)
 
-    # 秘密情報の代入を検出: ブロック (F-006)
+    # 秘密情報の代入を検出: ブロック (secret-scan)
     # bypass: C3_SKIP_SECRET_CHECK=1 で検出をスキップ（誤爆時の逃げ道）
     if os.environ.get('C3_SKIP_SECRET_CHECK') != '1':
         is_secret, pattern_name = _contains_secret(cmd)

{claude_code_conductor-2.2.0 → claude_code_conductor-2.3.0}/.claude/hooks/record_review_decision.py

@@ -1,7 +1,7 @@
 #!/usr/bin/env python3
 """CLI: record a review decision in c3.db.review_decisions.
 
-F-001: dev-workflow フェーズ E でユーザーが「対応 / 許容 / 保留」を選んだ
+review-hint: dev-workflow フェーズ E でユーザーが「対応 / 許容 / 保留」を選んだ
 判断を SQLite に記録するための薄い CLI ラッパー。実装本体は
 ``c3.db.insert_review_decision``。
 

{claude_code_conductor-2.2.0 → claude_code_conductor-2.3.0}/.claude/hooks/record_tier_outcome.py

@@ -1,7 +1,7 @@
 #!/usr/bin/env python3
 """CLI: record the outcome of the previously-selected tier in tier_bandit.
 
-F-005 MVP: dev-workflow フェーズ E の承認/否認シグナルを受けて、
+tier-routing MVP: dev-workflow フェーズ E の承認/否認シグナルを受けて、
 ``select_tier.py`` が直近に書いた ``.claude/state/tier_selection.json`` を
 読み、対応する Tier の (alpha, beta, trials) を ``tier_bandit`` テーブルで
 更新する。
@@ -119,7 +119,7 @@ def _append_prompt_history(selection: dict, success: bool) -> None:
 
 def main(argv: list[str] | None = None) -> int:
     parser = argparse.ArgumentParser(
-        description="Record tier outcome for F-005 Thompson Sampling"
+        description="Record tier outcome for tier-routing Thompson Sampling"
     )
     parser.add_argument(
         "--outcome",

{claude_code_conductor-2.2.0 → claude_code_conductor-2.3.0}/.claude/hooks/review_hint_inject.py

@@ -1,7 +1,7 @@
 #!/usr/bin/env python3
 """Inject past review decisions as hints into a review report.
 
-F-001: レビュー判断ヒント機能。code-reviewer / security-reviewer が
+review-hint: レビュー判断ヒント機能。code-reviewer / security-reviewer が
 生成したレビューレポート（`.claude/reports/code-review-report-*.md` /
 `security-review-report-*.md`）に、過去の許容例外・対応履歴を後付けで追記する。
 

{claude_code_conductor-2.2.0 → claude_code_conductor-2.3.0}/.claude/hooks/schema.sql

@@ -1,4 +1,4 @@
--- C3 SQLite schema (F-009: DuckDB ハイブリッド構成の基盤)
+-- C3 SQLite schema (duckdb-hybrid: DuckDB ハイブリッド構成の基盤)
 --
 -- このファイルは session_start.py の _run_init_c3_db ハンドラから読まれ、
 -- `.claude/state/c3.db` に対して冪等に CREATE TABLE IF NOT EXISTS で適用される。
@@ -20,7 +20,7 @@ DROP TABLE IF EXISTS po_results;
 DROP TABLE IF EXISTS po_status;
 
 -- ---------------------------------------------------------------------------
--- F-009 自身: スキーマバージョン管理
+-- スキーマバージョン管理
 -- ---------------------------------------------------------------------------
 
 CREATE TABLE IF NOT EXISTS schema_version (
@@ -29,7 +29,7 @@ CREATE TABLE IF NOT EXISTS schema_version (
 );
 
 -- ---------------------------------------------------------------------------
--- F-001: レビュー判断ヒント機能
+-- review-hint: レビュー判断ヒント機能
 -- ---------------------------------------------------------------------------
 -- code-reviewer / security-reviewer の指摘に対して、人間が下した判断
 -- （対応 / 許容 / 保留）と理由を蓄積する。次回以降のレビュー時に過去判断を
@@ -49,9 +49,7 @@ CREATE INDEX IF NOT EXISTS idx_review_decisions_checklist
     ON review_decisions(checklist_id, decided_at DESC);
 
 -- ---------------------------------------------------------------------------
--- F-002: PO 集約レイヤ
--- ---------------------------------------------------------------------------
--- F-005: Tier 自動ルーティング（Thompson Sampling 学習データ）
+-- tier-routing: Tier 自動ルーティング（Thompson Sampling 学習データ）
 -- ---------------------------------------------------------------------------
 -- タスク複雑度ごとに各 Tier の Beta(α, β) 事前分布を保持する。
 -- α / β は完了ごとに更新され、サンプリングで次の Tier を選ぶ。
@@ -66,7 +64,7 @@ CREATE TABLE IF NOT EXISTS tier_bandit (
     PRIMARY KEY (task_complexity, tier)
 );
 
--- F-005 Phase 2-B: 直近 N 件の outcome を保持して failure rate を計算する。
+-- tier-routing Phase 2-B: 直近 N 件の outcome を保持して failure rate を計算する。
 -- tier_bandit が「累積 α/β」の集約を持つのに対し、こちらは個別 event の履歴。
 -- select_tier.py が直近 5 件以上で failure rate ≥ 0.5 を検出したら 1 段昇格する。
 CREATE TABLE IF NOT EXISTS tier_recent_outcomes (
@@ -80,10 +78,10 @@ CREATE INDEX IF NOT EXISTS idx_tier_recent
     ON tier_recent_outcomes(task_complexity, tier, ts DESC);
 
 -- ---------------------------------------------------------------------------
--- F-008: SubagentStop メトリクス（既存 JSONL と並行運用）
+-- subagent-metrics: SubagentStop メトリクス（既存 JSONL と並行運用）
 -- ---------------------------------------------------------------------------
 -- subagent_log.py が JSONL に追記している記録を SQLite にも保存する。
--- F-005 の学習データ収集の前提。
+-- tier-routing の学習データ収集の前提。
 -- 既存 .claude/logs/agent-runs.jsonl は移行までの間並行運用する。
 
 CREATE TABLE IF NOT EXISTS agent_runs (

{claude_code_conductor-2.2.0 → claude_code_conductor-2.3.0}/.claude/hooks/select_tier.py

@@ -1,7 +1,7 @@
 #!/usr/bin/env python3
 """UserPromptSubmit hook: recommend an LLM Tier (haiku/sonnet/opus) for the prompt.
 
-F-005 MVP: タスクの複雑度を簡易ヒューリスティックで推定し、Thompson Sampling
+tier-routing MVP: タスクの複雑度を簡易ヒューリスティックで推定し、Thompson Sampling
 （または学習データ収集期は uniform random）で推奨 Tier を決定して
 ``additionalContext`` で親 Claude に伝える。
 
@@ -288,11 +288,11 @@ def write_tier_selection(
     record_tier_outcome.py がこの json を読んで α/β を更新する。
     既存ファイルは上書きされる（最新 1 件のみ保持）。
 
-    F-005 Phase 2-A: ``suggested_model`` も併せて書く。runner.py がこれを読んで
+    tier-routing Phase 2-A: ``suggested_model`` も併せて書く。runner.py がこれを読んで
     PO 経由のサブエージェント起動時に ``claude --agents`` で動的に上書きする。
     tier 名と model の短縮名は同一とする。
 
-    F-005 Phase 2-B: ``escalated`` / ``escalation_reason`` を任意で含める。
+    tier-routing Phase 2-B: ``escalated`` / ``escalation_reason`` を任意で含める。
     failure rate に基づく昇格が起きた場合のみ True / 文字列が入る。
     """
     os.makedirs(os.path.dirname(TIER_SELECTION_PATH), exist_ok=True)
@@ -345,7 +345,7 @@ def build_additional_context(
         suffix += f" [複雑度判定: {complexity_source}]"
 
     return (
-        f"[F-005 Tier 推奨] 複雑度: {complexity} / 推奨 Tier: {tier}（{confidence}）。"
+        f"[tier-routing 推奨] 複雑度: {complexity} / 推奨 Tier: {tier}（{confidence}）。"
         f"PO 経由のサブエージェント起動時はこの推奨が claude --agents JSON で"
         f" 自動適用されます（Phase 2-A）。親 Claude の Agent ツール経由は依然"
         f" frontmatter 指定が優先されるため、コスト最適化したい場合は手動切替"

{claude_code_conductor-2.2.0 → claude_code_conductor-2.3.0}/.claude/hooks/session_start.py

@@ -4,7 +4,7 @@
 3 つの責務を順に実行する:
 1. file-history のクリア（旧 clear_file_history.py）
 2. sandbox 設定の有効化（旧 enable_sandbox.py、worktree ではスキップ）
-3. C3 SQLite DB の初期化（旧 init_c3_db.py、F-009 基盤）
+3. C3 SQLite DB の初期化（旧 init_c3_db.py、duckdb-hybrid 基盤）
 
 各処理は独立しており、1 つが失敗しても他を実行する（exit 0 を返す）。
 失敗してもセッションは止めない（C3 の他機能を妨げない方針）。

{claude_code_conductor-2.2.0 → claude_code_conductor-2.3.0}/.claude/hooks/session_utils.py

@@ -60,7 +60,7 @@ def ensure_session_initialized(path: str, date_str: str) -> None:
 def extract_section(content: str, heading: str) -> str:
     """セッションファイル本文から ``## {heading}`` セクションの内容を抽出する。
 
-    F-004（MemoryConsolidation）と restore_session.py で共通利用される。
+    memory-consolidation（MemoryConsolidation）と restore_session.py で共通利用される。
     ``## {heading}\\n`` から次の ``\\n## `` または ``\\n<!--`` または末尾までを返す。
     見つからない場合は空文字列を返す。
 

{claude_code_conductor-2.2.0 → claude_code_conductor-2.3.0}/.claude/hooks/subagent_log.py

@@ -49,16 +49,16 @@ _MAX_SCAN_LINES = 10_000
 _EVENT_START = "SubagentStart"
 _EVENT_STOP = "SubagentStop"
 
-# F-002 Phase 2-B: SubagentStop の status 値の正常終了マーカー（仕様変更時の単一窓口）。
+# po-sqlite Phase 2-B: SubagentStop の status 値の正常終了マーカー（仕様変更時の単一窓口）。
 _STATUS_SUCCESS = "success"
 
-# F-002 Phase 2-B: po_status.current_step の最大文字数 [SR-V-001]。
+# po-sqlite Phase 2-B: po_status.current_step の最大文字数 [SR-V-001]。
 # payload.agent_type / agent_id は任意文字列のため DB 容量保護のため切り詰める。
 _MAX_CURRENT_STEP_LEN = 200
 
 # payload のホワイトリスト対象フィールド (sec-M-1)
-# F-008: total_tokens / status / token_usage / model を追加。
-# Tier 自動ルーティング (F-005) の学習データ収集の前提となる。
+# subagent-metrics: total_tokens / status / token_usage / model を追加。
+# Tier 自動ルーティング (tier-routing) の学習データ収集の前提となる。
 # result 系（応答本文・コード断片混入リスク）は意図的に除外。
 _SAFE_PAYLOAD_FIELDS = frozenset({
     'hook_event_name',

{claude_code_conductor-2.2.0 → claude_code_conductor-2.3.0}/.claude/rules/code-review-checklist.md

@@ -1,7 +1,9 @@
 # Code Review Checklist
 
 各項目には `[CR-XX-NNN]` 形式の checklist_id を付与している。
-レビュー時に指摘する場合はこの ID を併記すること（F-001: レビュー判断ヒント機能の照合キー）。
+レビュー時に指摘する場合はこの ID を併記すること（review-hint 機能の照合キー）。
+
+**該当 ID がない指摘**は `[CR-NEW]` を使う。無理やり近い既存 ID にマッピングしないこと（review-hint の照合精度が落ち、チェックリストの成長機会も失われるため）。`[CR-NEW]` 指摘は本チェックリストへの追加候補として扱う。
 
 ## 必須チェック項目（全作成物共通）
 

{claude_code_conductor-2.2.0 → claude_code_conductor-2.3.0}/.claude/rules/security-review-checklist.md

@@ -1,7 +1,9 @@
 # Security Review Checklist
 
 各項目には `[SR-XX-NNN]` 形式の checklist_id を付与している。
-レビュー時に指摘する場合はこの ID を併記すること（F-001: レビュー判断ヒント機能の照合キー）。
+レビュー時に指摘する場合はこの ID を併記すること（review-hint 機能の照合キー）。
+
+**該当 ID がない指摘**は `[SR-NEW]` を使う。無理やり近い既存 ID にマッピングしないこと（review-hint の照合精度が落ち、チェックリストの成長機会も失われるため）。`[SR-NEW]` 指摘は本チェックリストへの追加候補として扱う。
 
 ## 必須チェック項目（OWASP Top 10 準拠・全作成物共通）
 

{claude_code_conductor-2.2.0 → claude_code_conductor-2.3.0}/.claude/skills/dev-workflow/SKILL.md

@@ -380,7 +380,7 @@ AskUserQuestion で確認する:
 
 Agent ツールで `code-reviewer` エージェントを起動する。
 
-**F-001 過去判断ヒント注入（レポート生成後）:**
+**review-hint 過去判断ヒント注入（レポート生成後）:**
 code-reviewer がレポートを Write し終えたら、Bash で `.claude/hooks/review_hint_inject.py` を呼んで過去判断ヒントをレポート末尾に追記する:
 
 ```bash
@@ -438,7 +438,7 @@ AskUserQuestion で確認する:
 ```
 1. 対応する指摘に `> **[対応予定]**` を追記する
 2. 許容する指摘の直下に `> **[許容]** {理由}` を Edit で追記する（検出記録は削除しない）
-3. **F-001 判断記録**: 各指摘について Bash で c3.db に記録する（`[CR-XX-NNN]` を含むもののみ）:
+3. **review-hint 判断記録**: 各指摘について Bash で c3.db に記録する（`[CR-XX-NNN]` を含むもののみ。`[CR-NEW]` は記録対象外、チェックリスト追加候補として別途扱う）:
    ```bash
    python .claude/hooks/record_review_decision.py \
      --checklist-id CR-Q-001 \
@@ -460,7 +460,7 @@ AskUserQuestion で許容理由を確認する:
 }
 ```
 1. 全指摘の直下に `> **[許容]** {理由}` を Edit で追記する（検出記録は削除しない）
-2. **F-001 判断記録**: 全 `[CR-XX-NNN]` 指摘について `record_review_decision.py --decision accepted` で記録する
+2. **review-hint 判断記録**: 全 `[CR-XX-NNN]` 指摘について `record_review_decision.py --decision accepted` で記録する
 3. セッションファイルの `## うまくいったアプローチ` に `[許容例外] {指摘内容} → {許容理由}` の形式で追記し `patterns` に記録する
 4. セッションファイルの `- [ ] code-review` を `- [x]` に Edit して E-2 へ。
 
@@ -474,7 +474,7 @@ AskUserQuestion で許容理由を確認する:
 
 Agent ツールで `security-reviewer` エージェントを起動する。
 
-**F-001 過去判断ヒント注入（レポート生成後）:**
+**review-hint 過去判断ヒント注入（レポート生成後）:**
 security-reviewer がレポートを Write し終えたら、Bash で `.claude/hooks/review_hint_inject.py` に **両レポートのパス** を渡して呼ぶ。両方渡すことで重複指摘フラグ（同じ checklist_id を CR と SR が指摘）が判定される:
 
 ```bash
@@ -503,7 +503,7 @@ AskUserQuestion で確認する:
 ```
 
 承認後 → セッションファイルの `- [ ] security-review` を `- [x]` に Edit する。続けて **「引き継ぎバックログの照合」**（後述の共通ステップ）を実行してからコミットを提案する。
-**F-005 結果記録**: フェーズ E の最終承認時のみ Bash で記録する（多重カウント防止のため E-1 では記録しない）:
+**tier-routing 結果記録**: フェーズ E の最終承認時のみ Bash で記録する（多重カウント防止のため E-1 では記録しない）:
 ```bash
 python .claude/hooks/record_tier_outcome.py --outcome success
 ```
@@ -538,7 +538,7 @@ python .claude/hooks/record_tier_outcome.py --outcome success
 ```
 1. 対応する指摘に `> **[対応予定]**` を追記する
 2. 許容する指摘の直下に `> **[許容]** {理由}` を Edit で追記する（検出記録は削除しない）
-3. **F-001 判断記録**: 各指摘について Bash で c3.db に記録する（`[SR-XX-NNN]` を含むもののみ）:
+3. **review-hint 判断記録**: 各指摘について Bash で c3.db に記録する（`[SR-XX-NNN]` を含むもののみ。`[SR-NEW]` は記録対象外、チェックリスト追加候補として別途扱う）:
    ```bash
    python .claude/hooks/record_review_decision.py \
      --checklist-id SR-K-002 \
@@ -560,10 +560,10 @@ AskUserQuestion で許容理由を確認する:
 }
 ```
 1. 全指摘の直下に `> **[許容]** {理由}` を Edit で追記する（検出記録は削除しない）
-2. **F-001 判断記録**: 全 `[SR-XX-NNN]` 指摘について `record_review_decision.py --decision accepted` で記録する
+2. **review-hint 判断記録**: 全 `[SR-XX-NNN]` 指摘について `record_review_decision.py --decision accepted` で記録する
 3. セッションファイルの `## うまくいったアプローチ` に `[許容例外] {指摘内容} → {許容理由}` の形式で追記し `patterns` に記録する
 4. セッションファイルの `- [ ] security-review` を `- [x]` に Edit する。続けて **「引き継ぎバックログの照合」**（後述の共通ステップ）を実行してからコミットを提案する。
-5. **F-005 結果記録**: 全許容で完了するのも「成功」としてカウント:
+5. **tier-routing 結果記録**: 全許容で完了するのも「成功」としてカウント:
    ```bash
    python .claude/hooks/record_tier_outcome.py --outcome success
    ```
@@ -571,13 +571,13 @@ AskUserQuestion で許容理由を確認する:
 **「否認・再診断を依頼する」の場合:**
 追加の AskUserQuestion でフィードバックを確認し再実行する。
 セッションファイルの `## 試みたが失敗したアプローチ` に教訓をルール形式で追記し `patterns` に追加する。
-**F-005 結果記録**: 否認は「失敗」としてカウント:
+**tier-routing 結果記録**: 否認は「失敗」としてカウント:
 ```bash
 python .claude/hooks/record_tier_outcome.py --outcome failure
 ```
 
 **「全て対応する」「対応する指摘を選ぶ」の場合（フェーズ C へ戻る）:**
-これらも tier の選択がコスト最適でなかったとみなし、**F-005 結果記録**で失敗をカウントしてからフェーズ C へ:
+これらも tier の選択がコスト最適でなかったとみなし、**tier-routing 結果記録**で失敗をカウントしてからフェーズ C へ:
 ```bash
 python .claude/hooks/record_tier_outcome.py --outcome failure
 ```

{claude_code_conductor-2.2.0 → claude_code_conductor-2.3.0}/.claude/skills/develop/SKILL.md

@@ -13,10 +13,3 @@ plan-report に基づいて実装フェーズを実行する。
 3. `.claude/skills/dev-workflow/SKILL.md` の AskUserQuestion・Edit・セッションファイル更新の手順を省略しない
 4. D-0 で plan-report に YAML フロントマター（`po_plan_version`）が検出された場合は、続けて **必ず** `.claude/skills/parallel-agents/SKILL.md` を Read してその手順に従う（親 Claude の Agent ツール並列起動 + 公式 `isolation:worktree`）
 5. フロントマターが無い場合は legacy の D-1〜D-5 ceremony（tester→developer→tester の TDD 逐次実行）にフォールバックする
-
-## 移行注意（v1.12.0+）
-
-- 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.2.0 → claude_code_conductor-2.3.0}/.claude/skills/init-session/SKILL.md

@@ -31,12 +31,12 @@ Glob で `.claude/memory/sessions/*.tmp` を検索し、ファイル名（YYYYMM
    ```bash
    git log --since='{前回 SESSION の YYYYMMDD を YYYY-MM-DD 形式に変換}' --oneline
    ```
-3. 各 `- [ ]` 行に含まれる識別キーワード（`F-XXX` / `Phase X` / 機能名 / 「Zenn」「リリース」などの名詞）が、いずれかのコミットメッセージに含まれているかをキーワード照合する
+3. 各 `- [ ]` 行に含まれる識別キーワード（機能名 / `Phase X` / 「Zenn」「リリース」などの名詞）が、いずれかのコミットメッセージに含まれているかをキーワード照合する
 4. 該当があれば「**完了している可能性のあるタスク**」として Step 3 のサマリに加える（コミットハッシュも併記する）
 5. **自動で `[x]` 化はしない**。Step 4 のあとで AskUserQuestion を提示し、ユーザー承認した項目のみ Edit で `[x]` 化する
 6. 該当なし、または前回セッションが当日の場合はこの Step をスキップする
 
-> 目的: 「F-004 Phase 2 → v1.3.0 完了」のように、リリースで完了したのに `[ ]` のまま残った引き継ぎタスクを次セッション開始時に検出する。
+> 目的: 「memory-consolidation Phase 2 → v1.3.0 完了」のように、リリースで完了したのに `[ ]` のまま残った引き継ぎタスクを次セッション開始時に検出する。
 
 ---
 
@@ -135,7 +135,7 @@ session ファイルはタスク完了のたびに更新する。まとめて最
 
 - **A. ワークフローフェーズ項目**（例: `- [ ] ヒアリング` / `- [ ] 設計` / `- [ ] tester: Red フェーズ`）
   - 各スキル（dev-workflow など）が承認直後に Edit で `[x]` 化する。タイミングは各 SKILL.md に明記されている
-- **B. 引き継ぎバックログ項目**（例: `- [ ] F-XXX Phase X` / `- [ ] Zenn 記事化`）
+- **B. 引き継ぎバックログ項目**（例: `- [ ] {機能名} Phase X` / `- [ ] Zenn 記事化`）
   - セッションを跨ぐ高レベルタスク。以下のタイミングで必ず照合・更新する:
     - **セッション開始時**: init-session Step 1.5 で git log と照合
     - **リリース・大きな完了の節目**: dev-workflow フェーズ E の最終承認時にバックログ確認 AskUserQuestion で更新

{claude_code_conductor-2.2.0 → claude_code_conductor-2.3.0}/.claude/skills/parallel-agents/SKILL.md

@@ -30,7 +30,7 @@ Claude Code のサブエージェントは **更にサブエージェントを s
 並列実行で permission プロンプトに詰まらないよう、v2.2.0 から **worktree 専用の `wt_*` プレフィックス agent** を導入した:
 
 - `wt_tester` / `wt_developer` / `wt_systematic-debugger`: frontmatter に `permissionMode: bypassPermissions` を持つ並列専用バリアント
-- 内容はオリジナルの `tester` / `developer` / `systematic-debugger` と同一
+- 本体ロジックはオリジナルの `tester` / `developer` / `systematic-debugger` と同等。差分はレポート出力のファイル名規約のみで、並列専用 agent は `test-report-{task_id}.md` / `debug-needed-{task_id}.md` / `debug-analysis-{task_id}.md` を主経路とする（タイムスタンプ形式は task_id 不在時の保険）
 - worktree 内のみで動作するため、`worktree_guard.py` (PreToolUse, `PO_WORKTREE_GUARD=1`) が worktree 外への書き込みをブロックする保護下にある
 
 直接起動経路（worktree なし）では元の agent を使い、main リポジトリでの bypass を防ぐ。
@@ -165,7 +165,8 @@ AskUserQuestion ツール:
     ```
     」
   - **tester タスクの場合の追加注入**: 「`.claude/reports/test-report-{task_id}.md` を Write し、writes 宣言と一致させること」
-  - **developer タスクの場合の追加注入**: 「`.claude/reports/debug-needed-*.md` 出力で Stuck Signal を返してよい。systematic-debugger は親 Claude が後続 wave で呼ぶ」
+  - **developer タスクの場合の追加注入**: 「Stuck Signal を返す場合は `.claude/reports/debug-needed-{task_id}.md` を Write する（task_id を含めることで親 Claude が後続 wave で systematic-debugger を呼ぶ際に対象 task を特定できる）。systematic-debugger は親 Claude が後続 wave で呼ぶ」
+  - **systematic-debugger タスクの場合の追加注入**: 「`.claude/reports/debug-analysis-{task_id}.md` を Write し、writes 宣言と一致させること」
 
 全タスクを 1 メッセージ内で発行したあと、各 Agent の完了通知が `<task-notification>` で順次届く。全件揃うまで待つ。
 
@@ -276,13 +277,3 @@ checkpoint の summary には KEEP ルール（設計判断・決定事項・解
 - agent ツール並列起動の `<task-notification>` の到着順序は保証されないため、結果集約の表は task_id でソートして提示する
 - worktree クリーンアップを忘れると `.claude/worktrees/` に dead worktree が積もる。`-f -f` フラグの必要性は PoC で実証済み
 
----
-
-## PO 廃止移行期の注意（v1.12.0〜v2.2.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 非依存）に切り替えた
-- v2.0.0 で `parallel_orchestra` パッケージ本体を削除（互換破壊）
-- v2.1.0 で `tdd-develop` agent と `worktree-tdd-workflow` skill を削除し、planner が 3-wave に分解する設計に統一
-- **v2.2.0 で並列 worktree 専用の `wt_*` プレフィックス agent (`wt_tester` / `wt_developer` / `wt_systematic-debugger`) を導入。frontmatter `permissionMode: bypassPermissions` で permission プロンプトをスキップ。直接起動経路では元 agent を維持して main の bypass を防ぐ**

{claude_code_conductor-2.2.0 → claude_code_conductor-2.3.0}/.gitignore

@@ -15,9 +15,6 @@
 # Agent-individual memory (personal, populated at runtime)
 .claude/agent-memory/
 
-# Workflow test sandbox (not for distribution)
-examples/
-
 # Temporary files
 .claude/tmp/