feature-plan

実装計画

概要

計画の構成の決定、開発フェーズの順序付け、確立された計画パターンに沿った実行可能なタスクの生成を支援する、構造化コマンドです。

確立された機能開発プロセスに沿って、実装計画のドキュメントを作成します。次のコンテキストを包括的に利用できます。

必読資料：

• 機能開発ガイド：@~/.local/share/dotfiles/ai/guides/feature-development-process.md
• ビジョンドキュメント：@vision.md
• 要件ドキュメント：@requirements.md
• 技術仕様：@spec.md

注：プロジェクトにガイドのローカルコピー（@project/guides/feature-development-process.md）がある場合は、プロジェクト固有の変更を反映したそちらを参照してもかまいません。

利用できる追加コンテキスト：

• コードベース全体：既存の実装パターンとアーキテクチャを確認します
• 実装ガイド：backend/docs/guides/ と frontend/docs/guides/ を確認し、確立されたアプローチを参照します
• テストガイド：テスト戦略については backend/docs/guides/testing/backend-testing-guide.md を参照します

アプローチ：利用可能なすべてのコンテキストを活用し、明確な順序付けと統合された開発フェーズを備えた、実用的な実装計画を作成します。

重要：まずTODOリストを作成し、計画作成の3つのフェーズを追跡します。最初のフェーズを「in_progress」、残りのフェーズを「pending」に設定します。

実装計画の構成

実装計画には次の内容を含めます。

• 開発フェーズと順序付け（いつ、どの順番で進めるか）
• 独自性のある新しい要素を詳述したコードブロック（使用言語の標準に沿った完全なドキュメントを含む）
• 確立されたコードのパターン参照（異なる点のみを記載）
• 各フェーズ内の粒度の細かいチェックボックスタスク
• ビジョン、要件（REQ-2.1.1、US-1.1.2 のようなIDを使用）、仕様書への相互参照

重要：

• 計画書に工数、時間数、所要時間の見積もりを含めないでください
• チェックリストのタスク自体を完了基準とするため、成功基準を別のセクションに設ける必要はありません
• コード詳細度の方針：
  • 独自性のある、新しい、複雑なコード：使用言語の規約に沿った完全なドキュメントを含め、詳細に記述します。開発者が計画の段階で内容を確認、理解し、反復改善できるようにします
  • 確立されたパターン：既存の実装を参照し、異なる点のみを記載します。定型コードは含めません
  • コードを含める場合は、完全なドキュメントを備えた、十分かつ詳細な内容にします
  • 目標は、新しいコードについて計画段階での反復を可能にし、重複する定型コードは一切省くことです

プロセス：次の3つのフェーズを順に進めます

フェーズ1：計画の構成を決定する

まず、技術仕様を分析し、計画書をどのように構成するかを決定します。

複雑さの分析：

1. 技術仕様を確認し、実装範囲を把握します
2. コードベース内の類似機能を調査し、パターンを確認します
3. チームの関与範囲（バックエンドのみ、フロントエンドのみ、フルスタック、デザイン作業）を評価します
4. 最適な計画の構成を決定します

構成の提案 — 理由を添えてアプローチを提案します。

• 単一の plan.md：対象が絞られた機能や単一領域の作業（バックエンドのみ、フロントエンドのみなど）の場合（推定500行未満）
• 領域ごとに分割：複雑なフルスタック機能の場合は、plan-backend.md + plan-frontend.md + plan-design.md に分割します
• tasks.md を分離：複雑な調整が必要な場合（複数の開発者、引き継ぎが発生する場合）のみ

次のように尋ねます。「仕様を分析した結果、[構成]をおすすめします。この構成でご希望に合っていますか？」

フェーズ 2：実装アプローチを設計する

実装アプローチとフェーズ構成を決定します。

計画活動：

• 実装範囲を分析し、大まかなフェーズ分割を決定します
• 独自の要素と確立されたパターンを特定します。新しい要素と定型的な要素を区別します
• フェーズ間の依存関係と順序の要件を特定します
• コードの配置方法（対象ファイル、ディレクトリ構成、既存パターンへの準拠）を決定します
• 複雑さの要因と、詳しい説明が必要な技術的課題を評価します
• 定型的な記述を最小限に抑えるため、計画では既存パターンを参照します。開発者が参考にできる既存の実装を明記します

情報収集：

• 次の点について具体的な質問をします：
  • 既存パターンでは対応できない、独自の実装アプローチ
  • この機能のテストの深さに関する希望
  • 実装に関する制約や希望

順序の検証：

• 大まかなフェーズ分割と根拠を含む実装順序の提案を提示します
• 順序を確認します：「この順序で問題ありませんか？見落としている依存関係はありますか？」
• ドキュメントの作成に進む前に、フェーズ間の依存関係と前提条件を検証します
• 実装アプローチと順序について明示的な承認を得ます

フェーズ 3：計画ドキュメントを生成する

フェーズ 2 の計画に基づいて、実際の計画ドキュメントを作成します。

• フェーズ 1 で決定したとおりに、plan.md または plan-[domain].md ファイルを生成します
• フェーズ 2 で設計したアプローチと構成を使って、実装フェーズを記述します
• 体系的なセクション番号（1.1、1.2、2.1、2.2 など）を付けた目次を含めます
• 各実装フェーズに実行可能なチェックボックス形式のタスクを追加します（これらのタスクが完了基準になります）
• 詳細度を適切に使い分けます：
  • 独自性のある新しいコード：使用する言語の規約に従い、ドキュメントを含む完全で詳細な実装を記載します
  • 確立されたパターン：既存の実装を参照し、異なる点だけを記載します
  • コードを含める場合は、計画レベルでのレビューと反復に十分な完成度にします
