claude-code-conductor 2.62.0__tar.gz → 2.64.0__tar.gz

{claude_code_conductor-2.62.0 → claude_code_conductor-2.64.0}/.claude/agents/architect.md

@@ -35,12 +35,14 @@ requirements-report を受け取り、システム設計・技術選定・依存
 
 **Before:**
 - requirements-report を Read する
-- 既存コードがあれば Glob / Grep で構造を把握する
+- 採用する対策・パターンと同種の対策が過去に破られていないか、reviewer 系の agent-memory を確認する（agent-memory は gitignored でありディレクトリ横断の検索は空振りする。対象ファイルを列挙してから個別に読む）
 
 **During:**
 - 技術選定の根拠とトレードオフを必ず記録する
 - 複数案がある場合は比較表を作り採用理由を明示する
 - 不明点はユーザーに確認する
+- 対策・不変則は判定手段でなく満たすべき性質で書く（手段の固定は射程を縮める）
+- 対策・規約の配置先を決めるときは `.claude/skills/dev-workflow/references/reachability-map.md` で読み手に届くかを確認する
 
 **After:**
 - Skill ツールで `report-timestamp` を呼び出してタイムスタンプを取得し、Write ツールで `.claude/reports/architecture-report-{timestamp}.md` に出力する

{claude_code_conductor-2.62.0 → claude_code_conductor-2.64.0}/.claude/agents/developer.md

@@ -43,7 +43,6 @@ plan-report に基づき実装・デバッグ・リファクタリングを行
 
 **Before:**
 - plan-report を Read して実装対象タスクを確認する
-- 既存コードを Glob / Grep で把握する
 
 **During:**
 - 1タスク = 1コミットの粒度を保つ

{claude_code_conductor-2.62.0 → claude_code_conductor-2.64.0}/.claude/agents/doc-writer.md

@@ -36,7 +36,6 @@ tools:
 
 **Before:**
 - プロンプトに含まれる要件（種類・読み手・目的・粒度・対象・出力先）を確認する
-- Glob / Grep で対象ファイル・ディレクトリの構造を把握する
 - Read で関連ファイルを読み込む（大規模な場合は優先度の高いファイルから）
 
 **During:**

{claude_code_conductor-2.62.0 → claude_code_conductor-2.64.0}/.claude/agents/planner.md

@@ -41,7 +41,7 @@ requirements-report・architecture-report・各種レビューレポートを統
 **During:**
 - レビュー指摘がある場合は優先度を付けて反映する
 - タスクは「1タスク = 1コミット」の粒度を意識して分解する
-- `.claude/skills/dev-workflow/references/plan-design-guidelines.md` のルール 1〜15 と R2〜R6 を遵守する（適用射程は同ファイル冒頭の分類表に従う。`"sequential"` プランでは並列前提ルールを適用しない）
+- `.claude/skills/dev-workflow/references/plan-design-guidelines.md` のルール 1〜20 と R2〜R6 を遵守する（適用射程は同ファイル冒頭の分類表に従う。`"sequential"` プランでは並列前提ルールを適用しない）
 
 **After:**
 - Skill ツールで `report-timestamp` を呼び出してタイムスタンプを取得し、Write ツールで `.claude/reports/plan-report-{timestamp}.md` に出力する
@@ -58,7 +58,7 @@ requirements-report・architecture-report・各種レビューレポートを統
 制限:
 - ソースファイルの編集・書き込みは行わない
 - plan-report の YAML フロントマター内で `tasks[].id` の重複・未定義の `depends_on` 参照・エージェント名の typo を出力しない（`c3 plan validate` で検証可能）
-- `.claude/skills/dev-workflow/references/plan-design-guidelines.md` のルール 1〜15 と自己チェックリストに違反した plan-report を出力しない（適用射程は分類表に従う）
+- `.claude/skills/dev-workflow/references/plan-design-guidelines.md` のルール 1〜20 と自己チェックリストに違反した plan-report を出力しない（適用射程は分類表に従う）
 - 自動検査対象に違反する plan-report を出力しない:
   - R2/R4/R6（配布対象）: `.claude/hooks/planner_check.py` が PostToolUse で WARN を出す
   - R3（C3 固有）: `.dev/hooks/_planner_check.py` が PostToolUse で exit 2 ブロック

