Plan Feature Prs

---
name: plan-feature-prs
description: 実装計画書とPR分割の立案。要件ソース・デザインファイル・既存実装が揃った機能開発（epic）を、並列調査と全体設計判断の確定を経て、機能単位のPRスタックと実装セッションに渡す計画書（30_plan.md + 31_pr_briefs.md）に落とし込む。使用タイミング: (1)「実装計画を立てて」「PR分割して」「計画書を作って」「このepicのタスク分割をして」等の依頼時、(2) 要件確定済みの複数PR規模の機能の実装着手前。境界: 要件定義そのものは design-feature、計画確定後の複数セッション実装の進行管理は large-task、単一PRで済む規模は Phase 0-5 を直接適用。
---

# Plan Feature PRs

要件が確定した機能開発を「実装セッションが詳細設計から始められる計画書 + 自己完結したPR別ブリーフ」に落とし込む。計画の価値は網羅ではなく、(1) 全体に係る設計判断を先に確定させること、(2) 各PRを独立して着手可能にすることにある。

## 既存設定との関係

- **Phase 0-5（@context/workflow-rules.md）**: Phase 0〜2 の具体化。本スキルの成果物が Phase 2 の計画書に相当する
- **メモリディレクトリ（@context/memory-file-formats.md)**: 既存構造を使用。`20_survey.md` / `30_plan.md` / `99_history.md` に加え `31_pr_briefs.md` を追加する
- **/large-task**: 本スキルは計画立案まで。計画確定後の実装は、各実装セッションに「30_plan.md + 31_pr_briefs.md を読んで担当PRを詳細設計→実装」と渡す（進行管理を強化したい場合は /large-task implement と併用可）
- **/design-feature**: 要件自体が曖昧な場合は先に design-feature で要件書を作る。本スキルは要件書・デザイン・既存実装が揃った後を担当する

## 前提の確認（着手時）

以下が揃っているか確認し、欠けていれば design-feature への切替か、ユーザーへの確認を行う:

- [ ] 要件ソース（仕様書ページ・要件書・issue 等）
- [ ] スコープ判定基準（「今回リリース必須」等のラベル・節構成。なければユーザーに確認）
- [ ] ベースブランチ戦略（epic branch の有無、PR の向き先）

## ワークフロー

### Step 1: スコープ確定

1. 要件ソースを取得し、スコープ判定基準で全セクションを対象 / 対象外に分類する
2. 対象外セクションでも、対象機能が書き込む共有リソース（DBカラム・共通部品）があれば対象PRに含める判断をし、計画書に理由付きで記載する
3. 関連する過去メモリ・issue を検索する（/findmem）。過去に確定済みの方針・撤回された案を把握する

**完了基準**: 要件ソースの全セクションに in/out 判定が付き、out の判断理由が 99_history.md に記録されている（@context/workflow-rules.md「実装計画書の記載範囲」: 計画書本体にはやることのみを書く）。

### Step 2: 既存実装調査（並列委譲 + lead 検証）

1. 調査領域を機能ドメイン単位で 2〜4 に分割し、Explore agent を並列 spawn する（**model: sonnet を明示**。@context/tool-claude-code.md「委譲判断」）。**経路は Agent tool**: `Explore` は書き込み不可で調査結果を lead に返すだけなので、委譲の既定である herdr pane に当たらない（@context/herdr-delegation.md「経路の選択」）
2. 各 agent への指示に含める: 対象リポジトリとアーキテクチャ概要 / 調査項目の列挙 / 報告形式「セクションごとに要点2-4文 + ファイルパス:行番号。存在しないものは『存在しない』と明記」
3. **lead 検証**: 報告のうち設計判断が依拠する主張（「この処理は存在しない」「この前提で動いている」等）を一次情報（コード）と突き合わせてから採用する
4. 統合結果を `20_survey.md` に記録する（各節に検証状況を注記）

**完了基準**: Step 4 の各設計判断が依拠する事実すべてに ファイルパス:行番号 の裏付けがある。

### Step 3: デザインファイル調査（ある場合）

1. **構造から入る**: まずメタデータ（セクション / フレーム一覧と node ID）を取得し、画面インベントリを作る。全画面のスクショを最初から撮らない
2. 設計判断に効く画面だけスクショで詳細確認する: 期限・文言などの仕様値が書かれた画面 / エラー・分岐画面 / 「議論中」「WIP」等のラベルが付いたセクション（**中身を見て正体を特定する**。実装対象そのものであることが多い）
3. 要件ソースに記載のない画面群を発見したら、スコープ判定に戻す（Step 1 の in/out 判断）

**完了基準**: 全画面がいずれかのPRに割り当てられ、未確定画面が「未確定事項」表に載っている。

### Step 4: 全体設計判断の確定

