エージェント運用ルール (Agent Operation Rules)

実装品質を担保するために，3 つの専門エージェント（コーディング・テスト・リファクタリング）を用いた開発パイプラインを定義する．加えて，検証プロファイルを用意したプロジェクトでは検証エージェントが任意のフェーズとして加わる．本ガイドは運用の原則を定める．各フェーズの具体的な実行手順（委譲プロンプト・分岐・確認メッセージ）は /implement（.claude/skills/implement/SKILL.md）が正本である．

基本方針 (Basic Policy)

「実装完了」とは，コーディング・テスト・リファクタリングの全フェーズが完了した状態を指す．
各フェーズは専門エージェントが担当し，フレッシュなコンテキストでレビューする．各エージェントは前フェーズのサマリーを入力として受け取り，加えて git diff で実際の変更差分を自ら確認する．
フェーズのスキップは原則禁止する．リファクタリング不要の判断は Refactorer エージェント自身が行う．※ 例外は任意フェーズの Phase 1b（検証）で，前提が揃わない場合は理由を添えてスキップする．
検証エージェント（Phase 1b）は人間の動作確認を置き換えない．機械的に確かめられる範囲を先に潰し，人間が見る範囲を狭めるための前段であり，verifier の OK を人間の OK の代わりにしてはならない．
テストは実装コードではなく仕様（docs/04_SPEC/）を基準に書く．実装が仕様と異なればテストが失敗し，バグを検出する．
人間の本質的な役割は「AI にできない判断と確認」であり，各フェーズの品質のゲートキーパーとなる．

エージェント一覧 (Agent List)

エージェント	役割	フェーズ
`coder`	機能実装・バグ修正	Phase 1
`verifier`	動作・エッジケースの確認（任意．対象はローカル環境と，プロファイルが許可した検証用環境）	Phase 1b
`tester`	仕様ベースのテスト作成・実行	Phase 2
`refactorer`	コード品質の改善	Phase 3

※ verifier は検証プロファイル（.claude/verify-profile.md）を用意したプロジェクトでのみ動く任意のエージェント．プロファイルが無ければ Phase 1b は理由を 1 行添えてスキップされ，動作確認は従来どおり人間が行う．単独では /verify で起動する．検証手段・検証対象の環境・実行コマンド・前提条件といったプロジェクト固有の情報はすべてプロファイルに書き，エージェント側は持たない（雛形: .claude/skills/verify/profile-template.md）． ※ 検証対象の環境は既定でローカルのみ．staging 等の検証用環境は，人間がプロファイルの「検証対象の環境」に「いじっても影響が無い」と判断した根拠つきで書いた接続先に限り許可される（書かれていない環境を verifier が自分の判断で使うことはない）．本番はどんな場合も対象外．

補助エージェント (Support Agents)

実装パイプライン外でも，「思考（判断・文章品質）はメインループ，機械的な実行は軽量エージェント」の分担で使用量を節約する．サブエージェントは新規の小さいコンテキストで起動されるため，メインループのプロンプトキャッシュを壊さずに，安価なモデルにも上位モデルにも切り替えられる（メインのモデル切替はキャッシュ全損になるため行わない）．以下は各 skill から起動される補助エージェント．

エージェント	役割	使用元
`ops-runner`	git・gh・検証コマンドの機械的な実行（手順書に忠実に従い，判断が要る事態では停止して報告する）	`/commit`・`/task-create`・`/task-start`・`/task-handoff`・`/deps-update`
`deps-analyst`	依存更新 1 件の影響分析（破壊的変更の抽出・利用箇所の突き合わせ・推奨対応）	`/deps-update`
`advisor`	重要な価値判断・設計判断の相談役（Fable による熟考・助言．実装はしない）．Claude が自発的に呼んでよい基準（不可逆な設計判断の直前・同じ失敗が 2 回続いたとき）と上限（1 タスク 2 回，無人ループは 1 起動 3 回）は `/consult` skill に定める	`/consult`（`/auto-refactor`・`/auto-audit` からも上限付きで使用）

パイプラインの流れと人間の役割 (Pipeline & Human's Role)

/implement <タスク内容> で開始する（作業ブランチは git-conventions ルールに従い作成される）．

フェーズ	担当	やること	人間の関与
Phase 1: コーディング	`coder`	実装に集中する（テスト・リファクタ・コミットはしない）	—
Phase 1b: 検証（任意）	`verifier`	検証プロファイルに従い，ローカル環境（およびプロファイルが許可した検証用環境）で動作とエッジケースを確認する（コードは直さない）．プロファイルが無ければスキップ	完了後にブラウザ・実機で動作確認（AI にできない確認）．verifier が確認済みの項目は除き，残りを確認する．NG ならフィードバックして修正させる
Phase 2: テスト	`tester`	仕様（`docs/04_SPEC/`）を基準にテストを作成・実行する	テスト失敗時のみ方針判断（仕様・実装・テストのどれの問題か）．全成功なら自動で Phase 3 へ
Phase 3: リファクタリング	`refactorer`	テストを安全網に，挙動を変えずに品質を改善する	なし（不要判断は Refactorer 自身が行う）
Phase 4: ドキュメント更新	メイン	`docs/`・進捗記録を必要に応じて更新し，結果を `.claude/commit-context.md` に書き出す	更新がある場合のみ確認
完了	—	`/implement` はコミットしない	`/commit` でコミットする

チェック観点や委譲プロンプト等の詳細は .claude/skills/implement/SKILL.md を参照．.claude/commit-context.md は /commit が参照し，ドキュメント更新漏れチェックをスキップするために使う（.gitignore 対象）．

コミットルール (Commit Rules)

パイプライン完了後は /commit でコミットする．コミットメッセージのタグ等は .claude/rules/git-conventions.md に従う．

※ リファクタリングとテストは実装と一体の成果物として，まとめてコミットする．必要に応じて分割コミットも可．

※ 例外（無人運転）: 以下のループは CLAUDE.md の「/commit 自発実行禁止」ルールに対するユーザー承認済みの例外として，専用ブランチに自律コミットする．いずれも push・PR・マージ・main への操作は行わず，取り込み可否は人間が判断する．

/auto-refactor（リファクタ／ドキュメント整理ループ）→ refactor/ 専用ブランチ
/auto-audit（バグ／脆弱性の巡回監査ループ．発見を裏取り後，再現テストで正しさを担保できるものだけ自動修正し，それ以外は台帳へ報告）→ fix/ 専用ブランチ

※ 例外（Dependabot PR の取り込み）: /deps-update は，Dependabot が作成した依存更新 PR に限り，ゲート（メジャー更新でない・競合なし・CI 緑またはローカル検証緑）を満たすものを gh pr merge --merge で main に取り込む．これは「Claude が main へマージする」唯一の承認済み例外であり，ユーザーが明示的に起動した時のみ動く．メジャー更新・CI 赤・PR が付かない alert は影響分析付きで報告し，人間が判断する（.claude/skills/deps-update/SKILL.md）．

進捗記録の運用ルール（CLAUDE.md / PROGRESS.md）

進捗記録（CLAUDE.md「開発進捗」・docs/PROGRESS.md の書き方）のルールは .claude/rules/progress-log.md に定義されている．該当ファイルを編集する際に自動で読み込まれる．