to-issues

Issue への分解

垂直スライス（トレーサーバレット）を使用して、計画を独立して着手可能な Issue に分解します。

Issue トラッカーとトリアージラベルの語彙はすでに提供されているはずです。提供されていない場合は /setup-matt-pocock-skills を実行してください。

プロセス

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 本文テンプレートを使用します。needs-triage トリアージラベルを適用して、各 Issue が通常のトリアージフローに入るようにします。

「ブロック元」フィールドで実際の Issue 識別子を参照できるよう、依存関係の順序（ブロッカーが最初）で Issue を公開します。

## 親

Issue トラッカー上の親 Issue への参照（元が既存の Issue であった場合。それ以外の場合はこのセクションを省略します）。

実装する内容

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

受け入れ基準

• 基準 1
• 基準 2
• 基準 3

ブロック元

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

ブロッカーがない場合は「なし - すぐに開始可能」。

親 Issue を閉じたり変更したりしないでください。