複数PRにまたがる設計判断をこの時点で確定し、**D1..Dn の番号付き**で計画書に記載する。対象の典型: 新テーブル・新ライブラリ / 認証・トークン方式 / セッション・状態管理方式 / 共通部品の拡張方針 / 横断的なテスト・E2E方針。

- **判断ゲート**: 機構拡大（新テーブル・新 enum・新ライブラリ・新インフラ）の扱いは AGENTS.md「中長期最適と機構追加」に従う（既存機構で回す案を出すなら中長期最適の案と並べて提示 → ユーザー確認。事前委任があれば自律決定し、比較検討と採用理由を `99_history.md` に記録）
- ライブラリ選定は候補比較（メンテ状況・依存数・型サポート）を実施してから決める
- 未確定仕様（デザイン議論中等）は「現行マスタで実装し、確定後に追随」等の暫定方針を明記してユーザーに確認する

**完了基準**: 実装セッションが判断に迷う横断的論点が残っていない（残る場合は「未確定事項」表に対応方針付きで載っている）。

### Step 5: PR 分割

1. 機能単位で分割する。粒度の目安: 1PR = 1実装セッションで詳細設計〜動作検証まで完了できる規模。大きい機能は「基盤（migration + usecase + API）」と「画面フロー」に分ける
2. 依存関係を確定する。スタック方式: base ← epic ← PR1(被依存) ← PR2。**依存PRは被依存PRの head branch を base に作成**（被依存のマージで base が自動で切り替わるプラットフォーム挙動を利用）
3. 実装順序を決める: 小さく独立したもの → 設計リスクの高いもの（早期に外部レビューへ）→ 依存チェーン
4. 横断的な後続PR（E2E まとめ等）が方針上あるなら分割図に含める

**完了基準**: 分割図に全PRの依存と順序が表現され、どのPRも「base・依存・担当機能」が一意に読める。

### Step 6: 成果物生成

- `30_plan.md`: [references/plan-template.md](references/plan-template.md) を Read して使用
- `31_pr_briefs.md`: [references/pr-brief-template.md](references/pr-brief-template.md) を Read して使用。**各PRブリーフは自己完結**（そのブリーフ + 30_plan.md + 20_survey.md だけで詳細設計に入れる）
- `99_history.md`: スコープ外判断（理由・再開条件）と自律決定（比較・採用理由）

**完了基準**: 31_pr_briefs.md の任意のPRを選び、「このブリーフだけ渡されて詳細設計に入れるか（対象・参照・完了条件が揃っているか）」の自問に全PRが通る。

### Step 7: 引き渡し

実装セッションへの標準の渡し方を完了報告に含める:

```
<メモリディレクトリ>/30_plan.md + 31_pr_briefs.md を読んで、
詳細計画の立案と実装を進めてください。担当: <PR記号>
```

計画確定後にユーザーから方針変更（E2E方針・スコープ変更等）があった場合は、30_plan.md / 31_pr_briefs.md / 99_history.md の3点に反映してから返答する（実装セッションは計画書しか読まないため、会話上の合意だけでは伝わらない）。

## Gotchas

- **デザインファイルのメタデータは巨大になり得る**: ツール出力がファイル退避された場合は jq/python で階層とノード名だけ抽出する。全文を読まない
- **「議論中」ラベルを未確定＝スコープ外と即断しない**: 中身を確認すると実装対象画面の文言バリエーション議論であることが多い。「現行マスタで実装+確定後追随」に倒せるかで判定する
- **サブエージェントの「存在しない」報告は要検証**: 不在の証明は grep 漏れと区別できない。lead が別パターンで再検索してから設計判断に使う
- **E2E・横断テストの扱いは計画時に決める**: 決めずに始めると実装途中で「各PRに同梱 / 専用PRでまとめ / 書かない」の判断が割れる。既存E2Eが壊れる分の修正は常に各PR持ち
- **対象外機能と共有するリソース**: 対象外（例: 管理画面表示）が読むだけのDBカラムでも、書き込むのが対象機能なら migration は対象PRに含める

## 入出力例

- 入力: 「この機能仕様ページの『今回リリース必須』の項目を実装したい。PRは機能単位で分けて、まず計画を立てて」
  → 出力: 20_survey.md（3領域の調査統合）+ 30_plan.md（設計判断 D1-D8、PR-A〜F の分割図）+ 31_pr_briefs.md（6本の自己完結ブリーフ）+ 未確定事項2件のユーザー確認
- 入力: 「epic ブランチ配下にPRを積む形でタスク分割して」
  → 出力: epic 起点のスタック分割図 + 依存PRの base 指定を明記したブリーフ

## 既存設定への参照

- @context/workflow-rules.md（Phase 0-5・実装計画書の記載範囲・検証機構）
- @context/memory-file-formats.md（メモリディレクトリ構造）
- 委譲判断・委譲後の実務: @context/tool-claude-code.md
- 委譲の経路・モデル・指示書の書き方・結果の回収: @context/herdr-delegation.md