to-issues

Issue 化

計画を、垂直スライス（トレーサーバレット）を使って、個別に取り組める Issue に分割します。

Issue トラッカーには gh からアクセスできる必要があります。ラベルの用語が必要な場合は、プロジェクトの AGENTS.md または Issue テンプレートを確認してください。

プロセス

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

会話のコンテキストにすでにある情報をもとに進めます。ユーザーが引数として Issue の参照（Issue 番号、URL、パス）を渡した場合は、Issue トラッカーから取得し、本文とコメントをすべて読みます。

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

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

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

計画をトレーサーバレット Issue に分割します。各 Issue は、1 つのレイヤーだけを対象にする水平スライスではなく、すべての統合レイヤーをエンドツーエンドで横断する、薄い垂直スライスです。

スライスには「HITL」または「AFK」があります。HITL スライスには、アーキテクチャ上の決定やデザインレビューなど、人の作業が必要です。AFK スライスは、人の作業なしで実装し、マージできます。可能な限り HITL より AFK を優先してください。

- 各スライスは、あらゆるレイヤー（スキーマ、API、UI、テスト）をエンドツーエンドで通る、範囲は狭くても完全な経路を提供する - 完了したスライスは、それ単独でデモまたは検証ができる - 少数の分厚いスライスより、多数の薄いスライスを優先する

4. ユーザーに確認する

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

• タイトル：短く、内容がわかる名前
• タイプ：HITL / AFK
• ブロック要件：先に完了する必要がある他のスライス（あれば）
• 対象となるユーザーストーリー：このスライスが対応するユーザーストーリー（元の資料にある場合）

ユーザーに次の点を尋ねます。

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

ユーザーが分割を承認するまで、調整を繰り返します。

5. Issue を Issue トラッカーに登録する

承認された各スライスについて、以下の Issue 本文テンプレートを使って、新しい Issue を Issue トラッカーに登録します。各 Issue が通常のトリアージフローに入るよう、トリアージラベル needs-triage を付けます。

依存関係の順に（ブロックする Issue を先に）Issue を登録し、「ブロック要件」欄で実際の Issue 識別子を参照できるようにします。

## 親 Issue

Issue トラッカー上の親 Issue への参照（元の情報が既存の Issue の場合。そうでなければ、このセクションは省略）。

実装内容

この垂直スライスの簡潔な説明。レイヤーごとの実装方法ではなく、エンドツーエンドの動作を記述します。

受け入れ条件

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

ブロック要件

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

ブロック要件がない場合は「なし - すぐに着手可能」と記載します。

親 Issue をクローズまたは変更してはいけません。