to-tickets

チケット化

計画、仕様、会話を、チケットのセットに分割します。各チケットはトレーサーバレット型の垂直スライスであり、着手をブロックするチケットを明示します。

課題追跡システムとトリアージ用のラベル語彙は、事前に提供されているはずです。提供されていない場合は、/setup-agent-skills を実行するようユーザーに伝えてください。

プロセス

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

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

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

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

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

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

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

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

各チケットに、そのブロッキング関係を指定します。つまり、着手前に完了していなければならない他のチケットです。ブロッカーのないチケットはすぐに着手できます。

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

4. ユーザーに確認する

提案する内訳を番号付きリストで提示します。各チケットについて、次の内容を示してください。

• タイトル：短く、内容がわかる名前
• ブロックされる条件：先に完了が必要な他のチケット（あれば）
• 提供するもの：このチケットで実現するエンドツーエンドの動作

ユーザーに次の点を尋ねてください。

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

ユーザーが内訳を承認するまで、調整を続けてください。

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

承認済みのチケットを公開します。方法は、設定したトラッカー（/setup-agent-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)」。

Status： ready-for-agent

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

親イシュー

トラッカー上の親イシューへの参照（既存のイシューが元になっている場合。そうでなければ、このセクションは省略）。

作成するもの

レイヤーごとの実装ではなく、このチケットによってユーザー視点で実現する、エンドツーエンドの動作。

受け入れ条件

• 条件 1
• 条件 2

Blocked by

• ブロックする各チケットへの参照、または「None (can start immediately)」。

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