flowki@club:~$ Gerade gestartet · sei von Anfang an dabei

// cheat-sheet + prompts / claude code

Claude-Code-Toolkit (Deutsch)

Zwei Werkzeuge für den Alltag mit Claude Code: ein kompaktes deutsches Cheat-Sheet für Befehle, Prompt-Muster und Arbeits-Gates — plus 50 fertige Developer-Prompts mit Platzhaltern zum Kopieren.

Cheat-Sheet (Markdown) 50 Developer-Prompts (Markdown)

Kompakte Referenz für professionelle KI-gestützte Entwicklung mit Claude Code

Dieses Cheat Sheet richtet sich an Entwickler, die Claude Code (das offizielle CLI-Tool von Anthropic) produktiv einsetzen möchten. Es fasst die wichtigsten Befehle, Prompt-Muster, Projekt-Konfiguration und Best Practices zusammen.

Erstellt von der FlowKI-Community — https://flowki-club.de

1. Wichtigste CLI-Befehle & Slash-Commands

Session-Management

Agents & Skills

Arbeits-Modi

Kontext & Permissions

2. Prompt-Muster für Coding-Agenten

Grundprinzip: Role → Context → Task → Format

Schlecht:

Mach die Login-Funktion.

Gut:

Du bist ein Backend-Entwickler mit FastAPI-Expertise.

Context: Wir haben eine REST-API mit JWT-Auth (access + refresh tokens).
Die User-Daten liegen in PostgreSQL (SQLAlchemy ORM).

Task: Implementiere einen POST /auth/login Endpoint:
- Input: Pydantic-Schema (email, password)
- Validierung: bcrypt-Hash-Vergleich
- Output: access_token + refresh_token (15min / 7d)
- Error-Handling: 401 bei falschen Credentials, 422 bei invalider Email

Format: Production-ready Code, kein Stub. Unit-Tests für happy path + 401 + 422.
Gates: pytest grün, mypy --strict ohne Fehler.

Schrittweise Verifikation erzwingen

Implementiere [Feature] in kleinen Schritten:
1. Zuerst nur das Pydantic-Schema + Test dafür
2. Dann die Service-Logik + Integration-Test
3. Dann den Endpoint + E2E-Test

Stoppe nach jedem Schritt und zeige mir pytest-Output.
Erst bei grünem Test weitermachen.

Explizite Verbote setzen

Implementiere [Feature].

VERBOTE:
- Kein `pass`, `TODO`, `...` in Production-Code
- Keine ungepinnten Dependencies (kein ^, ~)
- Kein console.log/print() — nutze strukturiertes Logging
- Keine Secrets im Code — nur Env-Variablen

Definition of Done:
- Tests grün (zeig mir pytest-Output)
- Lint grün (zeig mir ruff/eslint-Output)
- Typcheck grün (zeig mir mypy/tsc-Output)

3. CLAUDE.md — Projektspezifische Regeln

Die CLAUDE.md-Datei im Projektroot ist der zentrale Ort für projektspezifische Anweisungen, die Claude Code bei jeder Session automatisch lädt.

Grundgerüst (Beispiel)

# Projekt: [Name]

## Stack
- Backend: FastAPI 0.115, Python 3.12, PostgreSQL 16
- Frontend: Next.js 15, React 19, TypeScript 5.6
- Testing: pytest, Playwright
- Deployment: Docker Compose

## Kritische Regeln

### Vor jeder Session (Startup-Protokoll)
[ ] CLAUDE.md lesen
[ ] Projektstand lesen (✅ / 🚧 / 🐛 Blöcke)
[ ] Aktive Bugs prüfen
[ ] Nächster Schritt bestätigen

### Definition of Done (DoD)
Jedes Feature ist erst fertig wenn:
[ ] Tests grün (`pytest`, `npm test`)
[ ] Lint grün (`ruff`, `eslint`)
[ ] Typcheck grün (`mypy --strict`, `tsc --noEmit`)
[ ] Manuell getestet (curl/Browser-Screenshot gezeigt)
[ ] Projektstand aktualisiert

### Verbote
❌ Kein Stub-Code (`pass`, `TODO`, `...`)
❌ Keine ungepinnten Dependencies
❌ Kein Auto-Retry bei Paid APIs ohne Rückfrage
❌ Keine Secrets in Git

