add init skill
This commit is contained in:
martin
parent
48166e2521
commit
98c940dc13
385
skills/init-project/SKILL.md
Normal file
385
skills/init-project/SKILL.md
Normal file
@ -0,0 +1,385 @@
|
||||
---
|
||||
name: init-project
|
||||
description: Initialisiert die .claude/ Projektstruktur mit code-reviewer Agent, create-todo und code-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/code-reviewer.md # Projektspezifischer Code-Review Agent
|
||||
├── code-review/ # Code-Review Findings (P0-P4)
|
||||
│ └── .gitkeep
|
||||
├── todos/ # Feature-Todos, Bugfixes, Verbesserungen
|
||||
│ └── .gitkeep
|
||||
└── skills/
|
||||
├── create-todo/SKILL.md # Erstellt Todos im .claude/todos/ Ordner
|
||||
└── code-review-todo/SKILL.md # Erstellt Review-Findings im .claude/code-review/ Ordner
|
||||
```
|
||||
|
||||
## 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/create-todo,skills/code-review-todo}
|
||||
touch .claude/code-review/.gitkeep .claude/todos/.gitkeep
|
||||
```
|
||||
|
||||
### Schritt 4: Code-Reviewer Agent erstellen
|
||||
|
||||
Erstelle `.claude/agents/code-reviewer.md` mit diesem Geruest. **Passe den Inhalt vollstaendig an den erkannten Tech-Stack an:**
|
||||
|
||||
~~~markdown
|
||||
---
|
||||
name: 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: Create-Todo Skill erstellen
|
||||
|
||||
Erstelle `.claude/skills/create-todo/SKILL.md`:
|
||||
|
||||
~~~markdown
|
||||
---
|
||||
name: create-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:** Hoch | 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: `kebab-case-beschreibung.md`
|
||||
|
||||
## 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: Code-Review-Todo Skill erstellen
|
||||
|
||||
Erstelle `.claude/skills/code-review-todo/SKILL.md`:
|
||||
|
||||
~~~markdown
|
||||
---
|
||||
name: code-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: Zusammenfassung ausgeben
|
||||
|
||||
Zeige dem User was erstellt wurde:
|
||||
|
||||
```
|
||||
Projektstruktur initialisiert fuer [PROJEKTNAME]:
|
||||
|
||||
.claude/
|
||||
├── agents/code-reviewer.md # [TECH-STACK Stichworte]
|
||||
├── code-review/ # Review-Findings
|
||||
├── todos/ # Feature-Todos
|
||||
└── skills/
|
||||
├── create-todo/SKILL.md # → .claude/todos/
|
||||
└── code-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 create-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.).
|
||||
Loading…
x
Reference in New Issue
Block a user