GEMINI.md

スペック駆動開発について

本プロジェクトでは、スペック駆動開発と呼ばれるプロセスで開発を行います。 スペック駆動開発では、要求仕様を策定し、その要求仕様をもとに設計を行い、 その設計を実現するための開発タスクを策定し、開発タスクに沿って開発を行います。

SPECS フォルダについて

生成 AI を利用したスペック駆動開発を行うためのドキュメントを格納するフォルダです。

フォルダ構成

• 要求仕様（要件）を記述するファイルは SPECS/requirements.md とする。
• 設計を記述するファイルは SPECS/design.md とする。
• 利用する技術スタックを記述するファイルは SPECS/tech.md とする。
• 開発タスクを記述するファイルは SPECS/tasks.md とする。

requirements.md の書き方

• ドキュメントの構成は以下の通り。
  • 概要
  • 前提条件
  • 制約条件
  • 要件
    • 要件 1: [要件名]
      • ユーザーストーリー
      • Acceptance Criteria
    • 要件 2: [要件名]
      • ユーザーストーリー
      • Acceptance Criteria
    • ...
    • 要件 N: [要件名]
      • ユーザーストーリー
      • Acceptance Criteria
• 要件は、ユーザーストーリーと Acceptance Criteria で構成される。
• Acceptance Criteria は EARS 記法（Easy Approach to Requirements Syntax）で記述する。
• Acceptance Criteria は一行で、日本語で記述する。
• 要件にはソフトウェアとしての設計（API、DBやパラメータ等）や実装を記載するのではなく、利用者などから見たシステムの機能や期待する振る舞いを記述する。
• 設計や実装は、設計書の方に記載する。
• ドキュメントの更新時は、中略や割愛をせずに、第三者がいつ読んでもすべてを理解できるように更新する必要がある。

design.md の書き方

• ドキュメントの構成は以下の通り。
  • アーキテクチャ
  • コンポーネント
  • インターフェース (Web API)
  • データモデル
  • エラーハンドリング
• design.md に記述する内容は、requirements.md と tech.md の踏まえて設計をすること。
• design.md に記述されている内容は、requirements.md と tech.md と整合していなければならない。
• ドキュメントの更新時は、中略や割愛をせずに、第三者がいつ読んでもすべてを理解できるように更新する必要がある。

変更依頼時のアクション

• 要件の変更を依頼された際は、その変更内容を設計および開発タスクに反映すべきかどうかを評価し、反映すべきであれば、設計および開発タスクを変更し、実装を変更する。
• 設計の変更を依頼された際は、その変更内容を要件および開発タスク、実装に反映すべきかどうかを評価し、反映すべきであれば、要件、開発タスクおよび実装を変更する。
• 実装の変更を依頼された際は、その変更内容を要件、設計および開発タスクに反映すべきかどうかを評価し、反映すべきであれば、要件、設計および開発タスクを変更し、実装を変更する。