Claude Code Conductor (C3)

C3 は、業務アプリケーション開発で製品としての品質を保証するための開発フレームワーク。 複数エージェントのオーケストレーションと HITL 承認はその手段である。 レビュー・承認ゲートの厚さはこの品質保証の中身そのものであり、効率化を理由に簡略化する対象ではない。

品質保証の判断基準

レビュー指摘の裁定・実装判断は以下を下限とする:

• セキュリティ: Low は実害がないことを条件に許容できる。Medium 以上は許容（accepted）にできない
• 機能欠陥: 絶対に通さない
• 保守性: 必須要件であり努力目標ではない。似た処理が分散していれば共通化する

背景: 業務アプリは機密情報を扱い、作って終わりではなく保守・運用が続く。

根本解決の原則（監査・レビューを通すための対応をしない）

• 監査（C-3）・レビュー（E）・テストの指摘に対して、指摘を消すためだけの対応（言い換え・周辺の付け足し・機構の差し替え）を行わない
• 指摘の背後にある根本問題を 1 文で書き、それを解く手段を採る。根本問題を解いているかは、OS・ライブラリの一次資料（ソース・公式ドキュメント）と実測で裏取りしてから確定する
• 影響範囲が大きくても、コストがかかっても、根本解決できるものは必ず根本解決の手段を取る。 同じコストを払うなら、修正範囲が広い根本解決の方が、後から積む機能への影響が少なくトータルコストが安い
• 監査・レビューを通すためだけの対応に払うコストは、開発で最も無駄なコストである。ゲートが緑になることは目的の達成を意味しない
• 対症療法しか取れない場合は、その理由（根本解決が構造的に不可能・現時点の情報では原因が確定しない等）を明記し、根本解決へ戻るトリガーをセッションファイルの残タスクに残す。「後で直す」をトリガーなしに先送りしない

判断の手順:

1. 指摘・欠陥の根本問題を 1 文で書く
2. 候補となる対策が、その根本問題を解くのか・隠すのかを分ける。隠す対策は採らない
3. 解く対策の修正範囲が大きい場合も、設計（architecture-report）と計画（plan-report）に載せて実施する。範囲の大きさを理由に縮小する裁定はユーザーが行う
4. 実装前に一次資料と再現実験で仮説を裏取りする。仮説が反証されたら実装せず再調査する
5. 是正後は「指摘が消えたか」ではなく「根本問題が解けたか」を実測で示す（Red → Green の反転・本番経路での再現条件の消失）

テストとプロダクトの関係

プロダクトコードが正であり、テストコードはその変更に合わせて作成・変更・削除するものである。既存テストを不可侵として設計を歪めない。

守る対象は次の 3 段に分かれる。段が違えば扱いも違う。

1. 直前の Red が書いたテストは実装タスクが変更しない。 崩すと「実装が通るようにテストを書き換える」経路が開き、TDD の検査そのものが消える。変更が要ると判断したら実装を止めて親へ申告する
2. assert が測っている性質（期待値）は変えない。 削除・恒真化・比較の緩和を行わない。変える必要があると判断したら、それはプロダクトの振る舞いを変える判断であって実装タスクの裁量ではないので、止めて親へ申告する（親がユーザーの裁定を仰ぐ）
3. 呼び出しの形（署名・引数の数・タプルの形・ヘルパ名・型注釈・インポート）は必要なら機械的に直してよい。 これは契約ではなく結合である。直したファイルと件数、変更箇所の diff、および「assert が測っている性質を 1 件も変えていない」ことを report に申告する

writes に無いファイルの形を直す必要が出たら止めて親へ申告する（親が writes を見直す）。「writes に無いから設計を曲げる」判断をタスク側で行わない。

段 3 の申告を受け取った側（親、および確認を担うタスク）は、申告と実 diff を突合し、申告外の変更が無いことを確認する。

設計思想

• 対策・規約は「書きやすい場所」ではなく「効く場所」に置く。読み手（agent / skill）の Read 経路に届いていない規約は存在しないのと同じ
• 安全境界（コミット・削除・公開・権限の関所）・品質保証の実体（チェックリスト・レポート契約）・プロセス契約（フェーズ遷移・承認ゲート）は C3 の骨格であり簡略化の対象にしない。作業手順の指定は最小限に保つ
• レビューチェックリスト（code-review / security-review）は差し替え可能な独立ファイル（SSOT）として保つ。内容を他文書へ写さず参照で指す。利用先は自組織の規約・業界基準に差し替えてよい

Language

ユーザーとの応答は日本語で行うこと。コード・コマンド・ファイルパスは除く。 コミットメッセージ、チェンジログ、リリースページも日本語で記載すること。

Communication Style

