claude-vault/skills/init-project/SKILL.md

---
name: init-project
description: Initialisiert die .claude/ Projektstruktur mit project-code-reviewer Agent, project-todo und project-review-todo Skills, sowie code-review/ und todos/ Ordnern. Analysiert den Tech-Stack automatisch.
argument-hint: "[optional: pfad zum projekt]"
allowed-tools: Read, Write, Edit, Glob, Grep, Bash, WebSearch
---

# Project Init - Claude Code Projektstruktur

Erstellt eine vollstaendige `.claude/`-Struktur fuer jedes Projekt. Analysiert automatisch den Tech-Stack und generiert projektspezifische Agents und Skills.

## Wann verwenden

- Neues Projekt starten und Claude Code Infrastruktur einrichten
- Bestehendes Projekt um Review- und Todo-Tracking erweitern
- `/init-project` in einem beliebigen Projektverzeichnis ausfuehren

## Was wird erstellt

```
.claude/
├── agents/project-code-reviewer.md     # Projektspezifischer Code-Review Agent
├── code-review/                        # Code-Review Findings (P0-P4)
│   └── .gitkeep
├── todos/                              # Feature-Todos, Bugfixes, Verbesserungen
│   └── .gitkeep
└── skills/
    ├── project-todo/SKILL.md           # Erstellt Todos im .claude/todos/ Ordner
    └── project-review-todo/SKILL.md    # Erstellt Review-Findings im .claude/code-review/ Ordner
```

**Namenskonvention:** `project-*` Prefix vermeidet Kollisionen mit globalen Claude-Skills/Agents (`create-todo`, `code-review-todo`, `code-reviewer`).

## Workflow

### Schritt 1: Projekt analysieren

Sammle den vollstaendigen Projektkontext. Lies diese Dateien (falls vorhanden):

1. **CLAUDE.md** - Hauptquelle fuer Architektur, Konventionen, Commands
2. **package.json** - Frontend: Framework, Dependencies, Scripts
3. **requirements.txt** / **pyproject.toml** - Backend: Python Dependencies
4. **Cargo.toml** / **go.mod** - Andere Sprachen
5. **docker-compose.yml** / **Dockerfile** - Deployment-Setup
6. **tsconfig.json** / **next.config.*** - TypeScript/Next.js Config

Extrahiere daraus:

| Info | Beispiel |
|------|---------|
| **Sprache(n)** | Python 3.13, TypeScript 5.x |
| **Framework(s)** | Django 6.0, Next.js 16 |
| **Datenbank** | PostgreSQL 18, SQLite |
| **Package Manager** | npm, pip, cargo |
| **Test-Framework** | pytest, Vitest, Jest |
| **Test-Command** | `npm run check`, `python manage.py test` |
| **Lint-Command** | `ruff check`, `eslint` |
| **Architektur-Typ** | Monolith, Monorepo, Microservices |
| **Hauptverzeichnisse** | Apps, Module, Packages |
| **Key Models/Components** | Die wichtigsten Datenstrukturen |
| **API-Patterns** | ViewSets, @api_view, tRPC, REST |
| **Auth-Pattern** | JWT, Session, OAuth |
| **State Management** | React Query, Zustand, Redux |

### Schritt 2: Bestehende Struktur pruefen

```bash
# Pruefe was bereits existiert
find .claude -type f 2>/dev/null | sort
```

**Regeln:**
- Bestehende Dateien NICHT ueberschreiben (warnen und ueberspringen)
- Bestehende Ordner wiederverwenden
- Nur fehlende Teile ergaenzen

### Schritt 3: Verzeichnisse anlegen

```bash
mkdir -p .claude/{agents,code-review,todos,skills/project-todo,skills/project-review-todo}
touch .claude/code-review/.gitkeep .claude/todos/.gitkeep
```

### Schritt 4: Code-Reviewer Agent erstellen

Erstelle `.claude/agents/project-code-reviewer.md` mit diesem Geruest. **Passe den Inhalt vollstaendig an den erkannten Tech-Stack an:**

~~~markdown
---
name: project-code-reviewer
description: >
  Projektspezifischer Code-Review Agent fuer [PROJEKTNAME].
  Analysiert Code auf Security, Performance, Architektur und Best Practices.
  Erstellt strukturierte Todo-Dateien in .claude/code-review/ im code-review-todo Format.
  Nutzt Web-Recherche um aktuelle Best Practices zu verifizieren.
model: sonnet
color: cyan
allowed-tools: Read, Glob, Grep, Write, Edit, Bash, WebSearch, WebFetch
---

Du bist ein erfahrener Code-Review-Spezialist fuer das **[PROJEKTNAME]** Projekt. Du analysierst Code systematisch und erstellst strukturierte Todo-Dateien fuer jedes Finding.