{claude_code_conductor-2.62.0 → claude_code_conductor-2.64.0}/.claude/agents/security-reviewer.md

@@ -41,7 +41,6 @@ SQLインジェクション・XSS・認証認可・秘密情報漏洩などの
 ## Workflow
 
 **Before:**
-- 変更ファイルと依存関係を Bash / Glob / Grep で確認する
 - 認証・外部入力・データベースアクセスのコードを優先的に確認する
 - `.claude/skills/dev-workflow/references/security-review-checklist.md` を Read してチェック観点を確認する
 

{claude_code_conductor-2.62.0 → claude_code_conductor-2.64.0}/.claude/agents/systematic-debugger.md

@@ -63,13 +63,11 @@ developer が詰まった問題の根本原因を調査し、debug-analysis-repo
 - エラーに関連する変更がないか調べる
 
 **2-4: 関連コードの読み込み**
-- Glob / Grep / Read でエラー箇所周辺のコードを調査する
 - 依存関係・呼び出し元を辿る
 
 ### Step 3: Phase 2 - パターン分析
 
 **3-1: 動いている類似コードを探す**
-- Grep / Glob で同様のパターンを実装している箇所を探す
 - 動いているコードと壊れているコードの両方を Read する
 
 **3-2: 差分の特定**
@@ -107,7 +105,7 @@ Skill ツールで `report-timestamp` を呼び出してタイムスタンプを
 ```
 
 ## Tools & Constraints
-- コードを修正・編集しない（Read / Bash / Glob / Grep / Write のみ使用）
+- コードを修正・編集しない（`memory:` 付き agent には Edit が実行時に自動付与されるため、frontmatter ではなく本規約が唯一の担保）
 - 推測で原因を断言しない。再現コマンドの出力など証拠に基づいて記述する
 - 推奨仮説は1つに絞る（複数の仮説を羅列しない）
 

{claude_code_conductor-2.62.0 → claude_code_conductor-2.64.0}/.claude/agents/wt_developer.md

@@ -17,7 +17,7 @@ tools:
 
 # Developer (worktree-parallel)
 
-> **v2.2.0+**: 本 agent は `parallel-agents` skill が `isolation: "worktree"` 付きで起動する **並列実行専用** バリアント。`permissionMode: bypassPermissions` により worktree 内で permission プロンプトをスキップする。worktree 外への書き込みは `.claude/hooks/worktree_guard.py` (PreToolUse, `PO_WORKTREE_GUARD=1`) でガードされる。
+> 本 agent は `parallel-agents` skill が `isolation: "worktree"` 付きで起動する **並列実行専用** バリアント。`permissionMode: bypassPermissions` により worktree 内で permission プロンプトをスキップする。worktree 外への書き込みは `.claude/hooks/worktree_guard.py` (PreToolUse, `PO_WORKTREE_GUARD=1`) でガードされる。
 >
 > 単発起動（`/develop` フェーズ D-1〜D-5 等、`isolation` なし）では本 agent を**使わない**。元の `developer` agent を使うこと。
 
@@ -48,7 +48,6 @@ plan-report に基づき実装・デバッグ・リファクタリングを行
 
 **Before:**
 - plan-report を Read して実装対象タスクを確認する
-- 既存コードを Glob / Grep で把握する
 
 **During:**
 - 1タスク = 1コミットの粒度を保つ

{claude_code_conductor-2.62.0 → claude_code_conductor-2.64.0}/.claude/agents/wt_systematic-debugger.md

@@ -15,7 +15,7 @@ tools:
 
 # Systematic Debugger (worktree-parallel)
 
-> **v2.2.0+**: 本 agent は `parallel-agents` skill が `isolation: "worktree"` 付きで起動する **並列実行専用** バリアント。`permissionMode: bypassPermissions` により worktree 内で permission プロンプトをスキップする。worktree 外への書き込みは `.claude/hooks/worktree_guard.py` (PreToolUse, `PO_WORKTREE_GUARD=1`) でガードされる。
+> 本 agent は `parallel-agents` skill が `isolation: "worktree"` 付きで起動する **並列実行専用** バリアント。`permissionMode: bypassPermissions` により worktree 内で permission プロンプトをスキップする。worktree 外への書き込みは `.claude/hooks/worktree_guard.py` (PreToolUse, `PO_WORKTREE_GUARD=1`) でガードされる。
 >
 > 単発起動（worktree なしで親 Claude から直接 Agent ツールで起動するケース等）では本 agent を**使わない**。元の `systematic-debugger` agent を使うこと。
 
@@ -68,13 +68,11 @@ developer が詰まった問題の根本原因を調査し、debug-analysis-repo
 - エラーに関連する変更がないか調べる
 
 **2-4: 関連コードの読み込み**
-- Glob / Grep / Read でエラー箇所周辺のコードを調査する
 - 依存関係・呼び出し元を辿る
 
 ### Step 3: Phase 2 - パターン分析
 
 **3-1: 動いている類似コードを探す**
-- Grep / Glob で同様のパターンを実装している箇所を探す
 - 動いているコードと壊れているコードの両方を Read する
 
 **3-2: 差分の特定**
@@ -112,7 +110,7 @@ developer が詰まった問題の根本原因を調査し、debug-analysis-repo
 ```
 
 ## Tools & Constraints