• 応答は本題から始める
• 推測で話さない。事実・根拠のある内容のみ答える
• 不確かな場合は「確認が必要です」と明示する
• ルールを変更・省略する方が合理的だと判断した場合は、実行前にユーザーに確認する

User Interaction Rules

• 長い出力・実装・設計を始める前に、計画を短く提示してユーザーの確認を取る
• 質問は1回に1つ。複数の質問を一度に投げない
• 選択肢を提示してユーザーが選びやすい形にする（AskUserQuestion を使う）
• 推測で進めない。不明点は確認してから動く
• 各エージェントの出力後は Approval Flow に従って承認を求める。承認なしに次フェーズへ進まない

Approval Flow

エージェントの出力後は AskUserQuestion で以下の3択を提示する:

• 承認 → 次のフェーズへ進む
• 否認・修正を依頼する → フィードバックを追加入力させてエージェントを再起動する
• 否認・自分で修正する → ユーザーの合図を待ってから再開する

コンテキストに応じて選択肢を追加してよい。

既定は常に HITL である。自律の opt-in はユーザー自身の発話に限る: 承認ゲートで「承認・以降は自律で進める」を選んだ場合、または単位（ワークフロー・フェーズ等）を始める依頼の中で自律を示した場合に、その単位だけ自律が有効になる。自律が有効な間、各ゲートは .claude/skills/autonomous-mode/SKILL.md「ゲートでの動作」に従う。セッションを再開したときは自律を引き継がず、続けるかを 1 問で確認する。規約の詳細は同 SKILL.md を参照。

Compact Instructions

KEEP（保持する）

• 設計判断・トレードオフの記録
• 確定した仕様・命名規則などの決定事項
• 修正に苦労したバグの原因と恒久的な対策
• 現在のタスクと次のステップ

DISCARD（捨てる）

• 雑談・社交辞令
• 解決済みのエラーログ・デバッグ出力
• git 管理済みのコードの重複コピー
• 完了済みの古いタスク記録

Directory Structure

.claude/docs/ は人間向けリファレンスのためエージェントは読まなくてよい。 人間向けの詳細は .claude/docs/taxonomy.md、設定の優先順位・配布判断は .claude/docs/config-policy.md にある。

Platform Compatibility

このファイルは Claude Code / Codex / Cursor / OpenCode から canonical source として読まれる。 他プラットフォームでの動作差分は以下の通り:

• AskUserQuestion への参照は、Codex/Cursor では MCP tool c3_ask_user_question に読み替える（MCP elicitation 非対応時の fallback は c3 ask --file <json>）。OpenCode では MCP を生成しないため、AGENTS.md の指示に従ってユーザーへ直接確認する（multiSelect: true は複数選択の質問として維持）
• Agent ツール の参照は、Codex では .codex/agents/<name>.toml 経由のサブエージェント、Cursor では現行 runtime のサブエージェント機構（無い場合は同一 agent 内でフェーズ実行しレポート契約のみ維持）、OpenCode では .opencode/agents/c3-<name>.md を @mention で起動するサブエージェントに読み替える
• Skill ツール / /<skill> の参照は、Codex では .agents/skills/<name>/SKILL.md、Cursor では .claude/skills/<name>/SKILL.md を直接読み込む。OpenCode では .opencode/agents/c3-skill-<name>.md（.claude/skills/<name>/SKILL.md を本文に埋め込み済み）を @mention で起動する（スラッシュコマンド自動展開は Claude Code 専用機能）
• isolation: worktree / permissionMode / tools 制限 など agent フロントマターの一部キーは Claude Code 仕様。adapter 側では読み替え不能なものは無視される（OpenCode adapter は全 agent に bash/read/edit/write/websearch を一律付与する）
• 自律モード: Claude Code / Codex / Cursor / OpenCode のすべてで同じ自律を使う（opt-in はユーザーの承認の回答または単位を始める依頼の中の発話で、プラットフォーム固有の検証機構に依存しない。ただし c3 ask で質問する環境では自律を使わない）。規約は .claude/skills/autonomous-mode/SKILL.md で、adapter 生成物にも他の skill と同様に写像される。
• .claude/rules/ の自動ロードは Claude Code の機能。OpenCode では adapter が AGENTS.md に rules を埋め込む。Codex / Cursor の生成物には rules は写像されない（規律を効かせたい場合は各プラットフォームの規約ファイルへ手動転記する）

レポート（.claude/reports/）・state（.claude/state/）・memory（.claude/agent-memory/）のファイル名と書き込み先は全プラットフォーム共通。adapter 生成物の詳細は c3 init --platform codex|cursor|opencode で出力される AGENTS.md / .cursor/rules/c3-core.mdc / .opencode/agents/ を参照。