## Standard-Befehle
```bash
# Development
make dev / docker compose up
make test / pytest -v
make lint / ruff check .
make migrate / alembic upgrade head

# Vor jedem Commit
make pre-commit  # = lint + typcheck + test

Projektstand

✅ Fertig

🚧 In Arbeit

🐛 Bugs


### Best Practices für CLAUDE.md
- **Kurz halten:** 200–500 Zeilen, nicht 2000 (sonst ignoriert der Agent Details)
- **Projektstand pflegen:** Nach jedem Feature ✅/🚧/🐛 aktualisieren
- **Importe nutzen:** `@docs/architecture.md` statt alles inline
- **Gates definieren:** Klare Erfolgskriterien (Tests grün, Lint grün, manuelle Verifikation)

---

## 4. MCP-Integration (Model Context Protocol)

MCP-Server erweitern Claude Code um Zugriff auf externe Tools und Datenquellen.

### Was ist MCP?
Das Model Context Protocol ist ein offener Standard für die Verbindung von LLMs mit externen Datenquellen, Tools und APIs. Ein MCP-Server stellt Tools (Functions) und Ressourcen (Read-Only-Daten) bereit, die Claude Code nutzen kann.

### Beispiele für MCP-Server
- **Filesystem:** Zugriff auf Dateien außerhalb des Projekts
- **Databases:** Direkter DB-Zugriff (PostgreSQL, MongoDB)
- **Browser:** Playwright-gesteuerte Browser-Automation
- **APIs:** GitHub, Jira, Slack, Discord
- **Memory:** Persistente Wissensdatenbank über Sessions hinweg

### Integration (konzeptionell)
1. MCP-Server installieren (z.B. `npm install -g @modelcontextprotocol/server-github`)
2. Server in `~/.claude/config.json` registrieren (Server-Befehl + Argumente)
3. Claude Code startet Server automatisch und nutzt dessen Tools

### Wichtig
- MCP-Server laufen lokal (localhost) — keine Cloud-Abhängigkeit
- Permissions gelten auch für MCP-Tools (Claude fragt bei sensiblen Operationen)
- Eigene MCP-Server können in Python/Node.js geschrieben werden (SDK vorhanden)

---

## 5. Hooks & Skills

### Hooks
Hooks automatisieren wiederkehrende Aktionen bei bestimmten Events (Session-Start, Code-Änderung, Fehler).

**Konzept:**
```json
{
  "hooks": {
    "onSessionStart": "Lies CLAUDE.md und zeige Projektstand",
    "beforeCommit": "Führe make pre-commit aus und zeige Ergebnis",
    "onTestFailure": "Analysiere Stack Trace, identifiziere Root Cause"
  }
}

Hooks werden in .claude/settings.json konfiguriert (projektspezifisch oder global).

Skills

Skills sind wiederverwendbare Mini-Workflows (Markdown-Dateien unter .claude/skills/).

Beispiel-Skill: /fix-tests

# fix-tests
Debugge fehlgeschlagene Tests:
1. Führe `pytest -v` aus und lies kompletten Output
2. Identifiziere erste fehlgeschlagene Test-Datei + Zeile
3. Lies Test-Code + getesteten Code
4. Analysiere Root Cause (nicht Symptom!)
5. Implementiere Fix
6. Führe `pytest [test-file] -v` aus und zeige Output
7. Erst bei grün: Frage ob weitere Tests gefixt werden sollen

Aufruf: Einfach /fix-tests in der Session eingeben.

6. Arbeits-Gates — Qualitätssicherung

Vor der Implementierung

[ ] Projektstand gelesen
[ ] Aufgabe in kleinste Einheit zerlegt
[ ] Betroffene Dateien identifiziert
[ ] Testplan definiert (happy path + Fehlerfälle)
[ ] Bei Unklarheit: NACHFRAGEN, nicht raten

Während der Implementierung

[ ] Eine Einheit auf einmal (ein Endpoint, eine Komponente)
[ ] Zuerst Test schreiben (TDD wenn möglich)
[ ] Dann Implementierung
[ ] Kein Stub-Code (pass, TODO, ...)
[ ] Nach jeder Datei: mentaler DoD-Check

Nach der Implementierung (Beweis-Protokoll)

[ ] `make test` → vollständige Ausgabe zeigen
[ ] `make lint` → vollständige Ausgabe zeigen
[ ] `make typcheck` → vollständige Ausgabe zeigen
[ ] Manueller Test: curl-Output ODER Screenshot zeigen
[ ] Projektstand aktualisieren
[ ] Erst dann nächste Einheit

