to-tickets

To Tickets

計画、仕様書、または会話を、チケットのセットに分割します。各チケットは tracer bullet 形式の垂直スライスで、ブロックするチケットを明示します。

issue tracker と triage label の語彙は提供されているはずです。まだの場合は /setup-leandrocfe-skills を実行してください。

プロセス

1. コンテキストを集める

会話のコンテキストにすでにある情報を使ってください。ユーザーが引数として参照（仕様書のパス、issue 番号、または URL）を渡した場合は、それを取得して本文全体とコメントを読んでください。

2. codebase を調査する（任意）

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

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

3. 垂直スライスの下書きを作成する

作業を tracer bullet チケットに分割してください。

• 各スライスは、すべてのレイヤー（スキーマ、API、UI、テスト）を通る狭くても完全な経路を実装します。単一レイヤーの水平スライスではなく、垂直スライスにしてください。
• 完了したスライスは、それ単体でデモまたは検証が可能です。
• 各スライスは、新しいコンテキストウィンドウ 1 つに収まる規模にします。
• 事前のリファクタリングは最初に行います。

各チケットにブロッカーの依存関係を設定します。つまり、着手する前に完了している必要のある他のチケットを指定します。ブロッカーのないチケットは、すぐに着手できます。

大規模なリファクタリングは垂直スライスの例外です。 大規模なリファクタリングとは、列の名前変更や共有シンボルの型変更のように、codebase 全体に影響範囲が広がる単一の機械的な変更です。一度の編集で数千の呼び出し箇所が壊れ、垂直スライスを完了状態にできません。これを tracer bullet に無理に押し込まず、expand–contract の順に進めてください。最初に expand します。新しい形式を古い形式と並行して追加し、何も壊れない状態にします。次に、影響範囲に応じた単位（パッケージごと、ディレクトリごと）に呼び出し箇所を移行します。各単位は expand にブロックされる独立したチケットとし、古い形式を残すことで、各単位の移行後も CI が成功する状態を保ちます。最後に contract します。古い形式を使う呼び出し箇所がなくなったら、古い形式を削除します。このチケットは、すべての移行単位にブロックされます。各単位だけでは成功状態にできない場合も、この順序を維持しつつ、同じ integration branch を共有できるようにして、それらすべてが最終的な統合・検証チケットをブロックするようにします。成功状態を約束するのは、その最終チケットだけです。

4. ユーザーに確認する

提案する分割を番号付きリストで提示します。各チケットについて、以下を示してください。

• タイトル：短くわかりやすい名前
• Blocked by：先に完了する必要がある他のチケット（あれば）
• 提供内容：このチケットで実現する、エンドツーエンドの動作

ユーザーに以下を尋ねてください。

• 粒度は適切ですか？（大きすぎる／細かすぎる）
• ブロッカーの依存関係は適切ですか？各チケットが本当に着手を妨げるチケットにのみ依存していますか？
• 統合する、またはさらに分割するべきチケットはありますか？

ユーザーが分割案を承認するまで、反復してください。

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

承認済みのチケットを公開します。方法は /setup-leandrocfe-skills が設定したトラッカーによって異なります。どちらの場合もチケットは同じで、ブロッキングエッジの扱いだけが変わります。

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

フロンティアに沿って作業します。つまり、すべてのブロッカーが完了しているチケットが対象です。完全な直列のチェーンでは、上から順に進めます。

親イシューを閉じたり、変更したりしないでください。

— <チケットのタイトル>

What to build: このチケットによって実現する、ユーザーの視点から見たエンドツーエンドの動作。レイヤーごとの実装の一覧ではありません。

Blocked by: このチケットをブロックするチケットの番号／タイトル、または「なし — すぐに着手できます」。

Status: ready-for-agent

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

Parent

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

What to build

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

Acceptance criteria

• 条件 1
• 条件 2

Blocked by

• ブロッカーとなる各チケットへの参照、または「なし — すぐに着手できます」。

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