to-tickets

チケット化

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

課題トラッカーとトリアージ用ラベルの語彙は、あらかじめ提供されているはずです。提供されていない場合は、先に set-up-project スキルを実行してください。

プロセス

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

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

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

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

実装を容易にするため、コードを事前にリファクタリングできる機会を探します。「変更を容易にしてから、容易な変更を行う」という考え方です。

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

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

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

各チケットには、ブロッキングの依存関係を記載します。着手前に完了していなければならない他のチケットを示してください。ブロッカーがないチケットは、すぐに着手できます。

チケットを参照する際は、番号だけでなくタイトルを使ってください。例：#12 ログインを追加 または 03: ログインを追加。分解の説明、「ブロック対象」、ユーザーに伝える内容のすべてで、このルールを適用します。

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

4. ユーザーに確認する

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

• タイトル：簡潔で内容が伝わる名前。docs/agents/issue-tracker.md の「Title prefixes」に記載された接頭辞を付けます
• ブロック対象：先に完了していなければならない他のチケット（ある場合）
• 成果：このチケットによって実現する、エンドツーエンドの動作

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

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

ユーザーが分解を承認するまで、やり取りを繰り返します。

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

承認済みのチケットを公開します。方法は、設定されているトラッカーの set-up-project によって異なります。どちらの場合もチケットは同じで、変わるのはブロッカーの関係の表し方だけです。

• ローカルファイル → 努力の spec.md の隣にある .efforts/<effort>/issues/<NN>-<slug>.md の下に、チケットごとに1つのファイルを書き込みます（<effort> は努力の名前、努力がない場合は機能の短いスラッグです）。依存関係の順序（ブロッカーを先）で 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

ブロッカー

• ブロッカーとなる各チケットへの参照（タイトル付き）、または「None (can start immediately)」。

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