Debugging-Protokoll

[ ] Komplette Fehlermeldung + Stack Trace lesen
[ ] Datei + Zeilennummer identifizieren
[ ] Root Cause finden (nicht symptomatisch patchen)
[ ] Fix implementieren
[ ] Reproduktionstest schreiben (vorher rot, nachher grün)
[ ] `make test` → alle grün
[ ] Projektstand aktualisieren

7. Häufige Anti-Patterns vermeiden

❌ Vage Aufträge

"Mach die App schneller." → Besser: "Analysiere /api/items — aktuell 2.3s Latenz. Vermutung: N+1 Query. Zeige mir EXPLAIN ANALYZE, dann optimiere."

❌ Implizite Annahmen

"Implementiere User-Login." → Besser: "Implementiere User-Login mit JWT (nicht Session-Cookies), bcrypt, PostgreSQL. Access-Token 15min, Refresh 7d."

❌ "Sollte funktionieren"

Agent behauptet Code ist fertig, zeigt aber keine Test-Ausgabe. → Nachhaken: "Zeig mir pytest -v Output. Erst bei grün weitermachen."

❌ Mehrere Features gleichzeitig

"Implementiere Login + Payment + Admin-Dashboard." → Besser: "Erst nur Login (DoD: Tests grün + curl-Beweis). Dann Payment. Dann Dashboard."

8. Quick-Tipps

Kontext optimieren

Kosten sparen

Sicherheit

Effizienz

9. Ressourcen

Lizenz: CC BY 4.0 — Frei nutzbar mit Quellenangabe (FlowKI-Community) Version: 1.0 (2026-08-03)

Sofort einsetzbare Prompts für tägliche Entwicklungsaufgaben mit KI-Assistenten

Diese Sammlung enthält 50 originale, praxiserprobte Prompts für Entwickler, die mit KI-Assistenten wie Claude, ChatGPT oder anderen Code-LLMs arbeiten. Jeder Prompt ist auf Deutsch formuliert, mit [Platzhaltern] versehen und direkt einsetzbar.

Erstellt von der FlowKI-Community — https://flowki-club.de

Frontend / UI (Prompts 1–7)

1. React-Komponente mit allen States

Erstelle eine React-Komponente [ComponentName] für [Zweck]. Die Komponente muss vier States abdecken: Loading (Skeleton), Error (Fehlermeldung mit Retry-Button), Empty (Platzhalter wenn keine Daten), Success (eigentlicher Inhalt). Nutze TypeScript für Props und Tailwind CSS für Styling. Mobile-First, responsiv ab 375px.

2. Form mit Validation

Implementiere ein Formular für [Zweck] mit den Feldern [field1, field2, field3]. Nutze React Hook Form mit Zod-Schema-Validierung. Zeige Fehler inline unter dem jeweiligen Feld, nicht als generische Fehlermeldung oben. Submit-Button disabled während der Validierung läuft. Zeige Success-State nach erfolgreichem Submit.

3. Barrierefreie Komponente

Reviewe die Komponente [ComponentName] auf Accessibility-Probleme. Prüfe: semantisches HTML, Keyboard-Navigation (Tab-Reihenfolge, Enter/Space für Buttons), ARIA-Labels wo nötig, Farbkontraste (mindestens WCAG AA), Focus-States sichtbar. Gib konkrete Code-Fixes für alle Findings.

4. Performance-Optimierung Frontend

Analysiere die Page [PageName] auf Performance-Probleme. Prüfe: unnötige Re-Renders (React DevTools Profiler), große Bundle-Größen (welche Dependencies sind schwer), fehlende Code-Splitting-Punkte, nicht optimierte Bilder (Format/Größe). Gib konkrete Optimierungsvorschläge mit Code-Beispielen.

5. Dark-Mode-Implementierung

Füge Dark-Mode-Support zur Komponente [ComponentName] hinzu. Nutze [CSS-Variables / Tailwind-dark-Klassen / styled-components-Theme]. Der Toggle soll die Präferenz im LocalStorage speichern und prefers-color-scheme als Default respektieren. Keine harten Farbwerte im Code — alles über Theme-Tokens.

6. Responsive-Layout debuggen

Das Layout [LayoutName] bricht auf [Breakpoint/Device]. Analysiere das Problem: Ist es ein Flexbox/Grid-Issue, ein fester width-Wert, oder Overflow durch zu breiten Content? Gib mir CSS-Fixes die das Layout flüssig zwischen 320px und 2560px machen, ohne Media-Query-Spaghetti.

