to-tickets

チケット化

計画、仕様、または会話を、複数のチケットに分割します。各チケットはトレーサーバレット型の垂直スライスで、作業開始をブロックするチケットを明示します。

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

プロセス

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

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

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

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

実装を容易にするために、事前にコードを整える機会がないか確認します。「変更を容易にしてから、容易になった変更を行う」。

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

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

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

各チケットに、作業開始をブロックする依存関係を付けます。ブロッカーのないチケットは、すぐに着手できます。

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

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

ブロック元

• ブロッカーとなる各チケットへの参照、または「なし（すぐに開始可能）」。

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