sdd-init

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、ミドルウェア、エラーバウンダリ、または同等のもの）を探します
• コントローラーや設定にベース REST パスのプレフィックス（例：/api/v1）がないか探します
• セキュリティ設定（例：SecurityConfig、認証アノテーション、JWT の設定）があれば記録します

3. 確認のための質問をする

確実に検出できない情報もあります。以下の質問を 1 つのまとめたメッセージでユーザーに尋ねてください — 一度に 1 つずつ質問しないでください：

I've analysed the project. Before I write docs/project.md, I need a few details:

1. **Project name and mission:** What does this application do, and who uses it?
   (1-2 sentences is enough — this is the "why we exist" paragraph.)

2. **Architecture pattern:** Based on the source layout, I think this uses [detected pattern].
   Is that right, or would you describe it differently?

3. **Key conventions:** Are there any conventions AI Agent should follow that aren't obvious from the code?
   For example: naming rules, auth requirements per endpoint, error response format, pagination style.

4. **Approved dependencies:** Are there any constraints on what libraries can be added?
   (If not, I'll list the detected dependencies as approved by default.)

コードベースのスキャンからすでに高い確信がある場合は、質問 2～4 を調整または省略してください。

ファイルを書き込む前に、ユーザーの回答を待ちます。

4. docs/project.md を書き込む

docs/ が存在しない場合は作成します。分析とユーザーの回答に基づいて埋めた、次の構造で docs/project.md を書き込みます：

# Project: <Name>

## Mission
<One paragraph on what this application does and who it serves.>

## Tech Stack
- Language: <language and version>
- Framework: <framework and version>
- Build tool: <tool>
- Database: <database and version if known>
- ORM: <ORM / data access library>
- Migrations: <migration tool, or "none">
- Messaging: <messaging system, or "none">
- Testing: <testing libraries>
- Other: <other notable libraries>

## Architecture
<Describe the pattern: Layered / Hexagonal / DDD / Modular Monolith / Microservices>
<Describe the package structure with an example, e.g.:>
<  com.example.<module>.<layer>  →  com.example.user.controller, com.example.user.service>

## Conventions
- Package naming: <convention>
- REST base path: <base path, e.g. /api/v1>
- Error handling: <mechanism, e.g. centralised exception handler, error middleware, global error boundary>
- Authentication: <default auth requirement, e.g. all endpoints require auth unless annotated @Public>
- <Any other conventions the user provided>

## Approved Dependencies
<Bulleted list of libraries approved for use. Anything outside this list requires a flag before adding.>

出力にプレースホルダーテキスト（山括弧のトークン）を残さないでください — すべてのフィールドを埋めるか、本当に不明な場合はその行を省略してください。

5. 確認

ファイルを書き込んだ後：

• 自動的に検出されたものと、ユーザーが提供したものの概要をユーザーに示します
• docs/project.md をレビューし、誤っていると思われる箇所を更新するよう伝えます
• スタックの進化に合わせてこのファイルを最新の状態に保つよう促します — これは他のすべての SDD スキルの主要な入力です
• /sdd-feature <feature description> を実行して最初の機能を始めるよう促します