7. Animationen mit Framer Motion

Erstelle eine Page-Transition für den Wechsel zwischen [RouteA] und [RouteB]. Nutze Framer Motion mit AnimatePresence. Die Transition soll smooth sein (Fade + leichter Slide), max 300ms Dauer. Stelle sicher dass exit-Animationen funktionieren (häufiger Fehler: fehlende key-Props). Respektiere prefers-reduced-motion.

Backend / APIs (Prompts 8–15)

8. REST-Endpoint mit vollem Error-Handling

Implementiere einen [POST/GET/PUT/DELETE] Endpoint [/api/path] in [FastAPI/Express/Django]. Input: Pydantic-Schema / Zod-Schema / Serializer mit den Feldern [field1, field2]. Implementiere Error-Handling für: 400 (Validation), 401 (Unauthenticated), 403 (Unauthorized), 404 (Not Found), 409 (Conflict), 500 (Internal Error). Jeder Error-Code mit aussagekräftiger Message. Rate-Limiting: [X requests/minute].

9. Datenbankabfrage optimieren

Die Query in [FunctionName] ist langsam ([Xms/s]). Zeige mir das SQL (oder ORM-Query), führe EXPLAIN ANALYZE aus, und erkläre wo das Problem liegt. Häufige Ursachen: N+1 Queries, fehlende Indexes, SELECT * statt gezielter Felder, zu breite JOINs. Gib optimierte Query + Index-DDL.

10. Auth-Middleware implementieren

Schreibe eine Auth-Middleware für [Framework] die JWT-Tokens validiert. Sie soll: Header Authorization: Bearer [token] parsen, Token-Signatur prüfen (Secret: [ENV_VAR]), Expiration checken, User-ID aus Payload extrahieren und in Request-Context setzen. Bei Fehler: 401 mit klarem Grund (expired / invalid / missing). Nutze Production-ready Library wie [PyJWT/jsonwebtoken/Django-Rest-Framework-SimpleJWT].

11. Paginierung für große Collections

Implementiere Cursor-basierte Paginierung für GET /api/[resource]. Die Antwort soll enthalten: data[] (Items), nextCursor (null wenn letzte Seite), hasMore (boolean). Nutze ein stabiles Sortier-Feld (z.B. created_at + id kombiniert). Keine Offset-Paginierung (bricht bei gleichzeitigen Inserts). Limit: [X items/page].

12. Hintergrund-Job mit Retry

Erstelle einen Background-Job [JobName] der [Aufgabe] erledigt. Nutze [Celery/BullMQ/Sidekiq]. Der Job soll: max 3 Retries bei Fehler, exponentielles Backoff (60s, 120s, 240s), Logging bei Start/Success/Failure mit allen relevanten IDs. Bei final failure: schreibe in Dead-Letter-Queue oder sende Alert. Idempotent (mehrfaches Ausführen darf keinen Schaden anrichten).

13. Rate-Limiter implementieren

Implementiere einen Token-Bucket-Rate-Limiter für [Endpoint/Service]. Limit: [X requests pro Y Zeiteinheit] pro [User/IP]. Nutze Redis für Distributed-State (mehrere App-Instanzen). Response bei Limit: 429 mit Header Retry-After: [seconds] und klarer Message. Wichtig: auch fehlgeschlagene Requests zählen (sonst Brute-Force möglich).

14. File-Upload mit Validation

Implementiere File-Upload für POST /api/upload. Erlaubte Typen: [.pdf/.jpg/.png], max Größe: [X MB]. Validiere: MIME-Type UND Dateiendung UND Magic-Bytes (nicht nur Extension prüfen — Security!). Generiere unique Filename (UUID + sanitized Original), speichere in [S3/lokales Volume]. Return: File-URL und ID. Prüfe auf Zip-Bombs und Malware-Uploads wenn sensibel.

15. Webhook-Handler mit Retry

Implementiere einen Webhook-Handler für POST /api/webhooks/[provider]. Validiere Webhook-Signatur (HMAC mit Secret: [ENV_VAR]). Extrahiere Payload, logge Event, führe Business-Logik aus. Wenn Verarbeitung fehlschlägt: return 500 damit Provider retried (viele Webhooks haben automatisches Retry). Idempotenz über event_id sicherstellen (nicht doppelt verarbeiten).

Datenbanken (Prompts 16–21)

