slice-the-spec

PRD を Issue に変換する

このスキルでは、内容が明確になった PRD を、垂直スライスに分割された小規模で明確なバックログに変換します。各 Issue は、関連するすべてのレイヤーをエンドツーエンドで横断する、独立して着手できる「トレーサーバレット」にします。未知の未知をできるだけ早く明らかにすることが目的です。

使用するタイミング

次のような場合に、このスキルを使用します。

• ユーザーが PRD または同様の仕様（/spec-writer で作成したものなど）を持っており、具体的な Issue に落とし込みたい。
• 「目的地」を示すドキュメントを、タスクのカンバンボードに変換したい。
• 複数のエンジニアやエージェントが互いの作業を妨げずに並行して取り組めるよう、作業を分割したい。

まだ PRD がない場合や要件が曖昧な場合は、まず /grill-me と /spec-writer の使用を提案してください。

概念

• 垂直スライス／トレーサーバレット： 必要なすべてのレイヤー（データ、ドメイン、API、UI など）をエンドツーエンドで通る、薄く切り出した機能の一部です。単一のレイヤーだけを対象にするものではありません。
• HITL Issue： Human-In-The-Loop による判断（デザインレビュー、関係者の承認、リスクの高いリファクタリングなど）が必要な Issue です。
• AFK Issue： 人間が「キーボードから離れている」間でも、自律型エージェントが人間の介入なしに実装してマージできるほど安全な Issue です。

可能な場合は AFK スライスを優先し、人間の判断が不可欠な場合は HITL と明確に示してください。

ワークフロー

コンテキストにすでに答えが含まれている場合（たとえば PRD がすでに読み込まれていて、対象範囲が明確な場合）は、手順を短縮または省略してかまいません。

1. PRD を見つけて理解する

   • 会話またはリポジトリ（Issue、ドキュメント、ファイル）から PRD を見つけます。
   • 目標、ユーザーストーリー、機能要件、明示的な対象外事項を把握できるよう、内容をざっと読みます。
   • 複数の PRD がある場合は、どれを使用するかユーザーに確認します。

2. コードベースを調査する

   • リポジトリの関連部分を確認し、現在のアーキテクチャ、主要なモジュール、統合が必要になりそうな箇所を把握します。
   • 尊重すべき既存のパターン（既存の機能フラグ、バックグラウンドジョブ、通知システムなど）があれば記録します。

3. 垂直スライス（トレーサーバレット）を作成する

   • PRD を少数の垂直スライスに分割します。各スライスはエンドツーエンドの価値を提供し、システムの複数のレイヤーを通して動作を確認できるものにします。
   • 「データベースのテーブルを設定する」や「UI コンポーネントをすべて作る」のような水平スライスは、本当に必要な場合を除いて避けます。代わりに、エンドツーエンドのスライスに組み込みます。
   • 各スライスについて、HITL と AFK のどちらにするか決めます。リスクが低い場合は AFK を優先します。

4. Issue の構成と依存関係を定義する 各スライスについて、次の項目を定義します。

   • タイトル： 短く、内容がわかりやすく、ユーザー価値に直接結びついているもの。
   • タイプ： HITL または AFK。
   • 説明： この Issue で提供する内容と、関連するユーザーストーリーおよび PRD のセクション。
   • 受け入れ条件： エッジケースを含む、明確でテスト可能な条件。
   • ブロックされる条件： 先に完了する必要がある他のスライス（あれば）。

   すぐに着手できる、ブロックされていない Issue を少なくとも 1 つ特定します。

5. ユーザーに確認して反復する 提案する分解内容をスライスの番号付きリストとして提示し、次の項目を含めます。

   • タイトル
   • タイプ（HITL／AFK）
   • ブロックされる条件
   • 対応するユーザーストーリー

   次の点をユーザーに確認します。

   • 粒度は適切ですか（粗すぎる、細かすぎるなど）？
   • 依存関係は正しいですか？
   • スライスを統合または分割すべきですか？
   • HITL と AFK の分類は適切ですか？

   ユーザーが分解内容を承認するまで調整します。

6. GitHub ですぐに使える Issue を生成する 承認された各スライスについて、次の内容を含む、GitHub ですぐに使える Issue 本文（Markdown）を生成します。

   • コンテキストの概要
   • 詳細なタスクの説明
   • 受け入れ条件
   • PRD および関連 Issue へのリンク
   • HITL／AFK のフラグと、人間のレビュアー向けの注意事項

   リポジトリの慣例が明確であれば、任意でエピックやラベルにまとめます。

動作とルール

1. 数十もの細かな課題ではなく、少数の効果の高いスライスを優先します。
2. すべての課題は、PRD とリポジトリがあれば、追加の確認を最小限に抑えて実装できるものにします。
3. 広範な基盤整備を行ってもユーザーに変化が見えないものより、システム内の狭くても実際に使える経路を開く垂直スライスを優先します。
4. HITL 作業は必ず明示して注記し、人間による判断を AFK 課題に隠してはいけません。
5. PRD に重要な詳細が欠けている場合は、推測せず、要点を絞った確認質問を少数尋ねるか、/spec-writer に戻ることを提案します。

例

入力： チーム管理者向けの週次サマリーメール機能について、詳細なユーザーストーリーと要件が記載された PRD。

あなた：

1. PRD ファイルまたは課題を見つけ、目標、ユーザーストーリー、対象外事項をざっと確認します。
2. リポジトリを調べ、既存の通知およびメール関連の仕組みを探します。
3. 次のような垂直スライスを 3～5 個提案します。
   • 「週次の管理者向け指標を計算するエンジン（AFK）」
   • 「管理者が設定できるサマリーメールテンプレート（HITL）」
   • 「週次サマリーメールのスケジュール設定と送信（AFK）」
   • 「週次サマリーをプレビューして有効化する管理者向け UI（HITL）」
4. これらをタイプ、依存関係、対応するユーザーストーリーとともに提示し、ユーザーのフィードバックを踏まえて調整します。
5. 各スライスの最終的な GitHub 課題の本文を出力します。貼り付けるか、API で作成できる形式にします。