to-issues

To Issues

計画を、垂直スライス（トレーサーバレット）を使って、個別に着手できる課題に分割します。

課題トラッカーとトリアージラベルの語彙は事前に提供されているはずです。提供されていない場合は、/setup-matt-pocock-skills を実行してください。

プロセス

1. コンテキストを集める

会話のコンテキストにすでにある情報を使って作業します。ユーザーが引数として課題への参照（課題番号、URL、パス）を渡した場合は、課題トラッカーから取得し、本文とコメントをすべて読んでください。

2. コードベースを調査する（任意）

まだコードベースを調査していない場合は、現在のコードの状態を把握するために調査してください。課題のタイトルと説明では、プロジェクトのドメイン用語集の語彙を使い、変更対象の領域に関する ADR を尊重してください。

実装を容易にするため、コードを事前にファクタリングできる機会を探してください。「変更を容易にしてから、容易な変更を行う」です。

3. 課題の下書きを作成する

垂直スライスのルールに従って、計画をトレーサーバレット課題に分割します。大規模なリファクタリングは例外です。この場合は、代わりに拡張–縮小の手順で分割してください（大規模なリファクタリングを参照）。

4. ユーザーに確認する

提案する分割案を番号付きリストで提示します。各スライスについて、次の項目を示してください。

• タイトル：簡潔で説明的な名前
• ブロックしている課題：先に完了する必要がある他のスライス（該当する場合）
• 対応するユーザーストーリー：対応するユーザーストーリー（元の資料にある場合）

ユーザーに次の点を確認してください。

• 粒度は適切ですか？（大きすぎる／細かすぎる）
• 依存関係は正しいですか？
• 統合またはさらに分割すべきスライスはありますか？

ユーザーが分割案を承認するまで調整してください。

5. 課題を課題トラッカーに登録する

承認された各スライスについて、課題本文テンプレートを使って新しい課題を課題トラッカーに登録します。これらの課題は AFK エージェントがすぐに着手できる状態とみなされます。別途指示がない限り、適切なトリアージラベルを付けて登録してください。

実際の課題識別子を参照できるよう、依存関係の順（ブロックする側を先に）で登録してください。トラッカーが対応している場合は、各スライスをネイティブのサブ課題として親課題にリンクし、各ブロッカーをネイティブのブロッキングエッジとして設定してください（方法は課題トラッカーのドキュメントを参照）。それ以外の場合は、本文の ## Parent セクションと ## Blocked by セクションで代替します。

親課題をクローズまたは変更してはいけません。

リファレンス

垂直スライスのルール

各課題は、1 つのレイヤーだけを横断する水平スライスではなく、すべての統合レイヤーを端から端まで貫く薄い垂直スライスです。

• 各スライスは、すべてのレイヤー（スキーマ、API、UI、テスト）を通る、範囲が狭くても完全な経路を実現します
• 完了したスライスは、それだけでデモまたは検証が可能です
• 事前のファクタリングが必要な場合は、先に行います

大規模なリファクタリング

大規模なリファクタリングとは、列の名前変更や共有シンボルの型変更など、コードベース全体に影響が広がる 1 つの機械的な変更です。1 回の編集で何千もの呼び出し箇所が一度に壊れ、垂直スライスを緑の状態でマージできません。これを無理にトレーサーバレットへ分割せず、拡張–縮小の順序で進めてください。

まず拡張として、既存の形式と並行して新しい形式を追加し、何も壊れない状態にします。次に、影響範囲に応じた単位（パッケージごと、ディレクトリごと）で呼び出し箇所をまとめて移行します。各バッチは個別の課題とし、拡張の課題にブロックされるようにします。古い形式が残っているため、各バッチで CI を緑の状態に保てます。最後に縮小として、すべての呼び出し箇所の移行後、すべての移行バッチにブロックされた課題で古い形式を削除します。バッチを個別に緑の状態に保てない場合でも、この順序は維持しますが、すべてのバッチが最終的な統合・検証課題にブロックされる共有の統合ブランチを使います。緑の状態は、その課題でのみ保証します。

課題本文テンプレート

## Parent

課題トラッカー上の親課題への参照（元の資料が既存の課題である場合。そうでなければ、このセクションは省略してください）。

実装する内容

この垂直スライスの概要を簡潔に説明してください。レイヤーごとの実装ではなく、エンドツーエンドの動作を説明してください。

具体的なファイルパスやコードスニペットは避けてください。すぐに古くなるためです。例外として、/prototype スキルで生成されたコードが、文章よりも正確に決定事項（ステートマシン、リデューサー、スキーマ、型の形状など）を表現している場合は、コードを直接記載するのではなく、そのプロトタイプコードがある場所へのコンテキストポインターを追加してください。

受け入れ条件

• 条件 1
• 条件 2
• 条件 3

ブロックされている項目

• ブロッキングチケットへの参照（該当する場合）

または、ブロッカーがない場合は「なし — すぐに着手できます」。