To Issues

計画を垂直スライス（tracer bullets）を使って、独立した粒度の issues に分割します。

issue tracker と triage ラベル語彙があなたに提供されているはずです — されていない場合は /setup-matt-pocock-skills を実行してください。

プロセス

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

会話コンテキストに既にあるものから作業を進めます。ユーザーが issue 参照（issue 番号、URL、またはパス）を引数として渡す場合は、issue tracker からそれを取得し、本文とコメント全体を読みます。

2. コードベースを探索する（オプション）

まだコードベースを探索していない場合は、コードの現在の状態を理解するために実行します。Issue のタイトルと説明は、プロジェクトのドメイン用語集を使用し、触れている領域の ADR を尊重する必要があります。

3. 垂直スライスを草案する

計画を tracer bullet issues に分割します。各 issue は、1 つのレイヤーの水平スライスではなく、すべての統合レイヤーをエンドツーエンドで切り抜く薄い垂直スライスです。

スライスは「HITL」または「AFK」です。HITL スライスは、アーキテクチャの決定やデザインレビューなど、人間による相互作用が必要です。AFK スライスは、人間による相互作用なしに実装とマージができます。可能な限り AFK を HITL より優先します。

<vertical-slice-rules> - 各スライスはすべてのレイヤー（schema、API、UI、tests）を通して狭いながらも COMPLETE なパスを提供する - 完了したスライスはそれ自体でデモ可能または検証可能である - 少数の厚いスライスよりも多くの薄いスライスを優先する </vertical-slice-rules>

4. ユーザーに質問する

提案された分割を番号付きリストとして提示します。各スライスについて、以下を表示します：

• タイトル: 短い説明的な名前
• タイプ: HITL / AFK
• ブロック対象: 最初に完了する必要がある他のスライス（ある場合）
• カバーされるユーザーストーリー: これがアドレスしてるユーザーストーリー（ソース資料にある場合）

ユーザーに以下を質問します：

• 粒度は適切に感じられますか？（粗すぎる / 細かすぎる）
• 依存関係は正しいですか？
• スライスをマージするか、さらに分割すべきですか？
• 正しいスライスが HITL と AFK としてマークされていますか？

ユーザーが分割を承認するまで反復します。

5. issues を issue tracker に公開する

承認された各スライスについて、issue tracker に新しい issue を公開します。下記の issue 本文テンプレートを使用してください。これらの issues は AFK agents に対応できるものと見なされるため、別途指示がない限り正しい triage ラベルで公開してください。

依存関係の順序（ブロッカー優先）で issues を公開して、「ブロック対象」フィールドで実際の issue 識別子を参照できるようにします。

<issue-template> ## Parent

issue tracker 上の親 issue への参照（ソースが既存の issue である場合、そうでない場合はこのセクションを省略します）。

What to build

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

具体的なファイルパスやコードスニペットは避けてください — すぐに古くなります。例外：プロトタイプが散文よりも正確に決定をエンコードするスニペット（state machine、reducer、schema、type shape）を生成した場合は、ここにインラインで記述して、プロトタイプからのものであることを簡潔に記載してください。決定が豊富な部分にトリミングしてください — 動作するデモではなく、重要な部分だけです。

Acceptance criteria

• Criterion 1
• Criterion 2
• Criterion 3

Blocked by

• ブロッキングチケットへの参照（ある場合）

またはブロッカーがない場合は「None - can start immediately」。

</issue-template>

親 issue を閉じたり修正したりしないでください。