to-tickets

チケットへの分割

計画、仕様、会話を一連のチケットに分割します。各チケットはトレーサーバレット方式の垂直スライスで、ブロックするチケットを明示します。

イシュートラッカーとトリアージラベルの語彙は、すでに提供されているはずです。提供されていない場合は、ユーザーに /setup-matt-pocock-skills を実行するよう伝えてください。

プロセス

1. コンテキストを収集する

会話のコンテキストにすでにある情報をもとに作業します。ユーザーが参照（仕様のパス、イシュー番号、URL）を引数として渡した場合は、それを取得し、本文とコメントをすべて読みます。

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

コードベースをまだ調査していない場合は、現在のコードの状態を理解するために調査します。チケットのタイトルと説明には、プロジェクトのドメイン用語集の語彙を使用し、変更する領域の ADR に従ってください。

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

3. 垂直スライスを作成する

作業をトレーサーバレット方式のチケットに分割します。

• 各スライスは、すべてのレイヤー（スキーマ、API、UI、テスト）にまたがる、範囲の狭いものの完全な経路を実現します。水平スライスではなく、垂直スライスにしてください
• 完了したスライスは、単独でデモまたは検証できます
• 各スライスは、1 回の新しいコンテキストウィンドウ内に収まる規模にします
• 事前のファクタリングが必要な場合は、先に行います

各チケットに、ブロック関係を付けます。ブロック関係とは、着手前に完了が必要な他のチケットです。ブロッカーがないチケットは、すぐに着手できます。

広範なリファクタリングは、垂直スライスの例外です。 広範なリファクタリングとは、列名の変更や共有シンボルの型変更などの機械的な変更で、影響範囲がコードベース全体に広がり、1 回の編集で数千か所の呼び出し元が一度に壊れ、どの垂直スライスも成功した状態でマージできないものです。無理にトレーサーバレットに分割せず、エクスパンド・コントラクトの順に進めます。最初にエクスパンドを行います。新しい形式を古い形式と並行して追加し、何も壊れないようにします。次に、影響範囲に応じたバッチ（パッケージ単位、ディレクトリ単位）で呼び出し元を移行します。各バッチは独立したチケットとし、エクスパンドにブロックされるようにします。古い形式が残っているため、各バッチを通じて CI は成功した状態を保ちます。最後にコントラクトを行います。古い形式の呼び出し元がなくなった後、すべての移行バッチにブロックされるチケットで古い形式を削除します。バッチ単独では成功した状態を保てない場合も、この順序は維持し、各バッチが最終的な統合・検証チケットをブロックする共有の統合ブランチを使います。成功が保証されるのは、その最終チケットだけです。

4. ユーザーに確認する

提案する内訳を、タイトルと依存関係を見つけやすいように、固定の絵文字アンカー付きの番号付きリストで提示します。

🎫 **Proposed tickets** · N slices

1. 🎫 **<Title>**
   🔗 Blocked by: <titles or "None — can start immediately">
   ✨ Delivers: <end-to-end behaviour>

2. 🎫 **<Title>**
   ...

続けて、次の 3 点を確認します（短くしてください。1 つのブロックにまとめても構いません）。

👇 Before I publish:
1) Granularity — too coarse / too fine / about right?
2) Blocking edges — does each ticket only wait on what genuinely gates it?
3) Merge or split any?

ユーザーが内訳を承認するまで、内容を調整します。

5. チケットを設定済みのトラッカーに登録する

承認されたチケットを登録します。方法は /setup-matt-pocock-skills で設定されたトラッカーによって異なります。チケット自体は同じで、ブロック関係の形式だけが変わります。

• ローカルファイル → チケットごとに 1 ファイルを .scratch/<feature-slug>/issues/<NN>-<slug>.md に書き込みます。ブロッカーを先にして依存関係の順に並べ、01 から採番します。各ファイルの「Blocked by」には、依存するチケットの番号とタイトルを記載します。以下のチケットごとのファイルテンプレートを使用してください。1 ファイルにつきチケットは 1 件とし、全チケットを 1 つのファイルにまとめないでください。
• 実際のイシュートラッカー（GitHub、Linear など） → ブロッカーを先にして依存関係の順に、チケットごとに 1 イシューを登録します。これにより、各チケットのブロック関係で実際の識別子を参照できます。プラットフォームにネイティブのブロック関係がある場合はそれを使い、ない場合は各チケットの「Blocked by」にブロッカーとなるイシューを記載します。元の情報が既存のイシューだった場合は、各チケットをそのサブイシューにします（トラッカードキュメントに記載された操作を使用）。特に指示がない限り、ready-for-agent トリアージラベルを適用します。チケットは作成時点でエージェントが着手できる状態です。

フロンティアから作業します。すべてのブロッカーが完了しているチケットがフロンティアです。一直線の依存関係の場合は、上から順に進めます。

親イシューをクローズまたは変更してはいけません。

# : <チケットのタイトル>

構築するもの： このチケットによって実現する、ユーザーの視点から見たエンドツーエンドの動作を記述します。レイヤーごとの実装一覧ではありません。

ブロック元： このチケットの着手を妨げるチケットの番号／タイトル、または「なし（すぐに着手できます）」。

ステータス： ready-for-agent

• 受け入れ基準 1
• 受け入れ基準 2

親

トラッカー上の親イシューへの参照（既存のイシューを元にしている場合は記載し、それ以外の場合はこのセクションを省略します）。

構築するもの

このチケットによって実現する、ユーザーの視点から見たエンドツーエンドの動作を記述します。レイヤーごとの実装内容ではありません。

受け入れ基準

• 基準 1
• 基準 2

ブロック元

• ブロックする各チケットへの参照、または「なし（すぐに着手できます）」。ブロッカーがネイティブのエッジとして設定されている場合は、このセクションを省略します。

どちらの形式でも、具体的なファイルパスやコードスニペットは避けてください。すぐに古くなるためです。例外として、プロトタイプで作成したスニペットが、文章よりも正確に設計上の決定（ステートマシン、リデューサー、スキーマ、型の形状など）を表している場合は、インラインで含め、プロトタイプ由来であることを簡潔に記してください。動作するデモではなく、設計上の決定を明確に示す重要な部分に絞ってください。