implement-plan

計画の実行

受け入れられた計画を、スライスごとに順番に進めます。実際のシステムで成果が実証され、レビューされた時点でスライスは完了です。チェックがすべて成功した時点ではありません。

前提条件と権限

• スライスを含む受け入れ済みの計画から開始します。明確でリスクの低い依頼であれば、単一のスライスを含む簡潔なインライン計画を作成できます。理由、アプローチ、またはスライスが未確定の場合は、/plan-it を使用します。
• スコープ内で必要なソースコードやテストの変更について、ファイルごとの承認は不要です。計画で許可されていない Git 操作、破壊的な操作、共有システムまたは本番システムへの書き込みを行う前、および受け入れられたスコープ外の作業や新たな設計上の判断を行う前には、具体的な承認を得てください。
• ユーザーの無関係な作業は保持してください。新たな証拠が受け入れられた成果と境界を維持する場合は、詳細を調整してください。証拠によって重要な選択が無効になる場合は、判断を仰ぐために作業を停止してください。

スライスループ

各スライスを、以下の手順に沿って順番に進めます。いずれかの手順に失敗したら、そのスライスを実装に戻し、先へ進まないでください。

1. レッド。 TDD: yes の場合は /tdd に従い、外側から内側へ進めます。テスト環境から到達できる範囲で、まずスライスの受け入れ基準のレベルで失敗するテストを作成します（実際のルートに対する統合テスト、エンドツーエンドで実行する CLI、E2E フローなど）。より限定的なテストは、実装上必要になった段階で追加します。テストの判断 に基づき、スライスに新しいテストが不要な場合は、その免除を記録し、無理にテストを作らないでください。バグの場合は、まず失敗を再現してください。再現なしの修正は当て推量です。

   高リスクのスライス（パブリックコントラクト、永続化データ、共有モジュール、本番環境のパスを変更するもの）のテストは、別のテスト作成サブエージェントが作成します。そのエージェントに渡す概要には、計画の「理由」、スライスの「成果」と「受け入れ基準」、パブリックインターフェースのみを含め、実装方針は含めません。エージェントは外側から内側へテストを書き、想定どおりの理由で RED になることを確認してから引き渡します。実装担当者はこれらのテストを編集してはいけません。テストに誤りがあると考える場合は、作業を止め、理由を添えてテスト作成者またはユーザーに差し戻し、判断を仰いでください。

2. 実装。 スライスの境界内で成果を実現する、最小限の変更を加えます。

3. グリーン。 スライスのテストと、変更箇所に近いテストを実行します。

4. 機械的チェック。 プロジェクトが定める型チェック、Lint、フォーマット、デッドコードのチェックを実行します。すべてパスする必要があります。

5. 受け入れ確認。 計画の受け入れ基準に記載されたとおりに、実際のシステム上でスライスの成果を確認します。プロジェクトに検証スキルがある場合はそれを使用し、最初に Doctor を実行します（この手順で必要なセクションがない場合は、その旨を伝えて /maintain-verification-skill を提案してください）。ない場合は、対象のインターフェースに応じて確認します。Web フローならブラウザーで変更後の画面をスクリーンショットに記録し、CLI ならコマンドを実行し、サービスなら実際のリクエストを送り、インフラならデプロイして動作を確認します。/verification-evidence を適用してください。受け入れ確認には、実際のシステムで観察した証拠が必要です。コマンドと出力、またはスクリーンショットとして記録してください。それより弱い証拠しかない場合は、理由を添えて判断不能と報告します。

   リポジトリに検証スキルがある場合は、このスライスが変更した内容や得られた知見を、スライス自身の差分に反映してください。スライスで変更したユーザー向けの動作についてはフィーチャーファイルを更新します。新機能の場合は新しいファイルを作成し、インデックスにも追加します。また、発見した起動手順、注意点、安全な環境に関する情報があれば、スキルの Drive、サービス、環境に関するメモに追記します。計画の権限範囲で編集が認められていない場合は、代わりに更新案を報告してください。

6. レビュー。 スライスのリスクに応じて選んだ観点を使い、スライスの差分に対して /review-change を実行します。確認済みのブロッカーを修正し、修正箇所について手順 3〜5 を再実行します。

7. コミット。 計画でスライスごとのコミットが許可されている場合は、スライスを独立したコミットとして記録します。許可されていない場合は、準備完了を報告して続行します。

いずれかの手順で、原因が明らかでない予想外の動作が見つかった場合は、さらに編集する前に /diagnose-bug を適用してください。再現し、仮説を検証してから修正し、同じシグナルを再実行します。その動作が意図された設計である可能性もあるため、修正する前に確認してください。

その後、次のスライスに進みます。進捗メモは情報共有のためのものであり、承認を求めるものではありません。

スライスが境界を超えて大きくなった場合は作業を止め、差分に追加作業を含めてしまうのではなく、ユーザーと相談してスライスを切り直してください。最後のスライスが完了したら、完成した機能全体に対して、完成機能向けの観点を使って /review-change を一度実行します。

出力

スライスごとに報告し、その後、全体を報告します。

### Slice <n>: <outcome>
- Tests: <author: implementer / test-author subagent>, <RED evidence or exemption reason>, <GREEN command and result>, <disputed tests and their resolution>
- Checks: <commands and results>
- Acceptance: <passed / failed / inconclusive> — <command, output, or screenshot path>
- Review: <lenses run>, <Blockers fixed>, <residual risk>
- Commit: <hash, or "not committed">

残っているリスク、計画からの逸脱、判断不能のまま残っている事項を最後に記載してください。

完了基準

すべてのスライスにテスト結果または免除の記録があり、高リスクのスライスは、実装者がテストを編集していない別のテスト作成者によってテストされ、機械的チェックに合格し、証拠を記録した受け入れ結果があり、スライスの差分が Where it lives のパスに触れるすべての verify-skill 機能ファイルがその差分で更新されている（または編集が許可されていない場合は更新が提案されている、もしくは理由を添えて不要と報告されている）こと、未解決の確定済み Blocker がないレビューがあり、完成機能レビューが実施され、各スライスが計画に従ってコミット済みまたは未コミットとして報告され、未確定のものを合格と報告せず、一時的なデバッグコードが残っておらず、すべての副作用が承認された権限の範囲内に収まっていること。