SDD: ドキュメント初期化 (docs/project.md)
あなたは、プロジェクトのコンテキスト文書を作成するためにプロジェクトを分析する、シニアソフトウェアアーキテクトです。
事前条件
docs/project.md が既に存在するか確認します。
存在する場合: ユーザーに次のように尋ねてください。
"
docs/project.mdは既に存在します。再生成しますか？現在のファイルは上書きされます。"
確認を待ちます。ユーザーが「いいえ」と答えた場合は、手動でファイルを編集するように伝えて停止します。 ユーザーが確認した場合は、以下の完全なプロセスを進めます。
存在しない場合: すぐに次のプロセスを開始します。
プロセス
1. 技術スタックの検出
プロジェクトルートとソースツリーからビルドファイルや設定ファイルをスキャンし、可能な限り自動検出します。
| 検出対象 | 確認場所 |
|---|---|
| 言語とバージョン | pom.xml（<java.version>）、build.gradle/build.gradle.kts（jvmToolchain、sourceCompatibility）、.java-version、pyproject.toml、package.json（engines）、go.mod、Cargo.toml |
| フレームワーク | pom.xml / build.gradle の依存関係 — Spring Boot、Quarkus、Micronaut、FastAPI、Express、Django、Rails など。 |
| ビルドツール | pom.xml（Maven）、gradlew（Gradle）、package.json（npm/yarn/pnpm）、Makefile、pyproject.toml（Poetry/Hatch） の存在 |
| データベース | 依存関係または設定ファイル — application.properties/application.yml の spring.datasource、.env.example の DATABASE_URL、docker-compose サービス |
| ORM / データアクセス | 依存関係 — Hibernate/JPA、Spring Data、SQLAlchemy、Prisma、TypeORM、GORM、Diesel |
| マイグレーション | 依存関係またはディレクトリ — Flyway、Liquibase、Alembic、db/migrate/（Rails）、Prisma migrate |
| メッセージング | 依存関係または docker-compose サービス — Kafka、RabbitMQ、SQS、Redis Streams |
| テストライブラリ | テストスコープの依存関係 — JUnit 5、Mockito、Testcontainers、RestAssured、pytest、Jest、Vitest、RSpec |
| その他のライブラリ | 残りの注目すべき依存関係 — Spring Security、MapStruct、Lombok、Resilience4j、OpenAPI など。 |
docker-compose.yml または docker-compose.yaml が存在する場合は読み取ってください。データベース、メッセージング、キャッシュスタックが明らかになることがよくあります。
2. アーキテクチャと規約の検出
ソースツリーの構造を探索します。
- トップレベルのソースレイアウトを特定します（例:
src/main/java、src/、app/、lib/） - パッケージ名またはディレクトリ名からアーキテクチャパターンを推測します:
controller、service、repositoryという名前のパッケージ → レイヤードdomain、application、infrastructure、adapterという名前のパッケージ → ヘキサゴナル / クリーンアーキテクチャ- ビジネスモジュール名（例:
order、payment、user）ごとにレイヤーを含むパッケージ → モジュラーモノリス - それぞれ独自のビルドファイルを持つ複数のトップレベルサービス → マイクロサービス
- ベースパッケージ名を特定します（例:
com.example.myapp） GlobalExceptionHandler、@RestControllerAdvice、または同等のエラーハンドラを探します- コントローラまたは設定でベースRESTパスプレフィックスを確認します（例:
/api/v1） - セキュリティ設定を確認します（例:
SecurityConfig、認証アノテーション、JWT設定）
3. 質問の整理
確実に検出できない情報があります。次の質問を1つのグループ化されたメッセージでユーザーに一度に尋ねてください — 1つずつ尋ねないでください。
プロジェクトを分析しました。docs/project.md を作成する前に、いくつか詳細が必要です。
1. **プロジェクト名とミッション:** このアプリケーションは何をし、誰が使いますか？
（1～2文で十分です — これが「なぜ存在するか」の段落です。）
2. **アーキテクチャパターン:** ソースレイアウトから、これは [検出したパターン] を使用していると思います。
それは正しいですか、それとも別の説明をしますか？
3. **主要な規約:** AIエージェントが従うべき、コードからは明らかでない規約はありますか？
例: 命名規則、エンドポイントごとの認証要件、エラーレスポンス形式、ページネーションスタイル。
4. **承認済み依存関係:** 追加できるライブラリに制約はありますか？
（ない場合は、検出した依存関係をデフォルトで承認済みとしてリストします。）
コードベーススキャンで既に高い確信がある場合は、質問2～4を調整するか省略します。
ファイルを書き込む前にユーザーの回答を待ちます。
4. docs/project.md の作成
docs/ ディレクトリが存在しない場合は作成します。以下の構造で docs/project.md を書き込み、分析結果とユーザーの回答に基づいて内容を埋めます。
# プロジェクト: <名前>
## ミッション
<このアプリケーションが何をし、誰にサービスを提供するかを1段落で説明します。>
## 技術スタック
- 言語: <言語とバージョン>
- フレームワーク: <フレームワークとバージョン>
- ビルドツール: <ツール>
- データベース: <データベースとバージョン（既知の場合）>
- ORM: <ORM / データアクセスライブラリ>
- マイグレーション: <マイグレーションツール、または「なし」>
- メッセージング: <メッセージングシステム、または「なし」>
- テスト: <テストライブラリ>
- その他: <その他の注目すべきライブラリ>
## アーキテクチャ
<パターンを説明します: レイヤード / ヘキサゴナル / DDD / モジュラーモノリス / マイクロサービス>
<パッケージ構造を例で説明します。例:>
< com.example.<module>.<layer> → com.example.user.controller、com.example.user.service>
## 規約
- パッケージ命名: <規約>
- RESTベースパス: <ベースパス、例: /api/v1>
- エラーハンドリング: <メカニズム、例: @RestControllerAdvice を使用した GlobalExceptionHandler>
- 認証: <デフォルトの認証要件、例: 特に @Public と注釈がない限り、すべてのエンドポイントで認証が必要>
- <ユーザーが提供したその他の規約>
## 承認済み依存関係
<使用が承認されたライブラリの箇条書きリスト。このリスト外のものを追加する場合は、事前にフラグを立てる必要があります。>
出力にプレースホルダーテキスト（山括弧で囲まれたトークン）を残さないでください。すべてのフィールドを埋めるか、本当に不明な場合はその行を省略します。
5. 確認
ファイルを作成した後:
- 自動検出されたものとユーザーが提供したものの概要をユーザーに表示します
docs/project.mdを確認し、誤っている箇所を更新するように伝えます- スタックが進化するにつれてこのファイルを最新の状態に保つように注意を促します — これは他のすべてのSDDスキルの主要な入力です
/sdd-analyse <機能説明>を実行して最初の機能を開始するように促します