to-tickets

リポジトリに関わる作業を始める前に、../../WORK-ROUTING.md を読んでください。このドキュメントは、プロジェクト文書、作業レーンの選択、計画の担当、作業完了時の締めくくりに関する共通のルーティング情報源です。

チケット化

計画、仕様書、会話の内容を、チケットのセットに分解します。各チケットはトレーサーバレット形式の垂直スライスで、それをブロックするチケットを明示します。

イシュートラッカーとトリアージ用ラベルの語彙は、あらかじめ提供されているはずです。提供されていない場合は、/setup-matt-pocock-skills を実行してください。

プロセス

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

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

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

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

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

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

作業をトレーサーバレットチケットに分解します。

• 各スライスは、すべてのレイヤー（スキーマ、API、UI、テスト）を通る、狭くても完全な経路にします。垂直スライスとし、単一レイヤーだけを対象とする水平スライスにはしません。
• 完了したスライスは、それ単独でデモまたは検証が可能です。
• 各スライスは、ひとつの新しいコンテキストウィンドウ内で完了できる規模にします。
• 事前のリファクタリングが必要な場合は、先に行います。

各チケットに、そのブロッキング関係、つまり開始前に完了している必要がある他のチケットを明記します。ブロッカーのないチケットは、すぐに着手できます。

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

4. ユーザーに確認する

提案する分解を番号付きリストで提示します。各チケットについて、次の項目を示します。

• タイトル：短く内容を表す名前
• ブロックされる要因：先に完了する必要がある他のチケット（ある場合）
• 提供するもの：このチケットによって実現する、エンドツーエンドの動作

ユーザーに次の点を尋ねます。

• 粒度は適切ですか？（粗すぎる／細かすぎる）
• ブロッキング関係は正しいですか？各チケットが、本当に開始を妨げるチケットだけに依存していますか？
• チケットを統合したり、さらに分割したりする必要はありますか？

ユーザーが分解を承認するまで、調整を続けます。

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

承認済みのチケットを公開します。方法は、設定されているトラッカー /setup-matt-pocock-skills によって異なります。どちらの場合もチケット自体は同じで、変わるのはブロッカーの関連付けの形式だけです。

• ローカルファイル → .scratch/<feature-slug>/issues/<NN>-<slug>.md の下に、チケットごとに1つのファイルを書き込みます。依存関係の順に（ブロッカーを先に）、01 から番号を付けます。各ファイルの「Blocked by」には、依存するチケットの番号／タイトルを記載します。以下のチケットごとのファイルテンプレートを使用してください。チケットごとに1ファイルとし、1つにまとめたファイルは作成しないでください。
• 実際の課題トラッカー（GitHub、Linear、…） → チケットごとに1件の課題を、依存関係の順に（ブロッカーを先に）公開し、各チケットのブロッカーの関連付けで実際の識別子を参照できるようにします。プラットフォームにネイティブのブロッカー／サブ課題の関連付けがある場合はそれを使用し、ない場合は各チケットの「Blocked by」にブロッカーとなる課題を記載します。特に指示がない限り、トリアージラベル ready-for-agent を適用します。チケットは作成時点でエージェントがすぐに取りかかれる状態です。

フロンティアに取り組みます。ブロッカーがすべて完了しているチケットが対象です。完全な直線状の依存関係であれば、上から順に進めます。

親課題はクローズも変更もしないでください。

— <チケットタイトル>

作るもの： このチケットで実現する、ユーザー視点でのエンドツーエンドの振る舞いです。レイヤーごとの実装項目の一覧ではありません。

Blocked by： このチケットの開始を妨げるチケットの番号／タイトル、または「None — can start immediately」。

ステータス： ready-for-agent

• 受け入れ条件 1
• 受け入れ条件 2

親課題

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

作るもの

このチケットで実現する、ユーザー視点でのエンドツーエンドの振る舞いです。レイヤーごとの実装ではありません。

受け入れ条件

• 条件 1
• 条件 2

Blocked by

• ブロッカーとなる各チケットへの参照、または「None — can start immediately」。

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