## Projektkontext

### Tech-Stack
[GENERIERT: Alle erkannten Technologien mit exakten Versionsnummern]

### Architektur
[GENERIERT: Hauptverzeichnisse, Apps/Module, Key Patterns]

### Wichtige Patterns
[GENERIERT: Projektspezifische Code-Konventionen und Patterns]

## Review-Prozess

### Schritt 1: Kontext sammeln

1. Lies `CLAUDE.md` fuer aktuelle Projektkonventionen
2. Identifiziere den Review-Scope
3. Nutze `git diff` oder `git log` um kuerzliche Aenderungen zu verstehen
4. Lies die betroffenen Dateien vollstaendig

### Schritt 2: Systematische Analyse

[GENERIERT: Checklisten passend zum Tech-Stack. Beispiele:]

**Fuer Python/Django Projekte:**
- Security (Secrets, Auth, CSRF, XSS, SQL-Injection)
- Performance (N+1 Queries, Indexes, Bulk Ops)
- Django Best Practices (Fat Models, Migrations, on_delete)
- DRF/API (Serializer, Pagination, Status Codes)

**Fuer TypeScript/Next.js Projekte:**
- Security (XSS, Token-Handling, Server-Only Secrets)
- Performance (Bundle Size, Re-Renders, Server Components)
- Next.js Patterns (App Router, use client, Metadata)
- React/TypeScript (keine any-Types, Keys, useEffect Cleanup)

**Fuer Fullstack Projekte:**
- Beide Checklisten kombiniert, nach Frontend/Backend getrennt

**Fuer Rust/Go/andere Projekte:**
- Sprachspezifische Checklisten (Memory Safety, Error Handling, Concurrency)

### Schritt 3: Prioritaet klassifizieren

| Prioritaet | Tag | Kriterien | Beispiele |
|------------|-----|-----------|-----------|
| **Kritisch** | `P0` | Security-Luecke, Datenverlust, kaputte Auth | [ANGEPASSTE BEISPIELE] |
| **Hoch** | `P1` | Performance-Crash, Datenkorruption, UX-Bruch | [ANGEPASSTE BEISPIELE] |
| **Wichtig** | `P2` | Inkonsistente Patterns, Wartbarkeitsrisiko | [ANGEPASSTE BEISPIELE] |
| **Mittel** | `P3` | Code-Qualitaet, Dead Code | [ANGEPASSTE BEISPIELE] |
| **Niedrig** | `P4` | Stilistik, Dokumentation | [ANGEPASSTE BEISPIELE] |

### Schritt 4: Best Practice recherchieren

1. Projekt-Konventionen (CLAUDE.md, bestehender Code)
2. Framework-Docs ([FRAMEWORK] [VERSION])
3. Referenz im Projekt finden
4. Web-Recherche bei Bedarf

### Schritt 5: Todo-Datei erstellen

**Dateiname-Format:** `P[0-4]-[thema]-[kebab-case-beschreibung].md` in `.claude/code-review/`

**Thematische Tags (immer diese 9 verwenden):**

| Tag | Verwendung |
|-----|------------|
| `security` | Secrets, XSS, CSRF, Injection, Headers, Cookies |
| `auth` | Authentifizierung, Autorisierung, Permissions, Tokens |
| `performance` | Queries, N+1, Indexes, Caching, Bundle Size, Re-Renders |
| `architecture` | God-Models, Modulgrenzen, Patterns, Strukturelle Bedenken |
| `error-handling` | Exceptions, try/catch, Error Boundaries, Fehlerbehandlung |
| `api` | Endpoints, Serializer, Status Codes, Pagination |
| `bug` | Fehlerhaftes Verhalten, Datenkorruption, Logic Errors |
| `config` | Settings, Environment, Dependencies, Feature Flags |
| `cleanup` | Dead Code, Imports, Naming, Deprecations, Debug-Reste |

Beispiel: `P1-performance-n-plus-1-scenario-list.md`

[TEMPLATE mit sprachspezifischen Code-Bloecken - python/typescript/rust/go]

## Regeln

1. **Verifizieren vor Schreiben** - immer die Source-Datei lesen.
2. **Ein Finding pro Datei** - separate Todos fuer unabhaengige Issues.
3. **Projekt-Code referenzieren** - exakte Datei, Zeilennummer, Code-Snippet.
4. **Positiv-Beispiel finden** - korrektes Pattern referenzieren.
5. **Versions-bewusst** - Dependency-Dateien pruefen.
6. **Keine Fehlalarme** - bei Unsicherheit weiter untersuchen.
7. **Sprache: Deutsch** - alle Todos auf Deutsch.
8. **Bestehende Todos pruefen** - Duplikate vermeiden.
9. **Web-Recherche nutzen** - aktuelle Docs verifizieren.
~~~

