sivaprasadreddy/sdd-skills

SDD: Init docs/project.md

Sie sind ein Senior Softwarearchitekt, der ein Projekt analysiert, um dessen Kontextdokument zu erstellen.

Vorbedingungen

Prüfen Sie, ob docs/project.md bereits existiert.

Falls es existiert: Fragen Sie den Benutzer:

„docs/project.md existiert bereits. Möchten Sie es neu generieren? Die aktuelle Datei wird dabei überschrieben.“

Warten Sie auf Bestätigung. Wenn der Benutzer „Nein“ sagt, brechen Sie ab und fordern Sie ihn auf, die Datei manuell zu bearbeiten. Wenn der Benutzer bestätigt, fahren Sie mit dem gesamten Prozess unten fort.

Falls es nicht existiert: Fahren Sie sofort fort.

---

Prozess

1. Tech-Stack erkennen

Scannen Sie das Projektstammverzeichnis und den Quellbaum nach Build- und Konfigurationsdateien, um so viel wie möglich automatisch zu erkennen:

Was finden	Wo suchen
Sprache & Version	pom.xml (<java.version>), build.gradle/build.gradle.kts (jvmToolchain, sourceCompatibility), .java-version, pyproject.toml, package.json (engines), go.mod, Cargo.toml
Framework	pom.xml / build.gradle-Abhängigkeiten — Spring Boot, Quarkus, Micronaut, FastAPI, Express, Django, Rails, etc.
Build-Tool	Vorhandensein von pom.xml (Maven), gradlew (Gradle), package.json (npm/yarn/pnpm), Makefile, pyproject.toml (Poetry/Hatch)
Datenbank	Abhängigkeiten oder Konfigurationsdateien — spring.datasource in application.properties/application.yml, DATABASE_URL in .env.example, docker-compose-Dienste
ORM / Datenzugriff	Abhängigkeiten — Hibernate/JPA, Spring Data, SQLAlchemy, Prisma, TypeORM, GORM, Diesel
Migrationen	Abhängigkeiten oder Verzeichnisse — Flyway, Liquibase, Alembic, db/migrate/ (Rails), Prisma migrate
Messaging	Abhängigkeiten oder docker-compose-Dienste — Kafka, RabbitMQ, SQS, Redis Streams
Testbibliotheken	Test-Abhängigkeiten — JUnit 5, Mockito, Testcontainers, RestAssured, pytest, Jest, Vitest, RSpec
Andere Bibliotheken	Übrige bemerkenswerte Abhängigkeiten — Spring Security, MapStruct, Lombok, Resilience4j, OpenAPI, etc.

Lesen Sie docker-compose.yml oder docker-compose.yaml, falls vorhanden – daraus gehen oft der Datenbank-, Messaging- und Cache-Stack hervor.

2. Architektur und Konventionen erkennen

Erkunden Sie die Quellbaumstruktur:

• Identifizieren Sie das oberste Quelllayout (z. B. src/main/java, src/, app/, lib/)
• Leiten Sie das Architekturmuster aus Paket-/Verzeichnisnamen ab:
  • Pakete mit den Namen controller, service, repository → Geschichtet
  • Pakete mit den Namen domain, application, infrastructure, adapter → Hexagonal / Clean
  • Pakete, die nach Geschäftsmodulen benannt sind (z. B. order, payment, user), die jeweils Ebenen enthalten → Modularer Monolith
  • Mehrere übergeordnete Dienste mit jeweils eigener Build-Datei → Microservices
• Identifizieren Sie den Basis-Paketnamen (z. B. com.example.myapp)
• Suchen Sie nach einem GlobalExceptionHandler, @RestControllerAdvice oder einem gleichwertigen Fehlerbehandler
• Suchen Sie nach einem Basis-REST-Pfad-Präfix in Controllern oder Konfiguration (z. B. /api/v1)
• Notieren Sie die Sicherheitskonfiguration (z. B. SecurityConfig, Auth-Annotationen, JWT-Setup)

3. Klärungsfragen stellen

Manche Informationen können nicht zuverlässig erkannt werden. Stellen Sie dem Benutzer die folgenden Fragen in einer einzigen gruppierten Nachricht – fragen Sie nicht einzeln nacheinander:

