implement

ユーザーが仕様またはチケットで説明した作業を、6つのステップで実装します。各ステップは、完了条件を満たした場合にのみ完了となります。

ユーザーがチケットの参照情報を渡した場合は、課題管理システムから取得し、作業を始める前にタイトルを伝えます。参照情報が曖昧な場合は、確認してください。

サブエージェントの作業レベル

この実行中に起動されるすべてのサブエージェントは、直接起動する場合も、スキル（/tdd、/review-axes）の呼び出しによって起動される場合も、モデルにかかわらず effort: medium で実行します。ユーザーが指定した作業レベルはこのセッションにのみ適用され、起動するサブエージェントには引き継がれません。

high 以上（high、xhigh、max）での実行には、起動前にユーザーの明示的な承認が必要です。サブエージェント名、モデル、作業レベル、および medium では不十分な理由を伝えて質問し、返答を待ってください。返答がない場合は承認されていないものとします。1回の承認で許可されるのは、質問の対象となったサブエージェントの起動のみです。

ホストで起動ごとの作業レベルを設定できず、サブエージェントがこのセッションの high 以上の作業レベルを引き継ぐ場合、その起動は high での起動とみなし、同じく事前の承認が必要です。

人間が回答できない場合（あなたがサブエージェントとして実行中の場合、無人で実行している場合、またはブリーフに担当者が不在と記されている場合）は、作業を停止し、質問をブロッカーとして報告してください。作業をインラインで続行してはいけません。この実行でユーザーに確認するその他の質問（仕様の所在など）にも同じルールが適用されます。無人の場合はブロッカーとし、推測してはいけません。

1. ビルド

可能な場合は、Skill ツールで「tdd」を呼び出し、事前に合意した境界に沿って作業します。型チェックを定期的に実行し、個々のテストファイルも定期的に実行します。

実行終了後も残るもの（ドックブロック、コードコメント、README、ドキュメント、ADR）から .scratch/ 内の場所を参照してはいけません。このフォルダーは定期的に削除されるため、参照先がなくなります。必要な情報をその場に記載するか、リポジトリ内の恒久的なファイルを参照してください。

完了条件：仕様またはチケットのすべての内容が実装されていること。

2. テスト

テストスイート全体を1回実行します。

完了条件：テストスイートを実行し、結果を把握していること。

3. リファクタリング

テストスイートが成功している場合に限り、今回の実行で作成したコードを対象に、クリーンアップを1回行います。

• 前提条件： テスト後にテストスイート全体が成功していること。成功していない場合はこのステップをスキップし、判定にその旨を記載します。
• 対象範囲： 今回の差分で作成または変更したコードのみ（未コミットの作業ツリー。/delegate-tickets 配下では現在のチケットのみ）。差分の範囲外で価値のあるリファクタリングに気づいても、適用せず、判定に記載してください。
• ルール： 動作を変更してはいけません。リファクタリングを通すためにテストを編集してはいけません。
• 最初にスナップショットを作成します。 git stash create を使う（参照、インデックス、作業ツリーを変更しない）か、差分のファイルを別の場所にコピーします。
• リファクタリング後、テストスイート全体を実行します。 成功した場合はリファクタリングを保持します。失敗した場合はスナップショットを復元し、作業ツリーをリファクタリング前の成功状態に戻してからレビューに進みます（git stash create のスナップショットの場合は、git restore --source=<snapshot> --worktree -- <files> を実行します。これによってインデックスは変更されません。また、スナップショットには含まれないため、リファクタリングで作成したファイルを削除し、削除したファイルを再作成します）。

完了条件：テストスイートが成功した状態でリファクタリングが保持されているか、成功時のスナップショットまで復元されているか、テストスイートが失敗したためスキップされていること。

4. レビュー

今すぐ /review-axes スキルを実際に呼び出してください。固定点としてステージングされていない作業ツリーを指定してください。変更はまだどのコミットにも含まれていないため、参照ベースの差分は空になります。また、スペックを探す必要がなく、適切なチェックボックスが同期されるよう、渡されたチケットのパス、チケットがない場合はスペックのパスを spec 引数として渡してください。受け入れ条件のチェックボックス（- [ ] / - [x]）はスペックまたはチケット内に残し、/review-axes に任せてください。スペックレビュー後、実際のコードの動作に基づいてチェックボックスが同期されます。

完了条件：この実行中に /review-axes が Standards と Spec のレポートを返していること。ステップ 1〜3 の合格はこのステップへの入力であり、代わりにはなりません。以下の Verdict はレビュー結果に基づいて作成するため、レビューが完了するまでは記述できません。

5. コミット

作業を現在のブランチにコミットしてください。

完了条件：この実行での変更が、現在のブランチ上のコミットに含まれていること。

6. 報告

最後に Verdict セクションを記載してください。

Verdict

1 行で、絵文字の後に短い理由を記載してください。🟢 は絵文字のみとし、その後にテキストを付けません。

• 🟢 すべて予定どおりに進みました。完全に実装され、スペックやチケットからの逸脱はなく、/review-axes から対応が必要な指摘もなく、ユーザーによる作業も不要です。絵文字のみを出力してください。
• 🟡 実装しましたが、作業中に調整が必要でした。予定していたロジックを変更した、アプローチを切り替えた、スペックの詳細を解釈した、または /review-axes から確認すべき指摘があった場合です。また、リファクタリング後にテストスイートが失敗したため元に戻した場合（理由を 1 行で記載）、または差分の範囲外で有益なリファクタリングに気づいた場合（適用せず、プレファクターチケットを提案）も 🟡 です。維持したリファクタリングは色に影響しません。テストスイートが失敗したためリファクタリングを見送った場合は、その旨を Verdict に記載してください。現在のルールに従い、テストスイートの失敗自体も色に反映します。何を変更し、その理由を記載してください。
• 🔴 何かが反映されなかった、または作業を進める前にユーザーの対応が必要です。未実装の項目がある、/review-axes がスペックの不足を見つけた、ユーザーの判断が必要、認証情報・移行・手動作業が必要など、「次のチケットにすぐ着手する」流れを妨げるものがある場合です。何が必要で、ユーザーが何をすべきかを記載してください。

該当する色のうち、最も重大なものを選んでください。赤の条件が 1 つでもあれば、ほかが順調でも Verdict は 🔴 です。