-- コードを修正・編集しない（Read / Bash / Glob / Grep / Write のみ使用）
+- コードを修正・編集しない（`memory:` 付き agent には Edit が実行時に自動付与されるため、frontmatter ではなく本規約が唯一の担保）
 - 推測で原因を断言しない。再現コマンドの出力など証拠に基づいて記述する
 - 推奨仮説は1つに絞る（複数の仮説を羅列しない）
 

{claude_code_conductor-2.62.0 → claude_code_conductor-2.64.0}/.claude/agents/wt_tester.md

@@ -15,7 +15,7 @@ tools:
 
 # Tester (worktree-parallel)
 
-> **v2.2.0+**: 本 agent は `parallel-agents` skill が `isolation: "worktree"` 付きで起動する **並列実行専用** バリアント。`permissionMode: bypassPermissions` により worktree 内で permission プロンプトをスキップする。worktree 外への書き込みは `.claude/hooks/worktree_guard.py` (PreToolUse, `PO_WORKTREE_GUARD=1`) でガードされる。
+> 本 agent は `parallel-agents` skill が `isolation: "worktree"` 付きで起動する **並列実行専用** バリアント。`permissionMode: bypassPermissions` により worktree 内で permission プロンプトをスキップする。worktree 外への書き込みは `.claude/hooks/worktree_guard.py` (PreToolUse, `PO_WORKTREE_GUARD=1`) でガードされる。
 >
 > 単発起動（`/develop` フェーズ D-1〜D-5 等、`isolation` なし）では本 agent を**使わない**。元の `tester` agent を使うこと。
 

{claude_code_conductor-2.62.0 → claude_code_conductor-2.64.0}/.claude/docs/config-policy.md