16. Migration mit Daten-Backfill

Erstelle eine Migration die Spalte [old_column] umbenennt zu [new_column] in Tabelle [table_name]. Die Tabelle hat [X Millionen] Rows. Schreibe: (1) Neue Spalte hinzufügen (nullable), (2) Daten kopieren in Batches (max 10k/Batch), (3) NOT NULL Constraint setzen, (4) Alte Spalte löschen. Downgrade-Pfad: rückwärts durchführen. Nutze [Alembic/Knex/ActiveRecord].

17. Index für Query erstellen

Die Query [SQL/ORM-Query] ist langsam. Führe EXPLAIN ANALYZE aus und zeige mir den Query-Plan. Wenn Seq-Scan auf großer Tabelle: erstelle Index. Wenn Join langsam: prüfe ob Foreign-Key-Index fehlt. Wenn ORDER BY langsam: prüfe ob Index auf Sort-Spalte fehlt. Gib mir DDL für optimalen Index (auch Partial/Composite wenn nötig).

18. N+1 Query fixen

Die Funktion [FunctionName] hat ein N+1-Problem: Sie lädt [Model] in einer Schleife. Jeder Loop-Durchgang triggert eine separate DB-Query. Refactore auf: einen Query mit JOIN oder select_related / prefetch_related / include (ORM-abhängig), oder einen Bulk-Load vor der Schleife. Zeige Vorher/Nachher-Code und Query-Count.

19. Datenbank-Deadlock debuggen

Wir sehen regelmäßig Deadlocks in Tabelle [table_name]. Logge die aktuell laufenden Transaktionen (PostgreSQL: pg_stat_activity, MySQL: SHOW PROCESSLIST). Erkläre warum der Deadlock entsteht (welche Locks in welcher Reihenfolge). Gib Lösung: entweder Query-Reihenfolge ändern, oder pessimistic Lock mit SELECT FOR UPDATE nutzen, oder Transaction kürzer machen.

20. Datenbank-Schema normalisieren

Die Tabelle [table_name] hat wiederholte Daten in Spalten [field1, field2, field3] (Denormalisierung-Problem oder JSON-Blob). Schlage 3. Normalform vor: Welche neuen Tabellen brauchen wir? Welche Foreign-Keys? Schreibe Migrations (CREATE TABLE, Daten-Migration, ALTER TABLE). Erkläre Trade-off: Normalisierung = weniger Redundanz, aber mehr JOINs.

21. Soft-Delete implementieren

Implementiere Soft-Delete für Tabelle [table_name]. Füge Spalte deleted_at TIMESTAMP NULL hinzu. Alle Queries müssen filtern: WHERE deleted_at IS NULL. Erstelle: (1) Migration für neue Spalte, (2) Update-Query für DELETE-Ersatz (UPDATE ... SET deleted_at = NOW()), (3) ORM-Scope/Filter der automatisch soft-deleted ausschließt. Wichtig: Unique-Constraints funktionieren anders (deleted items müssen aus Unique-Check raus).

Debugging / Testing (Prompts 22–29)

22. Fehlgeschlagenen Test debuggen

Der Test [TestName] schlägt fehl mit Fehler: [Error-Message]. Lies den Test-Code, den getesteten Code, und den kompletten Stack-Trace. Identifiziere: Ist es ein Assertion-Fehler (erwarteter vs. tatsächlicher Wert stimmt nicht), ein Exception (Code wirft unerwarteten Fehler), oder ein Timeout (z.B. bei async Code)? Gib Root-Cause und Fix.

23. Flaky Test stabilisieren

Der Test [TestName] ist flaky: Manchmal grün, manchmal rot, ohne Code-Änderung. Häufige Ursachen: Race-Condition (async Code ohne await), Zeit-abhängige Logik (z.B. new Date() ohne Mock), zufällige Daten ohne Seed, geteilter State zwischen Tests. Analysiere den Test und mach ihn deterministisch. Nutze Mocks/Stubs für externe Abhängigkeiten.

24. Integration-Test für API-Endpoint

Schreibe einen Integration-Test für [HTTP-Method] /api/[path]. Der Test soll: echte HTTP-Requests gegen Test-Server machen, echte Datenbank nutzen (vor jedem Test resetten), Token-Auth wenn nötig, alle Error-Codes testen (nicht nur Happy-Path). Nutze [pytest + TestClient / Supertest / Django-TestCase]. Assertions auf Status-Code UND Response-Body.

25. Mock für externe API

