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

実装品質を担保するために，3 つの専門エージェントを用いた開発パイプラインを定義する．

## 基本方針 (Basic Policy)

- 「実装完了」とは，コーディング・テスト・リファクタリングの全フェーズが完了した状態を指す．具体的な完了基準は [GUIDE_08](GUIDE_08_実装完了フロー.md) を参照．
- 各フェーズは専門エージェントが担当し，フレッシュなコンテキストでレビューする．
- フェーズのスキップは原則禁止する．リファクタリング不要の判断は Refactorer エージェント自身が行う．
- 各フェーズ間で人間が確認・判断を行う．

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

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

## 実装パイプライン (Implementation Pipeline)

### 開始方法

```bash
/implement <タスク内容>
```

### 全体フロー

```
人間: /implement <タスク内容>
  │
  ├─ ブランチ作成（GUIDE_04 準拠）
  │
  ├─ Phase 1 ──▶ [Coder]
  │                実装に集中．テスト・リファクタは行わない
  │
  ├─ 人間の確認ポイント 1
  │    ブラウザ/実機で動作確認
  │    OK → 続行 / NG → フィードバックして修正
  │
  ├─ Phase 2 ──▶ [Tester]
  │                仕様ベースでテスト作成・実行
  │
  ├─ Phase 2 完了後の分岐
  │    全テスト成功 → 自動で Phase 3 へ
  │    テスト失敗 → 人間に報告し判断を仰ぐ
  │
  ├─ Phase 3 ──▶ [Refactorer]
  │                テストを安全網としてリファクタリング
  │                テスト再実行で挙動が変わっていないことを保証
  │
  ├─ ドキュメント更新チェック
  │    変更内容に関連する docs/ の更新要否を確認
  │    必要なら更新してからコミットへ進む
  │
  ├─ 人間の確認ポイント 3
  │    最終確認
  │    OK → コミット・push・PR 作成
  │
  └─ CLAUDE.md 進捗更新
```

### Phase 1: コーディング (Coding)

- Coder エージェントが `docs/` を読んで実装する．
- 実装完了後，実装サマリーを出力する．
- テストやリファクタリングは行わない．
- コミットはしない．

### 人間の確認ポイント 1

- ブラウザ・実機での動作確認（AI にはできない確認）．
- 問題があればフィードバックし，Coder に修正を指示する．

### Phase 2: テスト (Testing)

- Tester エージェントが仕様（`docs/04_SPEC/`）を基準にテストを作成する．
- テストは実装コードではなく**仕様**を基準に書く．
- 実装が仕様と異なればテストが失敗し，バグを検出する．
- テスト方針は [GUIDE_07](GUIDE_07_テスト方針.md) を参照．

### Phase 2 完了後の分岐

- **全テスト成功**: テストサマリーを表示し，自動的に Phase 3 に進む．
- **テスト失敗あり**: 人間に報告し，判断を仰ぐ．
  - 仕様の問題 → 仕様を修正
  - 実装の問題 → Coder に修正を委譲
  - テストの問題 → Tester に修正を委譲

### Phase 3: リファクタリング (Refactoring)

- Refactorer エージェントがテストを安全網としてコード品質を改善する．
- 挙動は変更しない．
- リファクタリング後にテストを再実行し，全テストが通ることを確認する．
- リファクタリング不要と判断した場合は，理由を明示して終了する．
- リファクタリングの判断基準は [GUIDE_08](GUIDE_08_実装完了フロー.md) のリファクタリング方針を参照．

### ドキュメント更新チェック (Documentation Update Check)

Phase 3 完了後，コミット前に `docs/` 配下のドキュメント更新が必要かを確認する．エージェントが更新候補を提示し，人間が最終判断する（コミット前の具体的なチェックリストは [GUIDE_08](GUIDE_08_実装完了フロー.md) を参照）．

- **チェック観点**:
  - API・データ構造の変更 → `docs/04_SPEC/` の該当仕様を更新
  - 環境・依存関係の変更 → `docs/02_ENV/` を更新
  - 開発ステップの進捗 → `docs/03_PLAN/` や `CLAUDE.md` の進捗欄を更新
  - 規約・運用ルールの変更 → `docs/01_GUIDE/` を更新
- **該当なし**: ドキュメント更新が不要な変更（軽微なバグ修正，リファクタリングのみ等）はスキップ可．
- **実行者**: エージェントが `git diff` を基に更新候補を提示し，人間が更新要否を判断する．

### 人間の確認ポイント 3

- 最終確認を行い，OK ならコミット・push・PR 作成を指示する．

## コンテキスト受け渡し (Context Passing)

各エージェントは前フェーズのサマリーを入力として受け取る．加えて `git diff` で実際の変更差分を自ら確認する．

| フェーズ | 受け取る情報 |
| --- | --- |
| Coder | タスク内容 |
| Tester | Coder の実装サマリー + git diff |
| Refactorer | Coder + Tester のサマリー + git diff |

## 人間の役割 (Human's Role)

| タイミング | 人間がやること |
| --- | --- |
| 開始時 | タスクの指示（`/implement <何をするか>`） |
| Phase 1 後 | 動作確認（ブラウザ・実機など AI にできない確認） |
| Phase 2 後 | テスト失敗時のみ方針判断（全成功なら自動で Phase 3 へ） |
| Phase 3 後 | ドキュメント更新の要否判断 + 最終確認 → コミット・PR 作成の指示 |

人間の本質的な役割は「AI にできない判断と確認」であり，各フェーズの品質のゲートキーパーとなる．

## 個別実行 (Manual Execution)

パイプラインを使わず個別にエージェントを実行することも可能だが，3 フェーズすべてを順番に実行すること．

```bash
# 個別実行の場合
/coder         # Phase 1
# → 人間が動作確認
/tester        # Phase 2
# → 人間がテスト結果確認
/refactorer    # Phase 3
# → 人間が最終確認 → コミット
```

## 安全装置 (Safety Net)

Stop Hook により，実装を含む会話の終了時にテスト・リファクタリングの実施状況を確認する．未実施の場合は警告が表示される．これはアドバイザリー（助言）であり，ブロッキング（強制）ではない．

## コミットルール (Commit Rules)

パイプライン完了後のコミットは [GUIDE_04](GUIDE_04_Git運用ルール.md) に従う．

| 内容 | コミットタグ |
| --- | --- |
| 機能追加 | `[add]` |
| 機能更新 | `[update]` |
| バグ修正 | `[fix]` |

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