# 50 Developer-Prompts — Deutsch **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 - **Platzhalter anpassen:** Ersetze alle `[Begriffe in eckigen Klammern]` durch deine konkreten Werte - **Kontext hinzufügen:** Füge bei Bedarf projektspezifische Details hinzu (Stack, Constraints, bestehende Patterns) - **Iterativ verfeinern:** Wenn die erste Antwort nicht passt, gib Feedback und lass den Prompt verfeinern - **Gates setzen:** Fordere bei Code-Änderungen immer Proof (Test-Output, Lint-Output, manueller Test) --- **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)