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

実装品質を担保するために，3 つの専門エージェントを用いた開発パイプラインを定義する．本ガイドは運用の原則を定める．各フェーズの具体的な実行手順（委譲プロンプト・分岐・確認メッセージ）は /implement（.claude/skills/implement/SKILL.md）が正本である．

基本方針 (Basic Policy)

「実装完了」とは，コーディング・テスト・リファクタリングの全フェーズが完了した状態を指す．
各フェーズは専門エージェントが担当し，フレッシュなコンテキストでレビューする．各エージェントは前フェーズのサマリーを入力として受け取り，加えて git diff で実際の変更差分を自ら確認する．
フェーズのスキップは原則禁止する．リファクタリング不要の判断は Refactorer エージェント自身が行う．
テストは実装コードではなく仕様（docs/04_SPEC/）を基準に書く．実装が仕様と異なればテストが失敗し，バグを検出する．
人間の本質的な役割は「AI にできない判断と確認」であり，各フェーズの品質のゲートキーパーとなる．

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

エージェント	役割	フェーズ
`coder`	機能実装・バグ修正	Phase 1
`tester`	仕様ベースのテスト作成・実行	Phase 2
`refactorer`	コード品質の改善	Phase 3

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

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

フェーズ	担当	やること	人間の関与
Phase 1: コーディング	`coder`	実装に集中する（テスト・リファクタ・コミットはしない）	完了後にブラウザ・実機で動作確認（AI にできない確認）．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/ 専用ブランチ

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

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