diff --git a/.claude/skills/implement/SKILL.md b/.claude/skills/implement/SKILL.md index 1de9bee..22c51b8 100644 --- a/.claude/skills/implement/SKILL.md +++ b/.claude/skills/implement/SKILL.md @@ -38,7 +38,7 @@ tester エージェントに以下を委譲する: -「直前の実装に対するテストを仕様ベースで作成・実行してください． +「直前の実装に対するテストを，仕様（`docs/04_SPEC/`）を基準に作成・実行してください．テストは実装コードではなく仕様を基準に書くこと． 実装サマリー: {Coder の出力}」 @@ -75,7 +75,13 @@ ## Phase 4: ドキュメント更新 (Documentation) -GUIDE_05 の「Phase 4: ドキュメント更新」に記載されたチェック観点に従い，`docs/`, `CLAUDE.md`, `docs/PROGRESS.md` を必要に応じて更新する．進捗を記録する場合は進捗記録ルール `.claude/rules/progress-log.md` に従う（CLAUDE.md は最新 1 行に上書き，`docs/PROGRESS.md` に詳細を末尾追記．`git log` で取れる詳細は書かない）． +実装内容を以下のチェック観点で確認し，`docs/`, `CLAUDE.md`, `docs/PROGRESS.md` を必要に応じて更新する: + +- API・データ構造の変更 → `docs/04_SPEC/` の該当仕様を更新 +- 環境・依存関係の変更 → `docs/02_ENV/` を更新 +- 開発ステップの進捗 → `docs/03_PLAN/` や進捗記録（`CLAUDE.md` の進捗欄＋ `docs/PROGRESS.md`）を更新（書式は進捗記録ルール `.claude/rules/progress-log.md` に従う．CLAUDE.md は最新 1 行に上書き，`docs/PROGRESS.md` に詳細を末尾追記．`git log` で取れる詳細は書かない） +- 規約・運用ルールの変更 → `docs/01_GUIDE/` を更新 +- 該当なし（軽微なバグ修正，リファクタリングのみ等）→ 更新をスキップしてよい Phase 4 の結果を `.claude/commit-context.md` に書き出す: diff --git "a/docs/01_GUIDE/GUIDE_05_\343\202\250\343\203\274\343\202\270\343\202\247\343\203\263\343\203\210\351\201\213\347\224\250\343\203\253\343\203\274\343\203\253.md" "b/docs/01_GUIDE/GUIDE_05_\343\202\250\343\203\274\343\202\270\343\202\247\343\203\263\343\203\210\351\201\213\347\224\250\343\203\253\343\203\274\343\203\253.md" index 28c7d42..91f9daf 100644 --- "a/docs/01_GUIDE/GUIDE_05_\343\202\250\343\203\274\343\202\270\343\202\247\343\203\263\343\203\210\351\201\213\347\224\250\343\203\253\343\203\274\343\203\253.md" +++ "b/docs/01_GUIDE/GUIDE_05_\343\202\250\343\203\274\343\202\270\343\202\247\343\203\263\343\203\210\351\201\213\347\224\250\343\203\253\343\203\274\343\203\253.md" @@ -1,13 +1,15 @@ # エージェント運用ルール (Agent Operation Rules) 実装品質を担保するために，3 つの専門エージェントを用いた開発パイプラインを定義する． +本ガイドは運用の**原則**を定める．各フェーズの具体的な実行手順（委譲プロンプト・分岐・確認メッセージ）は `/implement`（`.claude/skills/implement/SKILL.md`）が正本である． ## 基本方針 (Basic Policy) - 「実装完了」とは，コーディング・テスト・リファクタリングの全フェーズが完了した状態を指す． -- 各フェーズは専門エージェントが担当し，フレッシュなコンテキストでレビューする． +- 各フェーズは専門エージェントが担当し，フレッシュなコンテキストでレビューする．各エージェントは前フェーズのサマリーを入力として受け取り，加えて `git diff` で実際の変更差分を自ら確認する． - フェーズのスキップは原則禁止する．リファクタリング不要の判断は Refactorer エージェント自身が行う． -- 各フェーズ間で人間が確認・判断を行う． +- テストは実装コードではなく**仕様**（`docs/04_SPEC/`）を基準に書く．実装が仕様と異なればテストが失敗し，バグを検出する． +- 人間の本質的な役割は「AI にできない判断と確認」であり，各フェーズの品質のゲートキーパーとなる． ## エージェント一覧 (Agent List) @@ -17,118 +19,19 @@ | `tester` | 仕様ベースのテスト作成・実行 | Phase 2 | | `refactorer` | コード品質の改善 | Phase 3 | -## 実装パイプライン (Implementation Pipeline) +## パイプラインの流れと人間の役割 (Pipeline & Human's Role) -### 開始方法 +`/implement <タスク内容>` で開始する（作業ブランチは git-conventions ルールに従い作成される）． -```bash -/implement <タスク内容> -``` +| フェーズ | 担当 | やること | 人間の関与 | +| --- | --- | --- | --- | +| 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` でコミットする | -### 全体フロー - -``` -人間: /implement <タスク内容> - │ - ├─ ブランチ作成（git-conventions ルール準拠） - │ - ├─ Phase 1 ──▶ [Coder] - │ 実装に集中．テスト・リファクタは行わない - │ - ├─ 人間の確認ポイント 1 - │ ブラウザ/実機で動作確認 - │ OK → 続行 / NG → フィードバックして修正 - │ - ├─ Phase 2 ──▶ [Tester] - │ 仕様ベースでテスト作成・実行 - │ - ├─ Phase 2 完了後の分岐 - │ 全テスト成功 → 自動で Phase 3 へ - │ テスト失敗 → 人間に報告し判断を仰ぐ - │ - ├─ Phase 3 ──▶ [Refactorer] - │ テストを安全網としてリファクタリング - │ テスト再実行で挙動が変わっていないことを保証 - │ - ├─ Phase 4 ──▶ ドキュメント更新 - │ docs/, CLAUDE.md, docs/PROGRESS.md を必要に応じて更新 - │ 更新がある場合のみ人間の確認を挟む - │ 結果を .claude/commit-context.md に書き出す - │ - └─ 完了 → /commit でコミット -``` - -### Phase 1: コーディング (Coding) - -- Coder エージェントが `docs/` を読んで実装する． -- 実装完了後，実装サマリーを出力する． -- テストやリファクタリングは行わない． -- コミットはしない． - -### 人間の確認ポイント 1 - -- ブラウザ・実機での動作確認（AI にはできない確認）． -- 問題があればフィードバックし，Coder に修正を指示する． - -### Phase 2: テスト (Testing) - -- Tester エージェントが仕様（`docs/04_SPEC/`）を基準にテストを作成する． -- テストは実装コードではなく**仕様**を基準に書く． -- 実装が仕様と異なればテストが失敗し，バグを検出する． - -### Phase 2 完了後の分岐 - -- **全テスト成功**: テストサマリーを表示し，自動的に Phase 3 に進む． -- **テスト失敗あり**: 人間に報告し，判断を仰ぐ． - - 仕様の問題 → 仕様を修正 - - 実装の問題 → Coder に修正を委譲 - - テストの問題 → Tester に修正を委譲 - -### Phase 3: リファクタリング (Refactoring) - -- Refactorer エージェントがテストを安全網としてコード品質を改善する． -- 挙動は変更しない． -- リファクタリング後にテストを再実行し，全テストが通ることを確認する． -- リファクタリング不要と判断した場合は，理由を明示して終了する． - -### Phase 4: ドキュメント更新 (Documentation) - -Phase 3 完了後，実装内容に応じて `docs/`, `CLAUDE.md`, `docs/PROGRESS.md` を更新する． - -- **チェック観点**: - - API・データ構造の変更 → `docs/04_SPEC/` の該当仕様を更新 - - 環境・依存関係の変更 → `docs/02_ENV/` を更新 - - 開発ステップの進捗 → `docs/03_PLAN/` や進捗記録（`CLAUDE.md` の進捗欄＋ `docs/PROGRESS.md`）を更新（書式は進捗記録ルール `.claude/rules/progress-log.md` に従う．`git log` で取れる詳細は書かない） - - 規約・運用ルールの変更 → `docs/01_GUIDE/` を更新 -- **該当なし**: ドキュメント更新が不要な変更（軽微なバグ修正，リファクタリングのみ等）はスキップ可． -- **更新がある場合のみ**人間の確認を挟む．更新不要の場合は確認なしで完了処理に進む． -- **コミットコンテキストの書き出し**: Phase 4 の結果（更新の有無と理由）を `.claude/commit-context.md` に書き出す．このファイルは `/commit` が参照し，`docs/`, `CLAUDE.md`, `docs/PROGRESS.md` の更新漏れチェックをスキップするために使う（`.gitignore` 対象）． - -### 完了処理 - -- `/implement` はコミットを行わない．完了後は `/commit` でコミットする． -- `/commit` は `.claude/commit-context.md` が存在する場合，`docs/`, `CLAUDE.md`, `docs/PROGRESS.md` の更新漏れチェックをスキップする．存在しない場合（`/implement` を経由していない場合）は警告のみ行う． - -## コンテキスト受け渡し (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 4 後 | ドキュメント更新がある場合のみ確認 → `/commit` でコミット | - -人間の本質的な役割は「AI にできない判断と確認」であり，各フェーズの品質のゲートキーパーとなる． +チェック観点や委譲プロンプト等の詳細は `.claude/skills/implement/SKILL.md` を参照．`.claude/commit-context.md` は `/commit` が参照し，ドキュメント更新漏れチェックをスキップするために使う（`.gitignore` 対象）． ## コミットルール (Commit Rules)