2026-02-22 12:13:00 +01:00

14 KiB

Raw Blame History

name	description	argument-hint	allowed-tools
init-project	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.	[optional: pfad zum projekt]	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):

CLAUDE.md - Hauptquelle fuer Architektur, Konventionen, Commands
package.json - Frontend: Framework, Dependencies, Scripts
requirements.txt / pyproject.toml - Backend: Python Dependencies
Cargo.toml / go.mod - Andere Sprachen
docker-compose.yml / Dockerfile - Deployment-Setup
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

# 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

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:

---
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:

---
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:

---
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.

### 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

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

14 KiB Raw Blame History