@@ -422,6 +422,34 @@ Claude Code 側で `deny` 判定が出た後に発火するため、`permission_
 定期的にレビューすること（`c3 run <固定スクリプトパス>` 形式のみを許可し、`../` を含みうる可変パスを
 プレフィックス許可しない）。
 
+**追記（SR-AI-001）: 破壊操作を伴うスクリプトは追記系と同列に扱わない**
+
+上記のプレフィックス一致という性質は、許可対象のスクリプトが**何をするか**によって危険度が変わる。
+`c3 run <script>*` の末尾ワイルドカード 1 本は、そのスクリプトが取りうる**あらゆる引数列**を
+無確認で許可する。追記系スクリプト（記録・注入・インデックス更新）ならこれで実害は限定的だが、
+**ファイルの移動・削除・上書きを行うスクリプトでは、引数 1 つで対象ディレクトリごと差し替えられる**。
+実例: `archive_reports.py` は `--reports-dir <任意ディレクトリ>` を取り、その直下の `*.md` を
+移動して移動元を削除する。末尾ワイルドカードで allow すると、プロンプトインジェクション経由で
+任意ディレクトリの `*.md` が無確認で移動・削除されうる。
+
+**対処**（新しい allow を追加する際・レビューで拾う際のチェック）:
+- そのスクリプトが破壊操作（削除・移動・上書き）を伴うかをまず判定する
+- 伴う場合、allow は**正規経路が実際に使う形だけ**に絞る（引数なしの完全一致 + 正規のオプションで
+  始まる形）。末尾ワイルドカード 1 本にしない
+- allow の絞り込みだけでは足りない場合がある。`<script> --opt *` 形のパターンは、後続に別の
+  オプションが続く文字列とも前方一致しうるため、**危険な引数自体に env ゲートを課す**
+  （例: `archive_reports.py` の `--reports-dir` は `C3_ARCHIVE_REPORTS_DIR_OK=1` がある場合のみ有効）。
+  env は allow パターンの前方一致では満たせないため、単一のコマンド文字列では越えられない関所になる
+
+**追記（SR-NEW-2）: env ゲートの射程は単一コマンド文字列に対する関所であり、セッション跨ぎの env 継承は射程外**
+
+上記の env ゲート（例: `C3_ARCHIVE_REPORTS_DIR_OK=1`）が防いでいるのは「1 本の許可済みコマンド文字列の
+前方一致だけでは越えられない」という点であり、**シェルセッションを跨いだ環境変数の永続化・継承は
+別の話**である。`export C3_ARCHIVE_REPORTS_DIR_OK=1` を `.bashrc` 等の起動ファイルに書く・
+CI のジョブ環境変数として設定する・親プロセスから子プロセスへ継承させる、といった経路で
+ゲートが「常時開いた状態」になれば、env ゲート自体は無力化される。ゲートは「未設定が既定」
+という運用を前提にした関所であり、恒久的な env 設定と組み合わせて使わないこと。
+
 ---
 
 ## 8. 参照先

{claude_code_conductor-2.62.0 → claude_code_conductor-2.64.0}/.claude/settings.json

@@ -13,6 +13,8 @@
       "Bash(c3 run .claude/skills/dev-workflow/scripts/record_review_decision.py*)",
       "Bash(c3 run .claude/skills/dev-workflow/scripts/record_agent_outcome.py*)",
       "Bash(c3 run .claude/skills/init-session/scripts/session_guard.py*)",
+      "Bash(c3 run .claude/skills/start/scripts/archive_reports.py)",
+      "Bash(c3 run .claude/skills/start/scripts/archive_reports.py --phase *)",
       "Read(**)",
       "Grep(**)",
       "Edit(.claude/reports/**)",

{claude_code_conductor-2.62.0 → claude_code_conductor-2.64.0}/.claude/skills/dev-workflow/SKILL.md

@@ -80,7 +80,7 @@ session.tmp の `モード:` 行を確認する。**有効な自律宣言**（§
 
 ### A-1〜A-3: 動的ヒアリング（ルーブリック型）
 
-**最初に必ず** `.claude/skills/dev-workflow/references/interview-rubric.md` を Read する（記憶・推測で進めない）。
+`.claude/skills/dev-workflow/references/interview-rubric.md` を Read する。
 その指針に従い、床 5 観点（①背景・目的 ②スコープ境界 ③制約・前提 ④非機能要件 ⑤成功条件）を
 **動的にヒアリング**する。要点:
 
@@ -147,7 +147,7 @@ c3 run .claude/skills/dev-workflow/scripts/record_agent_outcome.py \
 
 ### B-1〜B-2: 動的設計確認（ルーブリック型）
 
-**最初に必ず** `.claude/skills/dev-workflow/references/design-rubric.md` を Read する（記憶・推測で進めない）。
+`.claude/skills/dev-workflow/references/design-rubric.md` を Read する。
 その指針に従い、床 4 観点（①技術スタック制約 ②要件から導く設計判断ポイント ③非機能の実現方針 ④トレードオフ分岐）を
 **動的に確認**する。要点:
 
@@ -570,7 +570,7 @@ c3 run .claude/skills/dev-workflow/scripts/record_agent_outcome.py \
 3. plan-report も当日 debug-analysis も存在しない場合はフェーズ C から始めるよう案内して終了する。
 
 **`po_plan_version: "0.1"` の場合（parallel-agents モード）:**
-1. **最初に必ず** `.claude/skills/parallel-agents/SKILL.md` を Read する（記憶・推測で進めない）
+1. `.claude/skills/parallel-agents/SKILL.md` を Read する
 2. `.claude/skills/parallel-agents/SKILL.md` の手順に完全に従って wave 単位で実装を進める
 3. 全 wave 完了後はフェーズ E（レビュー）へ進む（wave に reviewer タスクが含まれていれば E をスキップ可能と案内する）
 
@@ -973,6 +973,8 @@ c3 run .claude/skills/dev-workflow/scripts/record_agent_outcome.py \
 ```
 
 **指摘がある場合:**
