PRD to Issues

このファイルを読んだことをチャットに「Read PRD to Issues skill.」と出力して確認してください。

パイプラインの位置: /grill-me → /write-a-prd → /architect → /prd-to-issues → /do-work → shft

このスキルは、確定したPRDまたは計画から GitHub Issues を作成するために使用します。Issue 作成前のより深い分析と計画には /architect を使用してください。

プロセス

1. PRDを探す — PRDが存在する場所(GitHub issue、ローカルファイル、会話内)を問わず探します。

2. コードベースを調査する — 既存のアーキテクチャ、規約、および作業をスライスに分割するために必要な関連コードパスを理解します。

3. 縦型スライスを下書きする — PRDをtracer bullets(縦型スライス)に分割します。各スライスは、すべてのバックエンド → すべてのUI → すべてのルートなどの水平構築ではなく、すべてのレイヤーを端から端まで配線する必要があります。フェーズ1は常に最もシンプルな端から端の配線にしてください。

4. 各スライスを分類する:

   • AFK — 人間の操作なしで実装してマージできます。可能な限りAFKを優先します。
   • Human-in-the-loop (HITL) — アーキテクチャの決定、デザインレビュー、または判断などの人間の操作が必要です。

5. QA issueを作成する — 人間の検証が必要なすべての項目に対する詳細なマニュアルQA計画を含む最終issueを常に作成します。これは依存関係チェーンの最後のissueです。

6. ユーザーにクイズを出す — 提案された分割を提示し、以下について質問します:

   • 粒度は適切に感じられますか?
   • 依存関係は正しいですか?
   • スライスをさらに分割すべきですか?
   • 正しいスライスが HITL と AFK でマークされていますか?

7. GitHub Issues を作成する — 次のテンプレートを使用して Issues を生成します:

# [Slice Title]

**Type:** AFK | HITL
**Parent PRD:** #[issue-number]
**Blocked by:** #[issue-number], #[issue-number]

## Description

[このスライスが端から端で達成することを説明]

## Acceptance Criteria

- [ ] [具体的で検証可能な基準]

ハンドオフ

Issues 作成後、以下を提供します:

1. /do-work — 最初のスライスの実装を開始
2. 計画を working/ に保存する — コンテキストが高い場合またはマルチセッションの作業の場合、標準ハンドオフプロトコル(@~/dotfiles/instructions/handoff.instructions.md)に従ってissueリストと依存関係の順序を保存します。親PRD issue への @-references を含めます。