• 各フェーズがどの仕様セクションと要件を実装するかを説明するため、根拠と相互参照を含めます（spec.md#1.2 のような仕様参照と、REQ-2.1.1、US-1.1.2 のような要件 ID を使用します）
• 実装順序に焦点を当てた、明確で実践的な言葉を使います
• discussion-summary.md を更新します：
  • feature ディレクトリに discussion-summary.md が存在するか確認します
  • 存在する場合：「Plan Phase」セクションを追加し、次の内容を含めます：
    • 実装アプローチに関する議論
    • 順序の決定とその根拠
    • 計画中に行った方針転換
    • 計画に関する決定事項を Key Decisions Log に追加します（番号は続きから付けます）
    • 新たに参照したファイルを Technical Context に追加します
  • 存在しない場合：前のフェーズのプレースホルダーを含む完全な構成で作成します

ガイドライン

• コンテキストを最優先：計画を立てる前に、既存の計画と実装パターンを必ず分析してください
• 詳細度を選択する方針：
  • 新規／複雑なコード：フレームワークの規約に沿った、ドキュメントを完備した詳細なコードをすべて記載し、計画段階でのレビューと反復を可能にしてください
  • 確立されたパターン：既存の実装を参照し、違いのみを記載してください。定型コードを繰り返す必要はありません
  • コードを記載する場合は、開発者が計画の段階で理解し、リファクタリングできるだけの詳細を盛り込んでください
• パターンの参照：類似するコードが存在する場合は、定型コードを繰り返すのではなく、「X のパターンに従い、Y を調整する」と記載してください
• 計画の概要を必須とする：ドキュメントの冒頭に、簡潔な概要（構築するもの、主要コンポーネント、箇条書きの作業順序）を記載してください
• 前提条件をフェーズ 1 にする：外部のセットアップ、手動での設定、環境要件を、確認のみの手順であっても、最初の実装フェーズに含めてください
• 実行可能なタスク：実行可能なタスクと実装手順にはチェックボックスを使用してください
• 開発と検証を統合する：各フェーズには、適切な検証とデータを伴うコード実装を含めてください（別々の作業にしないでください）
• コードと検証の方針：
  • 実装フェーズでは新規／複雑なコードに重点を置いて詳細をすべて記載し、標準的なコードについては既存のパターンを参照してください
  • コードを記載する場合は、計画段階でレビューできるよう、フレームワークの基準に沿った完全なドキュメントを含め、詳細に記述してください
  • テストを含めてください。独自のロジックには詳細をすべて記載し、標準的なパターンについてはテストフレームワークに応じた参照を記載してください
  • 正式なテストパターンが存在しない場合は、スモークテスト、一時的なスクリプト、または手動検証を含めてください
  • 新しいデータモデルを作成するフェーズには、開発者が使える現実的なサンプルデータを含めてください
• テスト構成のパターン：新規性に応じて詳細度を選択してください
  • 標準的な CRUD／シンプルなパターン：既存のテストパターンを参照するだけにしてください（「X のテストパターンに従う」など）
  • 新規／複雑なテストロジック：テストフレームワークに応じた、テスト構成全体と実装の詳細をすべて記載してください
  • テストを含める場合は、計画段階でレビューし、反復できるだけの詳細を記載してください
  • 独自のテストシナリオは十分にレビューし、標準的な定型コードは省略できるようにしてください
• コードのドキュメント：新規コードには完全なドキュメントを付け、標準的なパターンでは省略してください
  • 標準的な CRUD／シンプルなパターン：開発者は既存の例を参照できるため、記載する必要はありません
  • 新規／複雑なコード：言語のドキュメント規約に沿って、すべてのパラメーター、戻り値、例、型情報、詳細な説明を含む完全なドキュメントを記載してください
  • ドキュメントを含める場合は、計画段階で全体を理解できるよう、十分かつ完全に記述してください
  • 使用する言語のドキュメント形式を使ってください（例：JSDoc、docstrings、YARD など）
  • 独自のコードには完全なドキュメントを付け、標準的な定型コードは一切記載しないでください
• 段階的な検証：手動テストが煩雑になる複雑な統合やエンドツーエンドのワークフローには、検証手順を含めてください
• サンプルデータを早期に用意：モデル間の依存関係によって難しい場合を除き、新しいバックエンドデータベースモデルには、開発の初期フェーズから現実的なサンプルデータを含めてください
• 根拠を必須とする：すべての実装フェーズを仕様の該当セクションと関連付けてください
• 既存パターンに従う：確立されたコードベースのパターンに基づいて実装方針を決めてください
• ドキュメントを必須とする：すべての実装計画の最終フェーズに、ドキュメント／ガイドの作成を含めてください
• 実装のみに重点を置く：開発の哲学、リスク軽減戦略、品質保証戦略のセクションは含めないでください。開発者は、ビジョン、要件、仕様、ガイドを参照できます
• 各フェーズの完了時に TODO リストを更新してください
• 実装フェーズの時期と順序に重点を置いてください
• 実装ガイドや類似機能を参照してください
• これまでのすべてのドキュメントを相互参照し、ビジネス面と技術面の背景を確認してください

はじめに

1. すぐに3フェーズのTODOリストを作成します
2. ユーザーに「作業中の機能ディレクトリはどこですか？フルパスを指定してください（例：project/features/FT033-feature-name）」と尋ねます
3. ユーザーに「ビジョン、要件、仕様のドキュメントに @vision.md @requirements.md @spec.md のタグを付けてください」と尋ねます
4. ディレクトリが存在することを確認し、計画ドキュメントの作成場所を確認します
5. すべての過去のドキュメントを確認し、機能のコンテキスト全体を把握します
6. 計画構成の分析と提案からフェーズ1を開始します
7. 提案の内容に集中し、確認を待ってから先に進みます