to-issues-yes

To Issues

プランを垂直スライス（トレーサーバレット）を使って、個別に着手できるイシューに分割します。

イシュートラッカーとトリアージ用ラベルの語彙は、あらかじめ共有されているはずです。共有されていない場合は、/setup-utarn-skills を実行してください。

プロセス

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

会話内にある情報をもとに作業してください。ユーザーから引数としてイシューの参照（イシュー番号、URL、またはパス）が渡された場合は、イシュートラッカーから取得して、本文とコメントをすべて読んでください。

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

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

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

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

プランをトレーサーバレットのイシューに分割してください。各イシューは、1 つのレイヤーだけを対象とする水平スライスではなく、すべての統合レイヤーをエンドツーエンドで通す、薄い垂直スライスです。

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

4. スライスは承認されたものとして進める

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

• タイトル：短く、内容が伝わる名前
• ブロックされる要因：先に完了する必要がある他のスライス（あれば）
• 対応するユーザーストーリー：該当するユーザーストーリー（元の資料に記載がある場合）

ユーザーが内訳を承認したものとして、イシューの公開に進んでください。

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

ユーザーが内訳を承認するまで、調整を繰り返してください。

5. イシューをイシュートラッカーに公開する

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

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

## 親イシュー

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

実装内容

この垂直スライスの内容を簡潔に説明します。レイヤーごとの実装方法ではなく、エンドツーエンドの振る舞いを記述してください。

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

受け入れ条件

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

ブロックされる要因

• ブロッカーとなるチケットへの参照（あれば）

ブロッカーがない場合は「なし — すぐに着手できます」と記載してください。

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