To Tickets
計画、仕様、または会話を一連のチケットに分割します。各チケットはトレーサーブレットと呼ばれる垂直スライスであり、それぞれが自分をブロックするチケットを宣言します。
イシュートラッカーとトリアージラベルの語彙は事前に提供されている必要があります。提供されていない場合は、ユーザーに /setup-matt-pocock-skills を実行するよう伝えてください。
プロセス
1. コンテキストの収集
会話コンテキストにすでにあるものを基に作業します。ユーザーが引数として参照（仕様パス、イシュー番号、またはURL）を渡した場合は、それを取得し、本文とコメント全体を読み取ります。
2. コードベースの探索（オプション）
コードベースをまだ探索していない場合は、コードの現在の状態を理解するために探索してください。チケットのタイトルと説明には、プロジェクトのドメイン用語集の語彙を使用し、対象領域のADRを尊重してください。
実装を容易にするためにコードをプリファクタリングする機会を探してください。「変更を容易にしてから、容易な変更を行え。」
3. 垂直スライスのドラフト
作業をトレーサーブレットチケットに分割します。
- 各スライスは、すべてのレイヤー（スキーマ、API、UI、テスト）を貫く狭いが完全なパスを切り取ります。つまり、1つのレイヤーの水平スライスではなく、垂直スライスです。
- 完成したスライスは、単独でデモまたは検証可能です。
- 各スライスは、1つの新しいコンテキストウィンドウに収まるサイズにします。
- プリファクタリングは最初に行う必要があります。
各チケットにブロッキングエッジ（開始前に完了しなければならない他のチケット）を指定します。ブロッカーがないチケットはすぐに開始できます。
ワイドリファクタは垂直スライスの例外です。 ワイドリファクタとは、コードベース全体に影響範囲（ブラストラディウス）が広がる1つの機械的な変更（列の名前変更、共有シンボルの再型指定など）であり、単一の編集により数千の呼び出しサイトが同時に壊れるため、どの垂直スライスもグリーンにできません。これをトレーサーブレットに無理に押し込めないでください。代わりにexpand–contractとして順序付けます。最初にexpand：何も壊さないように、古い形式の隣に新しい形式を追加します。次に、呼び出しサイトを影響範囲ごと（パッケージごと、ディレクトリごと）にバッチで移行し、各バッチはexpandによってブロックされた独自のチケットとし、古い形式がまだ存在するためCIはバッチごとにグリーンを維持します。最後にcontract：呼び出し元がいなくなったら、すべての移行バッチによってブロックされたチケットで古い形式を削除します。バッチでさえ単独でグリーンを維持できない場合でも、順序は維持しますが、それらが共通の統合ブランチを共有し、最終的なintegrate-and-verifyチケットをブロックするようにします。グリーンはそのチケットでのみ約束されます。
4. ユーザーへの確認
提案された分割を番号付きリストとして提示します。各チケットについて、以下を表示します。
- タイトル: 短いわかりやすい名前
- ブロック元: 最初に完了しなければならない他のチケット（ある場合）
- 提供するもの: このチケットが機能させるエンドツーエンドの動作
ユーザーに質問します。
- 粒度は適切ですか？（粗すぎる / 細かすぎる）
- ブロッキングエッジは正しいですか？各チケットは本当にそれをゲートするチケットにのみ依存していますか？
- マージまたはさらに分割すべきチケットはありますか？
ユーザーが分割を承認するまで繰り返します。
5. 設定されたトラッカーにチケットを公開する
承認されたチケットを公開します。方法は /setup-matt-pocock-skills が設定したトラッカーに依存します。チケット自体は同じですが、ブロッキングエッジの形状のみが変わります。
- ローカルファイル →
.scratch/<feature-slug>/issues/<NN>-<slug>.mdにチケットごとに1ファイル書き込みます。依存関係順（ブロッカーが先）に01から番号を付けます。各ファイルの「Blocked by」には、依存する番号/タイトルをリストします。以下のチケットごとのファイルテンプレートを使用します。1チケット1ファイルであり、決して1つの結合ファイルにはしません。 - 実際のイシュートラッカー（GitHub、Linearなど） → 依存関係順（ブロッカーが先）にチケットごとに1イシューを公開し、各チケットのブロッキングエッジが実際の識別子を参照できるようにします。プラットフォームにネイティブなブロッキング/サブイシュー関係がある場合はそれを使用し、ない場合は各チケットの「Blocked by」をブロッキングイシューに設定します。別途指示がない限り、
ready-for-agentトリアージラベルを適用します。これらのチケットは構造上、エージェントが取得可能です。
フロンティア（ブロッカーがすべて完了したチケット）から作業します。純粋に線形なチェーンの場合、上から下へと進みます。
親イシューをクローズしたり変更したりしないでください。
: <チケットタイトル>
構築するもの: このチケットが機能させるエンドツーエンドの動作を、ユーザーの視点から記述します。レイヤーごとの実装リストではありません。
ブロック元: このチケットをゲートするチケットの番号/タイトル、または「なし（すぐに開始可能）」。
ステータス: ready-for-agent
- 受け入れ基準 1
- 受け入れ基準 2
親
トラッカー上の親イシューへの参照（ソースが既存のイシューの場合。それ以外の場合はこのセクションを省略）。
構築するもの
このチケットが機能させるエンドツーエンドの動作を、ユーザーの視点から記述します。レイヤーごとの実装ではありません。
受け入れ基準
- 基準 1
- 基準 2
ブロック元
- 各ブロッキングチケットへの参照、または「なし（すぐに開始可能）」。
どちらの形式でも、特定のファイルパスやコードスニペットは避けてください。それらはすぐに古くなります。例外として、プロトタイプが散文よりも正確に決定をエンコードするスニペット（ステートマシン、リデューサー、スキーマ、型形状）を生成した場合は、それをインライン化し、プロトタイプ由来であることを簡単に注記します。決定に富んだ部分のみにトリミングし、動作するデモではなく、重要なビットだけにします。