Projekt-Dokumentations-Generator
Generiere strukturierte Projektdokumentation durch Analyse der Codebasis. Erstellt Dokumente, die den tatsächlichen Code widerspiegeln, nicht die angestrebte Architektur.
Wann verwenden
- Neues Projekt benötigt erste Dokumentation
- Dokumentation fehlt oder ist veraltet
- Einarbeitung neuer Teammitglieder in die Codebasis
- Aktualisierung der Dokumentation nach einem Refactoring
Workflow
1. Projekterkennung
Durchsuche das Projektverzeichnis, um den Projekttyp zu ermitteln:
| Indikator | Projekttyp |
|---|---|
wrangler.jsonc / wrangler.toml | Cloudflare Worker |
vite.config.ts + src/App.tsx | React SPA |
astro.config.mjs | Astro-Seite |
next.config.js | Next.js-App |
package.json mit hono | Hono-API |
src/index.ts mit Hono | API-Server |
drizzle.config.ts | Datenbankebene vorhanden |
schema.ts oder schema/ | Datenbankschema vorhanden |
pyproject.toml / setup.py | Python-Projekt |
Cargo.toml | Rust-Projekt |
2. Frage nach zu generierenden Dokumenten
Welche Dokumente sollen generiert werden?
1. ARCHITECTURE.md – Systemüberblick, Stack, Verzeichnisstruktur, Schlüsselabläufe
2. API_ENDPOINTS.md – Routen, Methoden, Parameter, Antwortformen, Authentifizierung
3. DATABASE_SCHEMA.md – Tabellen, Beziehungen, Migrationen, Indizes
4. Alle oben genannten
Biete nur Dokumente an, die zum Projekt passen. Biete keine API_ENDPOINTS.md für eine statische Seite an. Biete keine DATABASE_SCHEMA.md an, wenn es keine Datenbank gibt.
3. Scanne die Codebasis
Für jedes angeforderte Dokument lies die relevanten Quelldateien:
ARCHITECTURE.md – scanne:
package.json/pyproject.toml(Stack, Abhängigkeiten)- Einstiegspunkte (
src/index.ts,src/main.tsx,src/App.tsx) - Konfigurationsdateien (
wrangler.jsonc,vite.config.ts,tsconfig.json) - Verzeichnisstruktur (obere 2 Ebenen)
- Schlüsselmodule und deren Exporte
API_ENDPOINTS.md – scanne:
- Routendateien (
src/routes/,src/api/oder inline im Index) - Middleware-Dateien (Authentifizierung, CORS, Logging)
- Request-/Response-Typen oder Zod-Schemas
- Fehlerbehandlungsmuster
DATABASE_SCHEMA.md – scanne:
- Drizzle-Schema-Dateien (
src/db/schema.ts,src/schema/) - Migrationsdateien (
drizzle/,migrations/) - Vorhandene rohe SQL-Dateien
- Seed-Dateien, falls vorhanden
4. Dokumentation generieren
Schreibe jedes Dokument in docs/ (erstelle das Verzeichnis, falls es nicht existiert). Wenn das Projekt bereits Dokumente dort hat, biete an, sie zu aktualisieren, anstatt zu überschreiben.
Bei kleinen Projekten ohne docs/-Verzeichnis schreibe in das Projektverzeichnis.
Dokumentvorlagen
ARCHITECTURE.md
# Architektur
## Überblick
[Ein Absatz: Was dieses Projekt tut und wie es strukturiert ist]
## Stack
| Ebene | Technologie | Version |
|-------|-------------|---------|
| Laufzeit | [z. B. Cloudflare Workers] | — |
| Framework | [z. B. Hono] | [Version] |
| Datenbank | [z. B. D1 (SQLite)] | — |
| ORM | [z. B. Drizzle] | [Version] |
| Frontend | [z. B. React 19] | [Version] |
| Styling | [z. B. Tailwind v4] | [Version] |
## Verzeichnisstruktur
[Kommentierter Baum – obere 2 Ebenen mit Zweckkommentaren]
## Schlüsselabläufe
### [Ablauf 1: z. B. „Benutzerauthentifizierung"]
[Schritt für Schritt: Anfrage → Middleware → Handler → Datenbank → Antwort]
### [Ablauf 2: z. B. „Datenverarbeitungspipeline"]
[Schritt für Schritt durch das System]
## Konfiguration
[Wichtige Konfigurationsdateien und was sie steuern]
## Bereitstellung
[Wie bereitgestellt wird, benötigte Umgebungsvariablen, Build-Befehle]
API_ENDPOINTS.md
# API-Endpunkte
## Basis-URL
[z. B. `https://api.example.com` oder relativ `/api`]
## Authentifizierung
[Methode: Bearer-Token, Session-Cookie, API-Key, keine]
[Woher Tokens kommen, wie sie bezogen werden]
## Endpunkte
### [Gruppe: z. B. Benutzer]
#### `GET /api/users`
- **Auth**: Erforderlich
- **Parameter**: `?page=1&limit=20`
- **Antwort**: `{ users: User[], total: number }`
#### `POST /api/users`
- **Auth**: Erforderlich (Admin)
- **Body**: `{ name: string, email: string }`
- **Antwort**: `{ user: User }` (201)
- **Fehler**: 400 (Validierung), 409 (E-Mail-Duplikat)
[Wiederhole für jeden Endpunkt]
## Fehlerformat
[Standard-Antwortstruktur bei Fehlern]
## Ratenbegrenzung
[Falls zutreffend]
DATABASE_SCHEMA.md
# Datenbankschema
## Engine
[z. B. Cloudflare D1 (SQLite), PostgreSQL, MySQL]
## Tabellen
### `users`
| Spalte | Typ | Einschränkungen | Beschreibung |
|--------|-----|-----------------|-------------|
| id | TEXT | PK | UUID |
| email | TEXT | UNIQUE, NOT NULL | Benutzer-E-Mail |
| name | TEXT | NOT NULL | Anzeigename |
| created_at | TEXT | NOT NULL, DEFAULT now | ISO-Zeitstempel |
### `posts`
[Gleiches Format]
## Beziehungen
[Fremdschlüssel, Join-Muster, Kaskadenregeln]
## Indizes
[Nicht-primäre Indizes und warum sie existieren]
## Migrationen
- Generieren: `npx drizzle-kit generate`
- Lokal anwenden: `npx wrangler d1 migrations apply DB --local`
- Remote anwenden: `npx wrangler d1 migrations apply DB --remote`
## Seed-Daten
[Verweis auf Seed-Skript, falls vorhanden]
Qualitätsregeln
- Dokumentiere, was existiert, nicht was geplant ist – lies den tatsächlichen Code, erfinde keine Endpunkte oder Tabellen
- Versionen einfügen – extrahiere aus package.json/lock-Dateien, nicht aus dem Gedächtnis
- Echte Antwortformen zeigen – kopiere aus TypeScript-Typen oder Zod-Schemas im Code
- Überblick behalten – Tabellen sind besser als Absätze, Codeblöcke besser als Prosa
- CLAUDE.md nicht duplizieren – wenn Architekturinformationen bereits in CLAUDE.md stehen, verschiebe sie entweder in ARCHITECTURE.md oder verweise darauf
- Lücken kennzeichnen – wenn du undokumentierte Routen oder Tabellen ohne klaren Zweck findest, markiere sie mit
<!-- TODO: Dokumentationszweck -->
Aktualisieren vorhandener Dokumente
Wenn Dokumente bereits existieren:
- Lies das vorhandene Dokument
- Vergleiche mit der aktuellen Codebasis
- Zeige dem Benutzer, was sich geändert hat (neue Endpunkte, entfernte Tabellen, aktualisierter Stack)
- Wende Aktualisierungen an und bewahre handschriftliche Notizen oder Abschnitte
Überschreibe niemals stillschweigend benutzerdefinierte Inhalte, die der Benutzer seinen Dokumenten hinzugefügt hat.