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 チケットとし、単一の結合ファイルにしてはいけません。
• 実際のイシュートラッカー（GitHub、Linear など） → 依存関係の順序（ブロッカーが先）でチケットごとに 1 イシューを公開し、各チケットのブロッキングエッジが実際の識別子を参照できるようにします。プラットフォームにネイティブのブロッキング関係があればそれを使用し、なければ各チケットの「Blocked by」にブロックしているイシューを設定します。ソースが既存のイシューであった場合は、各チケットをそのサブイシューにします（トラッカーのドキュメントに記載された操作）。特に指示がない限り、ready-for-agent トリアージラベルを付与します。チケットは構造上、エージェントが取得可能です。

フロンティア（ブロッカーがすべて完了しているチケット）から着手します。完全に線形なチェーンであれば、上から下へ進めるということです。

親イシューをクローズしたり変更したりしないでください。

:

What to build: このチケットで実現するエンドツーエンドの振る舞いを、ユーザーの視点から記述します。レイヤーごとの実装リストではありません。

Blocked by: このチケットをゲートするチケットの番号／タイトル、または「None (can start immediately)」。

Status: ready-for-agent

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

Parent

トラッカー上の親イシューへの参照（ソースが既存のイシューであった場合。そうでなければこのセクションは省略します）。

What to build

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

Acceptance criteria

• 基準 1
• 基準 2

Blocked by

• 各ブロッキングチケットへの参照、または「None (can start immediately)」。ブロッカーがネイティブのエッジとして設定された場合はこのセクションを省略します。

どちらの形式でも、具体的なファイルパスやコードスニペットは避けてください。すぐに古くなってしまいます。例外として、プロトタイプが、散文よりも正確に意思決定を表現するスニペット（状態機械、reducer、スキーマ、型の形）を生み出した場合は、それをインラインで記載し、プロトタイプ由来であることを簡潔に記します。動作するデモではなく、意思決定に富む部分だけに絞り、重要な部分のみを記載してください。