to-issues

To Issues

計画を、縦方向のスライス（トレーサーバレット）を使って、個別に取り組める独立した issue に分割します。

issue トラッカーとトリアージラベルの用語集は提供されているはずです。提供されていない場合は、/setup-leandrocfe-skills を実行してください。

プロセス

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

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

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

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

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

3. 縦方向のスライスを作成する

計画をトレーサーバレット issue に分割してください。各 issue は、1 つのレイヤーだけを扱う水平スライスではなく、すべての統合レイヤーを端から端まで通る、薄い縦方向のスライスです。

• 各スライスは、すべてのレイヤー（スキーマ、API、UI、テスト）を通る、範囲が狭くても完全な経路を実現します
• 完了したスライスは、それ単独でデモまたは検証できます
• 事前リファクタリングは先に行います

4. ユーザーに確認する

提案する分割案を番号付きリストで提示してください。各スライスについて、次の内容を示します。

• タイトル：短く説明的な名前
• ブロック要因：先に完了する必要がある他のスライス（あれば）
• 対象となるユーザーストーリー：該当するユーザーストーリー（元の資料にある場合）

ユーザーに次の点を確認してください。

• 粒度は適切ですか？（粗すぎる／細かすぎる）
• 依存関係は正しいですか？
• どのスライスかを統合したり、さらに分割したりしますか？

ユーザーが分割案を承認するまで、やり取りを続けてください。

5. issue トラッカーに issue を公開する

承認された各スライスについて、以下の issue 本文テンプレートを使って、新しい issue を issue トラッカーに公開してください。これらの issue は AFK エージェントがすぐに着手できる状態とみなされるため、別途指示がない限り、適切なトリアージラベルを付けて公開してください。

依存関係の順に（ブロック要因から先に）issue を公開し、「ブロック要因」欄で実際の issue 識別子を参照できるようにしてください。

## 親 issue

issue トラッカー上の親 issue への参照を記載します（元の情報が既存の issue である場合。それ以外の場合、このセクションは省略してください）。

作成内容

この縦方向のスライスの簡潔な説明です。レイヤーごとの実装方法ではなく、端から端までの動作を説明してください。

具体的なファイルパスやコードスニペットは避けてください。すぐに古くなるためです。例外として、プロトタイプで生成されたスニペットが、説明文よりも明確に判断内容を表している場合（状態機械、reducer、スキーマ、型の形状など）は、ここにインラインで記載し、プロトタイプ由来であることを簡潔に注記してください。判断に関わる部分だけを残してください。動作するデモではなく、重要な要点に絞ります。

受け入れ条件

• 条件 1
• 条件 2
• 条件 3

ブロック要因

• ブロックするチケットへの参照（ある場合）

ブロック要因がない場合は「なし — すぐに着手できます」と記載します。

親 issue をクローズしたり、変更したりしないでください。