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、Rails 的 db/migrate/、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. 提出澄清问题

有些信息无法可靠地自动检测。请将以下问题合并为一条消息，一次性询问用户——不要逐个提问：

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>，开始开发第一个功能