Die Funktion [FunctionName] ruft externe API [ServiceName] auf. Schreibe Unit-Tests die NICHT die echte API callen (zu langsam, Rate-Limits, kostet Geld). Nutze Mocks: [unittest.mock / jest.mock / VCR]. Mocke sowohl Success-Response als auch Error-Cases (Timeout, 500, 429). Assertions auf Request-Parameter (wurde richtig gecallt?) und Return-Value.

26. Test-Coverage erhöhen

Führe Coverage-Report aus für Datei [FilePath]. Nutze [pytest-cov / Jest --coverage / coverage.py]. Zeige mir welche Zeilen nicht abgedeckt sind. Für jede uncovered Zeile: entscheide ob (a) Test fehlt (dann schreibe ihn), (b) Code unerreichbar ist (dann lösche ihn), oder (c) Edge-Case der nicht getestet werden muss (begründe warum). Ziel: >80% Coverage bei kritischem Code.

27. Log-basiertes Debugging

Der Prod-Fehler [ErrorMessage] tritt sporadisch auf. Ich habe Logs von 3 Vorkommen: [Log-Auszug]. Analysiere: Was passiert unmittelbar vor dem Fehler? Welche Requests/User sind betroffen? Gibt es ein Muster (bestimmte Input-Werte, Tageszeit, Load)? Formuliere Hypothese und schreibe reproduzierbaren Test-Case.

28. Performance-Test schreiben

Schreibe einen Load-Test für [Endpoint/Function]. Simuliere [X concurrent users] die jeweils [Y requests] machen. Nutze [Locust / k6 / Artillery]. Metrics: Requests/sec, p50/p95/p99 Latency, Error-Rate. Akzeptanz-Kriterium: p95 < [Xms], Error-Rate < [Y%]. Wenn Kriterium verletzt: zeige mir wo der Bottleneck ist (CPU/DB/Network).

29. Memory-Leak finden

Die App verbraucht immer mehr RAM über Zeit (Memory-Leak). Nutze [Node.js --inspect + Chrome DevTools / Python memory_profiler / Go pprof]. Erstelle Heap-Snapshot vor und nach [kritischer Operation], vergleiche Objekt-Counts. Häufige Ursachen: Event-Listener nicht entfernt, globale Caches ohne Eviction, zirkuläre Referenzen. Zeige mir Code-Stelle + Fix.

Refactoring (Prompts 30–35)

30. Funktion in kleinere Teile zerlegen

Die Funktion [FunctionName] ist [X Zeilen] lang und macht zu viel. Zerlege sie in mehrere kleine Funktionen mit je einer Verantwortung (Single-Responsibility-Principle). Jede neue Funktion: aussagekräftiger Name, max 20 Zeilen, eine Abstraktionsebene. Nutze frühe Returns statt tiefer Verschachtelung. Original-Tests müssen danach noch grün sein.

31. Code-Duplikation entfernen

Die Funktionen [Function1] und [Function2] haben 80% identischen Code. Extrahiere den gemeinsamen Teil in eine Helper-Funktion [HelperName]. Die beiden Original-Funktionen sollen nur noch die Helper-Funktion callen mit unterschiedlichen Parametern. Achte auf: Keine Regression (Tests grün), keine erhöhte Komplexität wenn die Duplikation trivial ist.

32. Magic-Numbers durch Konstanten ersetzen

Der Code hat mehrere Magic-Numbers: [Beispiele]. Ersetze sie durch benannte Konstanten am Top der Datei oder in Config-File. Namen: SCREAMING_SNAKE_CASE für Konstanten. Erkläre jede Konstante mit kurzem Kommentar warum dieser Wert gewählt wurde. Beispiel: MAX_RETRIES = 3 # Balance zwischen Resilienz und schnellem Fail.

33. Type-Hints hinzufügen

Die Datei [FilePath] hat keine Type-Hints (Python) / Type-Annotations (TypeScript). Füge für jede Funktion hinzu: Parameter-Typen, Return-Type. Bei komplexen Strukturen: nutze TypedDict / Interface. Führe dann Type-Checker aus ([mypy --strict / tsc --noEmit]) und fixe alle Errors. Keine Any-Types — sei so spezifisch wie möglich.

34. Error-Handling verbessern

