Plan Feature PRs

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

本スキルは Phase 0-5 の Phase 0〜2 を具体化したもので、成果物が Phase 2 の計画書に当たる。着手前に context/workflow-rules.md と context/memory-file-formats.md を Read する。メモリディレクトリには通常の 20_survey.md / 30_plan.md / 99_history.md に加えて 31_pr_briefs.md を置く。要件自体が曖昧なら、先に /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 Phase 2）。

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

1. 調査領域を機能ドメイン単位で2〜4に分割し、Explore agent を Agent tool で並列に起こす。model: "sonnet" を渡す（調査の用途。表は context/delegation.md「モデルの選択」）。Explore は書き込まずに結果を返すだけなので、ファイルを書く委譲の経路（会話・pane）ではなく Agent tool を使う（同「経路の選択」）
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・新ライブラリ・新インフラ）は、中長期の最適で自分で決め、比較と採用理由を 99_history.md に残す（AGENTS.md「進め方の既定」）。レビュー指摘など他者由来の機構拡大はユーザーに確かめる（AGENTS.md「確認が要るもの」）
• ライブラリ選定は候補比較（メンテ状況・依存数・型サポート）を実施してから決める
• 未確定仕様（デザイン議論中等）は「現行マスタで実装し、確定後に追随」等の暫定方針を明記してユーザーに確認する

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

Step 5: PR 構成

1. 分割は AGENTS.md「コミット・ブランチ・PR」の分割条件に当たる箇所だけで行う。当たらない機能は1PRにまとめ、PR 内の段階は作業項目（taskboard の work_add）で表す。1セッションに収まるかどうかは分ける理由にしない（長時間の実装は1セッションで続けられるため）
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指定を明記したブリーフ