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 を追加する
• 実装進行: 計画確定後の各実装セッションは本ファイル末尾「実装セッションでの進め方」に従う
• /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 をReadして使用
• 31_pr_briefs.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点に反映してから返答する（実装セッションは計画書しか読まないため、会話上の合意だけでは伝わらない）。

実装セッションでの進め方

担当PRを指定されたセッションで行う。

1. 30_plan.md と 31_pr_briefs.md を開き、担当PRのブリーフを特定する。ブリーフの見出しを推測せず、ファイル内を検索して一致を確かめる
2. ブリーフを入力にPhase 0-5（@context/workflow-rules.md）を適用する。PR単位より細かい作業分割が要る場合は references/task-template.md の形式でタスクファイルを作る
3. 完了したら 30_plan.md のPR状態を更新する。実装中に計画の前提が成り立たなくなったら、自分のPRの中だけで対処せず30_plan.md / 31_pr_briefs.md / 99_history.mdに反映してから進める（他の実装セッションは計画書しか読まない）

完了基準: 担当PRの完了条件を満たし、30_plan.mdの状態が実態と一致している。

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