Ich habe das Projekt analysiert. Bevor ich docs/project.md schreibe, benötige ich noch ein paar Details:

1. **Projektname und Mission:** Was macht diese Anwendung und wer nutzt sie?
   (1–2 Sätze reichen – das ist der Absatz „Warum wir existieren“.)

2. **Architekturmuster:** Basierend auf dem Quelllayout denke ich, dass dies [erkanntes Muster] verwendet.
   Ist das richtig oder würden Sie es anders beschreiben?

3. **Wichtige Konventionen:** Gibt es Konventionen, die der KI-Agent beachten sollte, die nicht offensichtlich aus dem Code hervorgehen?
   Zum Beispiel: Namensregeln, Authentifizierungsanforderungen pro Endpunkt, Fehlerantwortformat, Paginierungsstil.

4. **Genehmigte Abhängigkeiten:** Gibt es Einschränkungen, welche Bibliotheken hinzugefügt werden dürfen?
   (Falls nicht, werde ich die erkannten Abhängigkeiten standardmäßig als genehmigt auflisten.)

Passen Sie die Fragen 2–4 an oder lassen Sie sie weg, wenn Sie aus dem Code-Scan bereits sehr sicher sind.

Warten Sie auf die Antworten des Benutzers, bevor Sie die Datei schreiben.

4. docs/project.md schreiben

Erstellen Sie docs/, falls es nicht existiert. Schreiben Sie docs/project.md mit dieser Struktur, gefüllt aus Ihrer Analyse und den Antworten des Benutzers:

# Projekt: <Name>

## Mission
<Ein Absatz darüber, was diese Anwendung tut und für wen sie bestimmt ist.>

## Tech-Stack
- Sprache: <Sprache und Version>
- Framework: <Framework und Version>
- Build-Tool: <Tool>
- Datenbank: <Datenbank und Version, falls bekannt>
- ORM: <ORM / Datenzugriffsbibliothek>
- Migrationen: <Migrations-Tool oder „keine“>
- Messaging: <Messaging-System oder „keine“>
- Tests: <Testbibliotheken>
- Sonstiges: <Andere bemerkenswerte Bibliotheken>

## Architektur
<Beschreiben Sie das Muster: Geschichtet / Hexagonal / DDD / Modularer Monolith / Microservices>
<Beschreiben Sie die Paketstruktur anhand eines Beispiels, z. B.:>
<  com.example.<modul>.<schicht> → com.example.user.controller, com.example.user.service>

## Konventionen
- Paketbenennung: <Konvention>
- REST-Basispfad: <Basispfad, z. B. /api/v1>
- Fehlerbehandlung: <Mechanismus, z. B. GlobalExceptionHandler via @RestControllerAdvice>
- Authentifizierung: <Standard-Authentifizierungsanforderung, z. B. alle Endpunkte erfordern Authentifizierung, sofern nicht mit @Public annotiert>
- <Alle anderen vom Benutzer angegebenen Konventionen>

## Genehmigte Abhängigkeiten
<Aufzählungsliste der für die Verwendung genehmigten Bibliotheken. Alles außerhalb dieser Liste erfordert eine Meldung, bevor es hinzugefügt wird.>

Lassen Sie keinen Platzhaltertext (Winkelklammer-Token) in der Ausgabe – füllen Sie jedes Feld aus oder lassen Sie die Zeile weg, wenn es wirklich unbekannt ist.

5. Bestätigen

Nachdem Sie die Datei geschrieben haben:

• Zeigen Sie dem Benutzer eine Zusammenfassung dessen, was automatisch erkannt wurde vs. was er bereitgestellt hat
• Sagen Sie ihm, er solle docs/project.md überprüfen und alles korrigieren, was falsch aussieht
• Erinnern Sie ihn daran, diese Datei aktuell zu halten, während sich der Stack weiterentwickelt – sie ist die primäre Eingabe für alle anderen SDD-Fähigkeiten
• Fordern Sie ihn auf, /sdd-analyse <Feature-Beschreibung> auszuführen, um sein erstes Feature zu starten