Die Funktion [FunctionName] hat schwaches Error-Handling: generisches except Exception oder try-catch ohne spezifische Fehler. Refactore: Fange nur Fehler die du erwartest und behandeln kannst. Für unerwartete Fehler: propagiere sie (re-raise). Logge alle gefangenen Errors mit Context. Nutze Custom-Exceptions für Business-Errors. Kein stilles Schlucken von Fehlern.

35. Nested-Ifs in Guard-Clauses umwandeln

Die Funktion [FunctionName] hat tief verschachtelte if-else-Blöcke (Arrowhead-Anti-Pattern). Refactore auf Guard-Clauses: Early-Return bei Fehlerfall, dann Happy-Path linear ohne Verschachtelung. Beispiel: statt if valid: if authorized: process() mach if not valid: return error → if not authorized: return error → process(). Reduziert Cognitive-Load massiv.

Code-Review (Prompts 36–40)

36. Security-Review für Auth-Code

Reviewe die Auth-Implementierung in [FilePath]. Prüfe: Passwörter werden gehasht (bcrypt/Argon2, nicht MD5), Tokens haben Expiration, keine Secrets im Code (nur Env-Vars), HTTPS-only für Cookies (Secure-Flag), SQL-Injection nicht möglich (Prepared-Statements/ORM), Rate-Limiting gegen Brute-Force. Für jedes Finding: Severity (P0/P1/P2) und Code-Fix.

37. Performance-Review

Reviewe [FilePath] auf Performance-Probleme. Prüfe: Loops mit DB-Queries (N+1), synchrone Calls wo async möglich wäre, große Dateien komplett in RAM geladen statt gestreamt, fehlende Caching-Layer, unnötige Kopien großer Objekte. Gib konkrete Optimierungsvorschläge mit geschätztem Impact (z.B. "10x schneller" vs. "5% schneller").

38. Code-Smell-Hunting

Analysiere [FilePath] auf Code-Smells: Long-Method (>50 Zeilen), God-Class (zu viele Responsibilities), Feature-Envy (Methode nutzt mehr Daten einer anderen Klasse als der eigenen), Shotgun-Surgery (eine Änderung betrifft viele Dateien), Primitive-Obsession (zu viele primitive Typen statt Domain-Objekte). Für jeden Smell: Refactoring-Vorschlag.

39. Dependency-Review

Reviewe [package.json / requirements.txt / Gemfile] auf problematische Dependencies. Prüfe: Sind alle Dependencies aktiv gepinnt (keine ^ oder ~ in Production)? Gibt es bekannte Vulnerabilities ([npm audit / pip-audit / bundler-audit])? Werden Dependencies noch maintained (letzter Release-Zeitpunkt)? Gibt es leichtgewichtigere Alternativen (z.B. day.js statt moment.js)?

40. API-Design-Review

Reviewe das API-Design von [Endpoint/Service]. Prüfe: RESTful-Konventionen eingehalten (GET/POST/PUT/DELETE richtig genutzt)? Response-Format konsistent (immer JSON mit gleichem Error-Format)? Versionierung vorhanden (/v1/-Prefix)? Pagination bei Collections? HTTP-Status-Codes semantisch korrekt? Breaking-Changes vermieden (wenn API bereits live)?

DevOps (Prompts 41–45)

41. Dockerfile optimieren

Reviewe [Dockerfile-Path] auf Optimierungen. Prüfe: Multi-Stage-Build genutzt (Build vs. Runtime trennen)? Layer-Caching optimal (COPY package.json VOR dem Code)? Minimal-Base-Image (alpine statt ubuntu)? Non-Root-User? Health-Check definiert? .dockerignore vorhanden (node_modules/build-Artefakte ausschließen)? Image-Size: zeige Vorher/Nachher.

42. CI/CD-Pipeline erstellen

Schreibe eine CI/CD-Pipeline für [GitHub-Actions / GitLab-CI / Jenkins] die: (1) bei jedem Push: Linter + Type-Checker + Tests ausführt, (2) bei Tag-Push: Build + Deploy zu [Umgebung]. Stages: Install-Dependencies (mit Cache), Lint, Test (parallel), Build, Deploy (nur auf main/master). Secrets über [GitHub-Secrets / GitLab-Variables]. Pipeline schlägt fehl wenn ein Test rot ist.

43. Health-Check-Endpoint

Implementiere einen Health-Check-Endpoint GET /health der zurückgibt: (1) Status: "healthy" / "degraded" / "unhealthy", (2) Details: DB-Connection OK? Redis OK? Disk-Space >10%? (3) Timestamp. Nutze HTTP-Status: 200 wenn healthy, 503 wenn unhealthy. Orchestrator (Kubernetes/Docker-Swarm) soll darauf basierend Container neu starten.