### Schritt 5: Project-Todo Skill erstellen

Erstelle `.claude/skills/project-todo/SKILL.md`:

~~~markdown
---
name: project-todo
description: Erstellt Todo-Dateien im .claude/todos/-Ordner. Kennt [TECH-STACK STICHWORTE]. Fuer Feature-Requests, Bugfixes und Verbesserungen.
argument-hint: <beschreibung des todos>
allowed-tools: Read, Write, Edit, Glob, Grep
---

# [PROJEKTNAME] Todo Generator

Erstellt strukturierte Todo-Dateien im `.claude/todos/`-Ordner.

## Projektkontext

### Tech Stack
[GENERIERT: Kompakte Tech-Stack Uebersicht]

### Hauptverzeichnisse
[GENERIERT: Die wichtigsten Verzeichnisse und was sie enthalten]

## Workflow

### Schritt 1: Kontext erfassen
1. Lies die Benutzeranfrage
2. Identifiziere den betroffenen Bereich
3. Falls unklar, suche mit Glob/Grep

### Schritt 2: Todo erstellen

Erstelle eine Datei in `.claude/todos/`:

```markdown
# [Kurzer, praegnanter Titel]

**Status:** Offen
**Prioritaet:** P[0-4] - [Kritisch|Hoch|Wichtig|Mittel|Niedrig]
**Bereich:** [GENERIERT: Projekt-spezifische Bereiche]

## Beschreibung
[Was soll gemacht werden]

## Anforderungen
1. [Konkrete Anforderung]

## Betroffene Dateien
- `pfad/datei` - [Was aendern]

## Technische Hinweise
[Relevante Patterns]

## Akzeptanzkriterien
- [ ] Kriterium
```

### Schritt 3: Dateiname waehlen

**Format:** `P[0-4]-[typ]-[kebab-case-beschreibung].md`

**Prioritaet:**

| Prio | Kriterien |
|------|-----------|
| `P0` | Blockiert Entwicklung, Security-Fix, Datenverlust |
| `P1` | Wichtiges Feature, schwerwiegender Bug |
| `P2` | Verbesserung, mittlerer Bug, technische Schuld |
| `P3` | Nice-to-have, kleine Verbesserung |
| `P4` | Kosmetik, Dokumentation, irgendwann |

**Typ-Tags:**

| Tag | Verwendung |
|-----|------------|
| `feature` | Neue Funktionalitaet |
| `bugfix` | Fehlerbehebung |
| `enhancement` | Verbesserung bestehender Features |
| `refactor` | Code-Umstrukturierung ohne Funktionsaenderung |
| `infra` | Build, CI/CD, Deployment, Dependencies |
| `test` | Tests hinzufuegen oder verbessern |
| `docs` | Dokumentation |

## Haeufige Bereiche
[GENERIERT: Die 4-6 wichtigsten Bereiche mit Dateipfaden]

## Best Practices
1. **Spezifisch sein** - Konkret beschreiben, nicht vage
2. **Dateien angeben** - Immer konkrete Pfade
3. **Patterns referenzieren** - Auf bestehende Loesungen verweisen
4. **Keine Implementierung** - Nur beschreiben WAS, nicht WIE
~~~

### Schritt 6: Project-Review-Todo Skill erstellen

Erstelle `.claude/skills/project-review-todo/SKILL.md`:

~~~markdown
---
name: project-review-todo
description: Erstellt Code-Review Todo-Dateien mit Problemanalyse, Impact-Bewertung und Best-Practice-Empfehlungen. Fuer Security, Performance und Architektur-Findings.
argument-hint: "[problembeschreibung oder dateipfad]"
allowed-tools: Read, Glob, Grep, Write, Edit, Bash, WebSearch
---

# Code Review Todo Creator - [PROJEKTNAME]

Erstellt strukturierte Code-Review Finding-Dateien in `.claude/code-review/`.

## Projektkontext
[GENERIERT: Kompakter Tech-Stack und Architektur-Ueberblick]

## Workflow

### Schritt 1: Kontext sammeln
1. Lies `CLAUDE.md`
2. Finde betroffene Dateien mit Glob/Grep
3. Lies und bestatige das Issue
4. Pruefe Framework-Versionen

### Schritt 2: Prioritaet klassifizieren

| Prioritaet | Tag | Kriterien |
|------------|-----|-----------|
| **Kritisch** | `P0` | Security, Datenverlust, Auth |
| **Hoch** | `P1` | Performance, Korruption, UX-Bruch |
| **Wichtig** | `P2` | Patterns, Wartbarkeit |
| **Mittel** | `P3` | Code-Qualitaet, Dead Code |
| **Niedrig** | `P4` | Stilistik, Docs |

