name: implement model: inherit description: "実装パイプラインを開始する．コーディング（＋任意の検証）→ テスト → リファクタリングの順で専門エージェントを実行し，必要に応じて人間の確認を挟む．" argument-hint: "<タスク内容>"

あなたはオーケストレーターです． GUIDE_02（エージェント運用ルール）を読み，パイプラインのルールを理解した上で以下の手順を実行してください．

前提確認 (Pre-check)

1. 現在のブランチを確認する（git branch --show-current）
2. main ブランチにいる場合，Git 規約 .claude/rules/git-conventions.md に従い作業ブランチを作成する
   • 同ルールのブランチ命名規則に従い，適切なプレフィックスとタスク内容を表す英単語 2〜4 語（kebab-case）でブランチ名を決定する
3. 実装対象のタスクを確認する: $ARGUMENTS

Phase 1: コーディング (Coder)

coder エージェントに以下を委譲する:

「以下のタスクを実装してください: $ARGUMENTS」

Coder の出力（実装サマリー）を記録し，Phase 1b に進む．

Phase 1b: 検証 (Verifier)

検証プロファイル（.claude/verify-profile.md）を用意したプロジェクトでのみ動く任意のフェーズ．人間の動作確認の前段として，verifier エージェントに動作とエッジケースを確認させ，人間が見る範囲を絞る（人間の確認を置き換えるものではない．CLAUDE.md「手動確認が必要な作業」）． 検証する環境はローカル環境と，検証プロファイルの「検証対象の環境」が明示的に許可した検証用環境に限られる（本番は対象外）．

実行判定

以下のいずれかに該当する場合は verifier を起動せず，理由を 1 行控えて「人間への提示」に進む（エラーにしない）:

• .claude/verify-profile.md が無い（検証プロファイル未設定．この場合が既定であり，従来どおり人間が動作確認する）
• 変更が，観測可能な挙動に関係しない（ドキュメント・設定・テスト・型定義のみ等）
• 検証の前提を整えるのに破壊的な操作（データの初期化・マイグレーションの適用等）が必要で，未実施である（無断で実行せず，人間に依頼する）
• ユーザーがタスク内容で検証の省略を指示している

委譲

verifier エージェントに以下を委譲する（検証手段・実行コマンドは書かない．verifier が検証プロファイルを読む）:

「以下の実装について，動作とエッジケースを確認してください（検証する環境は検証プロファイルの『検証対象の環境』に従う）．

タスク: $ARGUMENTS

実装サマリー: {Coder の出力}」

結果による分岐

• OK: 「人間への提示」に進む
• NG（今回の変更に起因する不具合）: 人間に回す前に，coder エージェントへ verifier の不具合報告（再現手順・期待・実際・推定原因）を渡して修正を委譲し，verifier に再確認させる．この自動差し戻しは 2 回まで．それでも NG なら，未解決の不具合を添えて「人間への提示」に進み，方針を仰ぐ
• NG（今回の変更と無関係な既存の問題のみ）: 差し戻さない．「気になった点」と合わせて別件として人間に伝え，/task-create での起票を案内する
• 検証不能（前提条件を満たさない等）: 理由を控えて「人間への提示」に進む

差し戻しで coder が修正した場合は，実装サマリーを最新の内容に更新して以降のフェーズに渡す．

人間への提示

verifier を起動しなかった場合（既定）は，理由を 1 行添えて従来どおり依頼する:

「Phase 1（コーディング）が完了しました．

{Coder の実装サマリー}

※ Claude による自動検証は行っていません（理由: {1 行．例: 検証プロファイル未設定}）

ブラウザや実機で動作を確認してください．

• OK → 次のフェーズ（テスト）に進みます
• NG → 問題点を教えてください．修正します」

verifier を起動した場合は，「確認済み」と「確認してほしい」の 2 部構成で提示する:

「Phase 1（コーディング）が完了しました．

{Coder の実装サマリー}

Claude が確認済みの項目 {verifier の「確認した項目」の表．差し戻しで直した不具合があればその内容も．検証不能だった場合は，この節を「検証を実行できませんでした（理由: …）」に置き換える}

あなたに確認してほしい項目 {verifier の「人間が確認すべき残り項目」．省略・要約しすぎない．検証不能だった場合は「ブラウザや実機で動作を確認してください」}

{未解決の不具合・今回の変更と無関係な既存の問題があれば，ここに分けて記載する}

• OK → 次のフェーズ（テスト）に進みます
• NG → 問題点を教えてください．修正します」

ユーザーの OK を得るまで Phase 2 に進まないこと．verifier の判定が OK でも，それをユーザーの OK の代わりにしてはならない． NG の場合は coder エージェントに修正を委譲し，再度確認を依頼する（修正が観測可能な挙動に関わり，検証プロファイルがある場合は Phase 1b からやり直す）．

Phase 2: テスト (Tester)

tester エージェントに以下を委譲する:

「直前の実装に対するテストを，仕様（docs/04_SPEC/）を基準に作成・実行してください．テストは実装コードではなく仕様を基準に書くこと．

実装サマリー: {Coder の出力}」

Tester の出力（テストサマリー）を記録し，テスト結果に応じて分岐する:

• 全テスト成功: テストサマリーを表示し，自動的に Phase 3 に進む．
• テスト失敗あり: ユーザーに以下を提示し，判断を仰ぐ．

「Phase 2（テスト）でテスト失敗がありました．

{Tester のテストサマリー}

テスト失敗の原因を判断してください:

• 仕様の問題 → 仕様の修正方針を教えてください
• 実装の問題 → coder エージェントに修正を委譲します
• テストの問題 → tester エージェントに修正を委譲します」

ユーザーの指示に従い対応した後，再度テストを実行して全テスト成功を確認してから Phase 3 に進む．

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

refactorer エージェントに以下を委譲する:

「直前の実装・テスト後のコードをリファクタリングしてください．

実装サマリー: {Coder の出力}

テストサマリー: {Tester の出力}」

Refactorer の出力（リファクタリングサマリー）を記録し，確認を挟まず Phase 4 に進む．

Phase 4: ドキュメント更新 (Documentation)

実装内容を以下のチェック観点で確認し，docs/, CLAUDE.md, docs/PROGRESS.md を必要に応じて更新する:

• API・データ構造の変更 → docs/04_SPEC/ の該当仕様を更新
• 環境・依存関係の変更 → docs/02_ENV/ を更新
• 起動・テスト・lint 等の開発コマンドの追加・変更 → docs/02_ENV/ENV_04_開発コマンド.md を更新（無ければ作成し，CLAUDE.md のドキュメント一覧にリンクを追記する）
• 開発ステップの進捗 → 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 に書き出す:

# commit-context
- docs_updated: true/false
- claude_md_updated: true/false
- progress_md_updated: true/false
- note: （更新不要の理由や更新内容の要約）

ドキュメントを更新した場合のみ，ユーザーに提示する:

「Phase 4（ドキュメント更新）が完了しました．

{更新したドキュメントの一覧と変更内容の要約}

確認をお願いします．

• OK → /commit でコミットできます
• NG → 修正点を教えてください」

更新不要と判断した場合は，確認を挟まず完了処理に進む．

完了処理 (Finalization)

「全フェーズが完了しました．/commit でコミットしてください．」