44. Logs strukturiert machen

Der Code nutzt print() / console.log() für Logging. Refactore auf strukturiertes Logging mit [Python logging / Winston / Logrus]. Jedes Log: (1) Level (DEBUG/INFO/WARN/ERROR), (2) Timestamp, (3) Context (Request-ID, User-ID wenn relevant), (4) Message. Format: JSON für Production (Machine-Readable), Pretty für Dev (Human-Readable). Nie Secrets/PII loggen.

45. Secret-Management einrichten

Der Code hat Secrets hardcoded: API-Keys, DB-Passwörter. Migriere auf: (1) Env-Variables für lokale Dev (.env-File, nicht committen), (2) Secret-Manager für Production ([AWS-Secrets-Manager / Vault / Doppler]). Im Code: nur os.getenv("SECRET_NAME") / process.env.SECRET_NAME. Deployment: Secrets via CI/CD injizieren, nicht im Image backen. Rotate alte Secrets.

Dokumentation (Prompts 46–50)

46. README für neues Projekt

Schreibe ein README.md für Projekt [ProjectName]. Struktur: (1) Was macht das Projekt (1–2 Sätze), (2) Prerequisites (Node.js-Version, etc.), (3) Installation (npm install, .env-Setup), (4) Development (npm run dev), (5) Testing (npm test), (6) Deployment, (7) Projektstruktur (welcher Ordner wofür), (8) Contribution-Guide. Nutze Code-Blocks mit Syntax-Highlighting. Halte es kurz — maximal 200 Zeilen.

47. API-Dokumentation generieren

Dokumentiere alle Endpoints in [RouterFile]. Für jeden Endpoint: (1) HTTP-Method + Path, (2) Auth required? (3) Request-Body-Schema (JSON-Beispiel + Field-Typen), (4) Response-Schema (Success + alle Error-Cases), (5) Beispiel-curl-Befehl. Nutze [OpenAPI/Swagger / Postman-Collection / Markdown-Tabelle]. Automatisch generieren wenn möglich (FastAPI macht das out-of-the-box).

48. Code-Kommentare verbessern

Reviewe [FilePath] auf Kommentare. Entferne: (1) Redundante Kommentare (// increment counter über counter++), (2) Auskommentierter Code (lösche oder committe), (3) Veraltete Kommentare (stimmen nicht mehr mit Code überein). Füge hinzu: (1) WHY-Kommentare (Warum diese Lösung, nicht wie sie funktioniert), (2) Docstrings für Public-Functions, (3) TODOs mit Jira-Ticket-Link wenn relevant.

49. Onboarding-Guide für neue Devs

Schreibe einen Onboarding-Guide für neue Entwickler im Projekt. Abschnitte: (1) Lokales Setup (Schritt-für-Schritt, keine Annahmen), (2) Architektur-Überblick (welche Services/Komponenten gibt es), (3) Code-Konventionen (Naming, File-Struktur, Branching-Strategie), (4) Erste Task zum Einarbeiten (z.B. "Füge Logging zu Funktion X hinzu"), (5) Wer bei Fragen kontaktieren. Maximal 500 Zeilen.

50. Changelog pflegen

Generiere Changelog-Eintrag für Version [X.Y.Z] basierend auf Git-Commits seit letztem Tag. Kategorien: Added (neue Features), Changed (Änderungen an bestehenden Features), Fixed (Bugfixes), Deprecated (bald entfernte Features), Security (Security-Fixes). Nutze [Conventional-Commits / Keep-a-Changelog-Format]. Keine technischen Details — schreibe für End-User. Bei Breaking-Changes: Migration-Guide inline.

Nutzungshinweise

Lizenz: CC BY 4.0 — Frei nutzbar mit Quellenangabe (FlowKI-Community)
Version: 1.0 (2026-08-03)
Feedback & Ergänzungen: https://discord.gg/flowki (FlowKI-Discord-Community)

// weiter geht's in der community

Fragen, Feedback, eigene Ergänzungen?

Dieses Freebie ist ein Startpunkt, kein Endpunkt. Im deutschsprachigen FlowKI-Club-Discord besprichst du deine Fälle mit anderen KI-Praktikern, bekommst Updates zu den Sammlungen zuerst und kannst eigene Beiträge einbringen.

Zur FlowKI-Community →