### Schritt 3: Best Practice recherchieren
1. Projekt-Konventionen
2. Framework-Docs ([VERSIONEN])
3. Referenz im Projekt
4. Web-Recherche

### Schritt 4: Dateiname
`P[0-4]-[thema]-[kebab-case].md` in `.claude/code-review/`

Thematische Tags: `security`, `auth`, `performance`, `architecture`, `error-handling`, `api`, `bug`, `config`, `cleanup`

### Schritt 5: Todo schreiben

```markdown
# [Praegnanter Titel]

**Status:** Offen
**Prioritaet:** P[0-4] - [Level] / [Kategorie]
**Bereich:** [Bereich] ([Dateigruppe])

## Beschreibung

### Was ist das Problem?
[Erklaerung + Code-Snippet]

### Warum ist das problematisch?
[Konsequenzen]

### Wie sollte es richtig gemacht werden?
[Kopierbarer Fix]

### Referenz im Projekt
[Positiv-Beispiel]

## Requirements
1. [Anforderung]

## Betroffene Dateien
- `pfad/datei` - Zeile XX: [Aenderung]

## Best Practice
> **Regel:** [Prinzip]

## Akzeptanzkriterien
- [ ] [Kriterium]
- [ ] [GENERIERT: Projekt-spezifischer Check-Command] laeuft fehlerfrei
```

## Regeln
1. **Verifizieren vor Schreiben** - Source lesen
2. **Ein Finding pro Datei**
3. **Projekt-Code referenzieren** - Datei, Zeile, Snippet
4. **Versions-bewusst** - Dependencies pruefen
5. **Sprache: Deutsch**
~~~

### Schritt 7: .gitignore aktualisieren

Fuege folgende Regeln zur `.gitignore` des Projekts hinzu (falls nicht bereits vorhanden).
Falls keine Root-`.gitignore` existiert, erstelle sie.

```gitignore
### Claude Code ###
.claude/*
!.claude/agents/
.claude/agents/*
!.claude/agents/project-code-reviewer.md
!.claude/skills/
!.claude/code-review/
!.claude/todos/
```

**Logik:**
- `.claude/*` → alles ignorieren (settings, memory, docs, sonstige lokale Dateien)
- `!.claude/agents/` + `.claude/agents/*` → Ordner erlauben, Inhalt ignorieren...
- `!.claude/agents/project-code-reviewer.md` → **Ausnahme**: der Code-Reviewer soll allen Entwicklern zur Verfuegung stehen
- `!.claude/skills/` → **tracked**: definiert Team-Konventionen
- `!.claude/code-review/` → **tracked**: Team-Roadmap fuer Code-Qualitaet
- `!.claude/todos/` → **tracked**: Feature-Backlog

### Schritt 8: Zusammenfassung ausgeben

Zeige dem User was erstellt wurde:

```
Projektstruktur initialisiert fuer [PROJEKTNAME]:

.claude/
├── agents/project-code-reviewer.md  # [TECH-STACK Stichworte]
├── code-review/                     # Review-Findings
├── todos/                           # Feature-Todos
└── skills/
    ├── project-todo/SKILL.md            # → .claude/todos/
    └── project-review-todo/SKILL.md     # → .claude/code-review/

Erkannter Stack: [FRAMEWORK VERSION, SPRACHE VERSION, ...]
```

## Wichtige Regeln

1. **Niemals ueberschreiben** - Bestehende Dateien in `.claude/` NICHT ueberschreiben. Warnung ausgeben und ueberspringen.
2. **Exakte Versionen** - Immer die tatsaechlichen Versionsnummern aus Dependency-Dateien verwenden, nicht raten.
3. **Projektsprache** - Wenn CLAUDE.md oder README auf Deutsch ist, alle generierten Inhalte auf Deutsch.
4. **Minimal aber vollstaendig** - Keine Checklisten-Punkte fuer Technologien die im Projekt nicht vorkommen.
5. **Code-Beispiele anpassen** - Template-Snippets in der Projektsprache (Python, TypeScript, Rust, Go, etc.).
6. **Bereiche aus dem Projekt** - Die "Haeufige Bereiche" Sektion im project-todo Skill muss die tatsaechlichen Verzeichnisse des Projekts abbilden, nicht generische Platzhalter.
7. **Check-Commands** - Akzeptanzkriterien muessen den tatsaechlichen Test/Lint-Command des Projekts verwenden (`npm run check`, `python manage.py test`, `cargo test`, `make test`, etc.).