+対応の置き場所（どの文書・どの層に対策を置くか）を決める際は `.claude/skills/dev-workflow/references/reachability-map.md` で読み手に届くかを確認する。
+
 指摘一覧をテキストで提示してから AskUserQuestion で方針を確認する:
 ```json
 {
@@ -1114,6 +1116,8 @@ c3 run .claude/skills/dev-workflow/scripts/record_agent_outcome.py \
 ```
 
 **指摘がある場合:**
+対応の置き場所（どの文書・どの層に対策を置くか）を決める際は `.claude/skills/dev-workflow/references/reachability-map.md` で読み手に届くかを確認する。
+
 指摘一覧をテキストで提示してから AskUserQuestion で方針を確認する:
 ```json
 {

{claude_code_conductor-2.62.0 → claude_code_conductor-2.64.0}/.claude/skills/dev-workflow/references/plan-design-guidelines.md

@@ -5,7 +5,7 @@
 | 分類 | ルール番号 | R 番号 | 自己チェックリスト項目 |
 |---|---|---|---|
 | `"0.1"`（並列実行）限定 | ルール 1・2・10・11・14／ルール 3・9（※直後の注記により sequential でも成果物宣言・レビュー配置の規律は満たすこと） | R5（isolation 指定が発生しない逐次では非該当） | チェーン長／同一ファイル衝突／R5／ルール 14 |
-| 両モード共通 | ルール 4・5・7・8・12・13・15 | R2・R3・R4・R6（planner_check hook 群は po_plan_version の値を読まないため sequential プランでも発火する） | id 一意・depends_on 参照先実在／空配列禁止／TDD 3 タスク分解／15 分粒度／R6／writes が空のタスク／レビュータスクの depends_on／ルール 15 方向検算 |
+| 両モード共通 | ルール 4・5・7・8・12・13・15・16・17・18・19・20 | R2・R3・R4・R6（planner_check hook 群は po_plan_version の値を読まないため sequential プランでも発火する） | id 一意・depends_on 参照先実在／空配列禁止／TDD 3 タスク分解／15 分粒度／R6／writes が空のタスク／レビュータスクの depends_on／ルール 15 方向検算／テスト凍結の実装責任／手順過多の契約化／一時改変の後始末方法／検知力検証の双方向／gitignored 検証パス |
 | 逐次では読み替え | ルール 6（Stuck Signal の契約自体は共通。wave 失敗時の 2-E 吸収は並列限定の運用であり、逐次は dev-workflow SKILL.md の D-2.5〈Stuck チェック〉で吸収する） | - | - |
 
 **注記**: 両モード共通に分類されたルール（5・R2・R4・R6 等）が `writes` や reviewer タスクの存在を前提とする場合、**その前提を作るルール（9・3）も sequential プランで満たすこと**。`"0.1"` 限定の趣旨は『並列度・worktree 取り込み衝突に関する制約』に限られ、成果物宣言・レビュー配置の規律はモードを問わない。
@@ -13,6 +13,8 @@
 planner agent が本ファイルを参照する。
 plan-report 生成時はこれを確実に読んでから出力すること（D-012 準拠）。
 
+規約・対策の配置先を決めるときは `reachability-map.md` で読み手に届くかを確認する。
+
 ---
 
 ## depends_on の付け方
@@ -129,6 +131,26 @@ Stage 1: dev_a, dev_b, dev_c (並列)
 
 **静的検査の保証範囲**: 本ルールの静的検査（`tests/skills/test_planner_lightweight.py`）が保証するのは**この規約文書にルール 15 が存在すること**のみであり、個々の plan-report が本ルールに従っているかは検査しない。方向が合っているかの判定は planner の責任に残る。
 
+## 凍結仕様の実装責任（ルール 16）
+
+16. **テスト前提の実装責任** — 計画が既存テストの凍結を前提とする場合（件数リテラル・逐語アンカー・特定テストケースの存在仮定など）、その仮定を変更する修正は **当該テストファイルを `writes` に含むタスク** で行うこと。修正担当を明示することにより、前提が破られたときの責任の所在を確定させる。
+
+## タスク prompt の設計方針（ルール 17）
+
+17. **契約と性質で指示し、手順で指定しない** — `tasks[].prompt` には契約・不変則・測るべき性質を書く。逐語的な手順指定は避けること。実施主体が判断を失い、手順の逐語に従うだけになると別の欠陥を生じやすい。実測: C-3 監査で High 5 件中 3 件が親による逐語手順の誤りが原因だった（2026-07-23）。
+
+## 一時改変の後始末指定（ルール 18）
+
+18. **cleanup 手段を明示・禁止経路を宣言する** — 検証のための一時改変（テストの一時ハード・mock 削除・debug logging など）を指示する場合、**後始末の手段を逐語で指定し、 `git checkout` / `git restore` / `git reset` を明示的に禁止すること**。これらは復元不能な失敗を招く（実績: 2026-08-01 に実装 5 時間分が全損）。代わりに「元のコードへ戻す」「テストスケルトンを削除」など、失敗時に検出可能な方法を指示すること。
+
+## 検知力検証の双方向テスト（ルール 19）
+
+19. **do-nothing スタブの両方向赤緑反転** — 検証系タスクの contract に「検知力を実証する」を含める場合、do-nothing スタブ **2 種**（always-False / always-True）を用いて赤緑が完全に入れ替わることを示すこと。単一スタブでは正の双子が赤にならない原理的限界を越えられない。適用困難な対象では、代替手段として「両方向反転」の実現可能性を明記する。
+
+## gitignored 成果物の検証経路（ルール 20）
+
+20. **直接 Read・状態外の指示分離** — gitignored ファイル（`.claude/reports/` 等）の検証は `git status --short` ではなく **直接 Read で行うこと**。git 管理下で成果物を検証する必要があれば、明示的に commit → 確認 → cleanup の流れを指示する。worktree で起動される worker（developer / tester）の prompt には gitignored 文書の Read を指示しないこと（届く経路が無い。親か plan-report 経由で指す）。reviewer 向けの prompt には「当該ファイルは gitignored である」と明記し、reviewer に直接 Read させることを指示する。
+
 ---
 
 ## 出力直前の自己チェックリスト
@@ -147,6 +169,11 @@ plan-report を Write する前に以下を必ず確認する:
 - [ ] R6: タスク総数 3 件以上なら reviewer 系タスクが 1 件以上含まれているか
 - [ ] ルール 14: writes が全て gitignored のタスク（confirm- 等）は運用層で main 直接経路に読み替えられることを認識しているか
 - [ ] ルール 15: finding 反映時に方向検算表を含めたか（Critical/High/Medium 必須）
+- [ ] ルール 16: テスト凍結仮定を変更する修正は当該テストファイルを writes に含む task で行うか明示されているか
+- [ ] ルール 17: tasks[].prompt は逐語手順でなく契約・不変則・測るべき性質で書かれているか
+- [ ] ルール 18: 一時改変指示は後始末手段を逐語で指定し、git checkout/restore/reset を明示的に禁止しているか
+- [ ] ルール 19: 検証系 task の contract に do-nothing スタブ 2 種の赤緑反転実証が含まれているか（適用困難なら代替宣言）
+- [ ] ルール 20: gitignored 成果物検証は直接 Read 指示で行い、worker prompt には Read を指示していないか
 
 ---
 

claude_code_conductor-2.64.0/.claude/skills/dev-workflow/references/reachability-map.md

@@ -0,0 +1,38 @@
+# 到達可能性マップ
+
+規約・対策をどこに置けば読み手に届くか。対象読み手ごとに、有効な配置先を表引きで示す。
+
+## 到達経路一覧
+
+表の列構成: 経路（配置方法）、実パス（ファイルパスまたは「—」）、届く role（対象読み手）、条件（前提・性質）
+
+| 経路 | 実パス | 届く role | 条件 |
+|---|---|---|---|
+| .claude/CLAUDE.md | .claude/CLAUDE.md | 全 role | 自動ロード・常駐コスト有。全員に効かせたい安全境界のみ置く |
+| .claude/rules/ (再帰自動ロード) | — | 全 role | 再帰自動ロード。サブエージェント含む。`.claude/rules/` 配下のサブディレクトリも対象 |
+| agents/<role>.md 本文 | — | 当該 role のみ | サブエージェント起動時に frontmatter とともに載る。persona 実行 role（interviewer/architect/planner）へは dev-workflow SKILL.md 各フェーズ冒頭の Read 指示に依存して親経由で届く |
+| dev-workflow/SKILL.md | .claude/skills/dev-workflow/SKILL.md | 親 Claude のみ | worker（developer/tester）には届かない。フェーズ遷移・承認ゲートの定義・手順 |
+| references/*.md (導線経由) | — | 導線を持つ role のみ | 導線が無ければ誰にも届かない。SKILL.md 各フェーズから Read 指示で参照される |
+| plan-report タスク prompt | — | 当該タスクの worker のみ | worker へ届く唯一の動的経路。planner が転記した内容のみ有効 |
+| 起動プロンプト（E-0 等） | — | 起動された agent のみ | E-0 の枠付けが正例。データ/指示の明確な区分 |
+| agent-memory/<role>/ | — | 当該 role（Before に Read 指示を持つ role のみ） | gitignored: worktree に存在せず、ディレクトリ横断検索は空振りする。ファイルを列挙して個別に Read。上流（architect）には既定では届かない（architect.md の Before が能動的な確認を指示して補完する） |
+| design-critic-rubric.md | .claude/skills/dev-workflow/references/design-critic-rubric.md | design-critic（C-3 ステップ 2） | C-3 設計監査ゲート内で Read 指示される |
+| interview-rubric.md | .claude/skills/dev-workflow/references/interview-rubric.md | interviewer（A-1〜A-3） | フェーズ A 冒頭で Read 指示される |
+| design-rubric.md | .claude/skills/dev-workflow/references/design-rubric.md | architect（B-1〜B-2） | フェーズ B 冒頭で Read 指示される |
+| plan-design-guidelines.md | .claude/skills/dev-workflow/references/plan-design-guidelines.md | planner（C-2） | フェーズ C 計画作成時に参照・守るべき規約 |
+
+## 置き場所デシジョン（3 手順）
+
+**① 対象読み手を決める**
+恒久規約・対策の対象読み手は誰か。例: developer のみ、全 role、特定フェーズの worker、など。
+
+**② 表で経路を引く**
+上記の表から対象読み手に届く経路を探す。複数経路がある場合は「コスト」と「確実性」で選ぶ。
+- 常駐コスト（CLAUDE.md 肥大化）vs. 導線による確実性（参照側の負担）
+- 安全境界（コミット・削除・権限）はより上流（CLAUDE.md / rules/）に置く
+
+**③ 経路が無ければ agent 本文か plan 契約に置く**
+表を見ても対象読み手に届く経路が無い場合（例: worker 向け恒久規約、developer のみ向けのパターン）は、以下を選ぶ:
+- 多くの worker が参照するなら plan-report の task prompt に書く（動的経路）
+- 特定フェーズ限定なら agent.md 本文に書く
+- サブエージェント（design-critic など）の動作規約なら agent 本文か SKILL.md の起動フェーズに書く

{claude_code_conductor-2.62.0 → claude_code_conductor-2.64.0}/.claude/skills/parallel-agents/SKILL.md

@@ -140,6 +140,8 @@ plan-report 承認時点で全タスク・agent・writes・prompt が確認済
 
 ### 2-C: タスクを実行する（並列起動）
 
+wave を起動する前に `git status` が空（未コミット変更なし）であることを確認する（未コミット変更は worktree に届かない。2-F-2 の取り込み後確認とは別の**起動前**チェック）
+
 並列化可能タスクを **1 ターン内で複数 Agent ツール呼び出し** として発行する。並列度の上限は **デフォルト 5、上限 15**（PoC で検証済み）。タスク数がそれ以上なら 5 件ずつのバッチに分割する。
 
 **重要**: 各タスクの `agent` 名は plan-report で `tester` / `developer` 等と書かれているが、**Agent ツール呼び出し時の `subagent_type` には並列専用バリアント (`wt_*`) を指定する**。マッピング表:

{claude_code_conductor-2.62.0 → claude_code_conductor-2.64.0}/.claude/skills/start/SKILL.md

@@ -53,10 +53,14 @@ Glob で `.claude/reports/*.md` を検索する（`archive/` 配下は含まな
 }
 ```
 
+アーカイブは専用スクリプトが行う。このコマンドは、移動先に同名のファイルが既にある場合は
+移動元を `{元の名前}-archived-{元ファイルの更新時刻}.md` へリネームして**両方を残す**（既存ファイルは 1 バイトも変更しない）。
+アーカイブ先ディレクトリが無ければ作成する。移動できなかったファイルがあれば stderr に一覧を出して exit 1 になる。
+
 **「全てアーカイブして新しく始める」の場合:**
 Bash ツールで実行する:
 ```bash
-mkdir -p .claude/reports/archive && mv .claude/reports/*.md .claude/reports/archive/
+c3 run .claude/skills/start/scripts/archive_reports.py
 ```
 
 **「アーカイブするフェーズを選ぶ」の場合:**
@@ -77,11 +81,19 @@ AskUserQuestion で対象フェーズを確認する:
 }
 ```
 
-選択されたフェーズに対応するファイルを Bash ツールで移動する（ファイルが存在しない場合はスキップ）:
-- 要件定義: `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 && mv .claude/reports/design-review-report-*.md .claude/reports/archive/ 2>/dev/null || true`
+選択された各ラベルを次の表で `--phase` の値に読み替え、Bash ツールで 1 回だけ実行する
+（`--phase` は繰り返し指定でき、指定した分の和が対象になる。対象ファイルが 1 件も無くても成功する）:
+
+| 選択肢のラベル | `--phase` の値 | 対象になるファイル |
+|---|---|---|
+| 要件定義 | `requirements` | `requirements-report-*.md` |
+| 設計 | `architecture` | `architecture-report-*.md` |
+| 計画 | `plan` | `plan-report-*.md` |
+| レビュー | `review` | `code-review-report-*.md` / `security-review-report-*.md` / `design-review-report-*.md` |
+
+```bash
+c3 run .claude/skills/start/scripts/archive_reports.py --phase requirements --phase review
+```
 
 ---