--- title: "Praxisleitfaden zu Claude Code Rules·Skills·Agents" locale: de category: tutorial category_name: "Tutorial" translation_status: reviewed license: cc_by author: "injoys" source_url: https://injoys.com/en/articles/claude-code-rules-skills-agents-guide published_at: 2026-08-19T16:14:05+09:00 --- # Praxisleitfaden zu Claude Code Rules·Skills·Agents > Rules, Skills und Agents in Claude Code dienen jeweils dauerhaften Anweisungen, wiederverwendbaren Abläufen und der Delegation isolierter Aufgaben. Anhand praktischer Beispiele werden die korrekte Dateistruktur, Aufrufmethoden sowie Grundsätze für Sicherheit und Kontextverwaltung erläutert. ## Key Points - Erstellen Sie im Projektstamm das Verzeichnis `.claude` und unterscheiden Sie den Geltungsbereich gemeinsamer und persönlicher Einstellungen. - Lagern Sie stets einzuhaltende Vorgaben in Markdown-Dateien unter `.claude/rules` aus und beschränken Sie bei Bedarf die Pfade, auf die sie angewendet werden. - Definieren Sie wiederkehrende Abläufe in `.claude/skills/<이름>/SKILL.md` und legen Sie den automatischen oder expliziten Aufruf fest. - Delegieren Sie Aufgaben, die einen unabhängigen Kontext und eine eigene Rolle erfordern, an einen Sub-Agenten unter `.claude/agents/<이름>.md`. - Prüfen Sie zunächst mit kleinen Validierungsaufgaben das Laden, die Werkzeugberechtigungen und die Ergebnisqualität, bevor Sie die Einstellungen in das Team-Repository übernehmen. Die Erweiterungsfunktionen von Claude Code sind nicht alle dieselbe Art von Prompt. **Rules sind dauerhaft anzuwendende Anweisungen**, **Skills sind wiederverwendbare Arbeitsabläufe für wiederkehrende Aufgaben**, und **Agents sind rollenspezifische Ausführende, die in einem separaten Kontext arbeiten**. Wer die drei Funktionen klar unterscheidet, kann wiederholte Prompts reduzieren und zugleich den Kontext der Hauptkonversation effizient verwalten. Dieses Dokument erläutert die Einrichtung auf Projektebene. Da sich unterstützte Metadaten oder Oberflächen je nach Version von Claude Code unterscheiden können, sollten nicht funktionierende Felder nochmals anhand der offiziellen Dokumentation der installierten Version überprüft werden. ## Schritt 1: `.claude`-Verzeichnis und Konfigurationsumfang festlegen Rules, Skills und Agents, die innerhalb eines Projekts gemeinsam verwendet werden sollen, werden üblicherweise unter `.claude` im Stammverzeichnis des Repositorys abgelegt. ```text my-project/ ├── .claude/ │ ├── rules/ │ │ ├── code-style.md │ │ └── api.md │ ├── skills/ │ │ └── fix-issue/ │ │ └── SKILL.md │ └── agents/ │ ├── code-reviewer.md │ └── test-runner.md ├── src/ └── package.json ``` Die Verzeichnisse lassen sich wie folgt erstellen. ```bash mkdir -p .claude/rules mkdir -p .claude/skills/fix-issue mkdir -p .claude/agents ``` ### Zwei Missverständnisse über `.claude` 1. `.claude` ist nicht zwingend für alle Anweisungen von Claude Code erforderlich. Projektanweisungen können auch über `CLAUDE.md` im Stammverzeichnis oder `.claude/CLAUDE.md` verwaltet werden, während persönliche Benutzereinstellungen unter `~/.claude` im Home-Verzeichnis abgelegt werden können. 2. Je nach Betriebssystem wird bei Dateinamen zwischen Groß- und Kleinschreibung unterschieden. Es ist sicherer, die Einstiegsdatei eines Skills entsprechend dem offiziellen Format als `SKILL.md` in Großbuchstaben anzulegen. Wird sie als `skill.md` gespeichert, wird sie möglicherweise nicht erkannt. ### Auswahlkriterien für Projekt- und persönliche Einstellungen | Umfang | Geeignete Inhalte | Beispiel | |---|---|---| | Projektweit geteilt | Regeln und Automatisierungen, die alle Mitwirkenden einheitlich befolgen müssen | Testbefehle, Verzeichnisstruktur, API-Konventionen | | Persönlich | Persönliche Präferenzen oder Einstellungen, die nicht im Repository veröffentlicht werden dürfen | Persönliche Arbeitsweise, Auswahl lokaler Werkzeuge | | Nur lokal | Pfade oder experimentelle Einstellungen, die nur auf einem bestimmten Computer gültig sind | Lokaler Datenpfad, temporäres Debugging-Verfahren | Nur Dateien, die das Team gemeinsam verwenden soll, werden in Git committet. Geheime Schlüssel, Token und Passwörter interner Server dürfen nicht in Rules oder Skills eingetragen werden. ## Schritt 2: Dauerhafte Anweisungen mit Rules erstellen Mit Rules lassen sich Projektanweisungen, die Claude bei der Arbeit berücksichtigen soll, auf mehrere Markdown-Dateien verteilen. Von den Regeln unter `.claude/rules` werden Dateien ohne `paths`-Bedingung als Projektanweisungen geladen, während Dateien mit einer Pfadbedingung beim Bearbeiten der entsprechenden Dateien angewendet werden. ### Beispiel für eine grundlegende Rule `.claude/rules/code-style.md` kann wie folgt erstellt werden. ```markdown # Grundsätze für das Schreiben von Code - Neuer Anwendungscode wird in TypeScript geschrieben. - Für öffentliche Funktionen werden Eingabewerte, Rückgabewerte und Fehlerbedingungen beschrieben. - Bestehende Tests dürfen nicht gelöscht werden, um Fehler zu verbergen. - Nach Änderungen werden die zugehörigen Tests und die Typprüfung ausgeführt. - Erklärungen werden auf Koreanisch verfasst, Codebezeichner folgen jedoch den bestehenden Namenskonventionen. ``` Eine gute Rule ist überprüfbar. „Den Code ansprechend schreiben“ ist weniger eindeutig als „Nach Änderungen `npm test` und `npm run typecheck` ausführen“. ### Rule nur auf bestimmte Pfade anwenden Wenn für Frontend und Backend unterschiedliche Regeln gelten, lässt sich der Umfang mit `paths` im YAML front matter eingrenzen. ```markdown --- paths: - "src/api/**/*.ts" - "tests/api/**/*.ts" --- # API-Regeln - Alle API-Eingaben werden anhand eines Schemas validiert. - Fehlgeschlagene Authentifizierung und unzureichende Berechtigungen werden als unterschiedliche Fehler behandelt. - Wenn ein Endpunkt geändert wird, werden auch die entsprechenden API-Tests aktualisiert. ``` Pfadspezifische Regeln verringern das Problem, dass für eine Aufgabe unnötige Anweisungen den Kontext sämtlicher Arbeiten belegen. ### Inhalte, die nicht in Rules gehören - Ein Migrationsverfahren, das nur einmal ausgeführt wird - Detaillierte Anforderungen, die nur für ein bestimmtes Issue erforderlich sind - Einander widersprechende absolute Anweisungen - Ausführliche Wiederholungen von Inhalten, die bereits durch Code oder Linter-Konfigurationen erzwungen werden - Sensible Daten wie Passwörter, API-Schlüssel oder Kundeninformationen Rules sind kein „magischer Garant für bedingungslose Befolgung“. Bei mehrdeutigen oder widersprüchlichen Anweisungen können die Ergebnisse variieren. Daher müssen zusätzlich deterministische Prüfmittel wie Tests, Linter und Zugriffskontrollen eingesetzt werden. ## Schritt 3: Wiederkehrende Abläufe mit Skills automatisieren Ein Skill bündelt Beschreibung, Arbeitsablauf, erforderliche Werkzeuge und ergänzende Materialien zu einer wiederverwendbaren Einheit. Die grundlegende Struktur eines Projekt-Skills lautet `.claude/skills//SKILL.md`; bei Bedarf können im selben Verzeichnis Vorlagen oder Skripte ergänzt werden. Anders als Rules wird ein Skill verwendet, wenn er für eine bestimmte Aufgabe benötigt wird. Claude kann ihn anhand seiner Beschreibung automatisch auswählen, oder der Benutzer kann ihn ausdrücklich im Format `/` aufrufen. Er funktioniert nicht zwingend ausschließlich manuell. ### Beispiel für einen Skill zur Behebung von Issues Ein Beispiel für `.claude/skills/fix-issue/SKILL.md` sieht wie folgt aus. ```markdown --- name: fix-issue description: Einen Fehler reproduzieren, seine Ursache eingrenzen und anschließend eine minimale Korrektur sowie einen Regressionstest durchführen. disable-model-invocation: true allowed-tools: Read, Grep, Glob, Edit, Bash(npm test:*) --- # Verfahren zur Behebung eines Issues Ziel-Issue: $ARGUMENTS 1. Den zugehörigen Code und die vorhandenen Tests untersuchen. 2. Vor der Korrektur das Reproduktionsverfahren und das erwartete Verhalten festhalten. 3. Die Grundursache in einem Absatz erläutern. 4. Die Korrektur mit dem geringsten Wirkungsumfang anwenden. 5. Einen Regressionstest hinzufügen oder prüfen, ob ein vorhandener Test das Problem validiert. 6. Die zulässigen Tests ausführen und die Ergebnisse zusammenfassen. 7. Geänderte Dateien, verbleibende Risiken und manuell zu prüfende Punkte melden. ``` Dieser Skill lässt sich wie folgt aufrufen. ```text /fix-issue Profilbild wird nach der Anmeldung nicht aktualisiert ``` `disable-model-invocation: true` ist nützlich, wenn Claude daran gehindert werden soll, diesen Skill eigenständig auszuführen, sodass er nur direkt durch den Benutzer aufgerufen wird. Die unterstützten front matter-Felder können je nach Version von Claude Code variieren. ### Beispiel für einen Skill mit Design-Priorität Wenn vor der eigentlichen Implementierung zunächst ein Designdokument erstellt werden soll, kann der folgende Ablauf in einen Skill aufgenommen werden. 1. Anforderungen und unklare Punkte voneinander trennen. 2. Die bestehende Struktur und wiederverwendbare Module untersuchen. 3. Datenfluss, Schnittstellen und Fehlerbedingungen entwerfen. 4. Unter `docs/design/` ein Designdokument erstellen. 5. Nach Bestätigung durch den Benutzer oder Prüfung der ausdrücklich festgelegten Freigabebedingungen implementieren. 6. Tests und ein Rollback-Verfahren angeben. ### Eigenschaften eines guten Skills - Eingaben und endgültige Ergebnisse sind eindeutig. - Reihenfolge und Abbruchbedingungen des Ablaufs sind festgelegt. - Es werden nur die erforderlichen Werkzeuge zugelassen. - Umfangreiche Referenzmaterialien werden in separate Dateien ausgelagert. - Bei einem Fehler wird nicht eigenmächtig fortgefahren, sondern Bericht erstattet. - Ein einzelner Skill verfolgt nicht zu viele Ziele. Wiederkehrende Aufgaben mit klarem Anfang und Ende, etwa das Erstellen von Commits, Code-Reviews, Release-Prüfungen oder API-Design, eignen sich für Skills. ## Schritt 4: Rollen und Kontext mit Agents trennen Sub-Agents von Claude Code übernehmen in einem separaten Kontext eine bestimmte Rolle und geben ihre Ergebnisse an die Hauptkonversation zurück. Das ist nützlich, wenn nicht sämtliche umfangreichen Suchergebnisse oder Testprotokolle im Hauptkontext angesammelt werden sollen. Projekt-Agents werden üblicherweise unter `.claude/agents/.md` definiert. Mit dem Befehl `/agents` lassen sich Agents anzeigen oder verwalten. Außerdem kann in natürlicher Sprache darum gebeten werden, eine Aufgabe an einen bestimmten Agent zu delegieren. ### Beispiel für einen Code-Review-Agent `.claude/agents/code-reviewer.md` kann wie folgt erstellt werden. ```markdown --- name: code-reviewer description: Ein auf das Lesen konzentrierter Reviewer, der geänderten Code auf Defekte, Sicherheitsrisiken und fehlende Tests prüft tools: Read, Grep, Glob, Bash model: sonnet --- Du bist ein ausschließlich für Code-Reviews zuständiger Agent. Prüfe in der folgenden Prioritätsreihenfolge. 1. Defekte, die tatsächliche Ausfälle oder Datenverluste verursachen können 2. Sicherheitsprobleme im Zusammenhang mit Authentifizierung, Berechtigungen und Eingabevalidierung 3. Probleme bei Nebenläufigkeit, Transaktionen und Fehlerbehandlung 4. Fehlende Tests, durch die Anforderungen nicht validiert werden 5. Strukturen, die die Wartbarkeit erheblich beeinträchtigen Jeder Befund muss Dateipfad, Begründung, Auftretensbedingungen und eine minimale Korrekturrichtung enthalten. Unbegründete Stilpräferenzen dürfen nicht als Defekte gemeldet werden. Ändere den Code nicht direkt, sondern gib ausschließlich die Review-Ergebnisse zurück. ``` Eine Anfrage kann wie folgt formuliert werden. ```text Lass den Agent code-reviewer die Änderungen im aktuellen Branch prüfen. ``` ### Unterschied zwischen Skill und Agent | Kriterium | Rules | Skills | Agents | |---|---|---|---| | Hauptzweck | Dauerhafte Anweisungen bereitstellen | Wiederkehrende Abläufe wiederverwenden | Aufgaben nach Rollen delegieren | | Anwendungszeitpunkt | Immer oder entsprechend einer Pfadbedingung | Automatische Auswahl oder ausdrücklicher Aufruf | Delegierung durch Claude oder Anfrage des Benutzers | | Kontext | Als Anweisungen in der Hauptaufgabe enthalten | Wird hauptsächlich im aktuellen Arbeitsablauf ausgeführt | Wird in einem separaten Kontext ausgeführt und gibt danach Ergebnisse zurück | | Typisches Beispiel | Coding-Standards | Verfahren zur Behebung eines Issues | Code-Reviewer | | Speicherort | `.claude/rules/*.md` | `.claude/skills//SKILL.md` | `.claude/agents/*.md` | ### Agents und Agent Teams sind nicht dasselbe Die Tatsache, dass gewöhnliche Sub-Agents einen separaten Kontext verwenden, bedeutet nicht, dass Agents frei miteinander kommunizieren können. Ein gewöhnlicher Sub-Agent übernimmt eine zugewiesene Aufgabe und gibt das Ergebnis im Rahmen einer Delegierungsstruktur an den Haupt-Agent zurück. Agent Teams, bei denen mehrere unabhängige Sitzungen Nachrichten miteinander austauschen, sind eine separate Funktion. Unterstützungsstatus und Aktivierungsbedingungen müssen in der offiziellen Dokumentation geprüft werden. Wenn ein Workflow unter der Annahme entwickelt wird, dass ein Agent fortlaufend weitere Agents erzeugt, kann er aufgrund von Versions- oder Berechtigungseinschränkungen scheitern. Sicherer ist es, zunächst mit einer einfachen Struktur zu beginnen, in der der Haupt-Agent Aufgaben an rollenspezifische Sub-Agents verteilt und deren Ergebnisse zusammenführt. ## Schritt 5: Laden, Berechtigungen und Qualität überprüfen Es darf nicht angenommen werden, dass Konfigurationsdateien allein durch ihre Erstellung wie beabsichtigt funktionieren. Jede Komponente sollte separat anhand einer kleinen Aufgabe geprüft werden. ### Empfohlene Prüfreihenfolge 1. **Rules prüfen:** Jeweils eine Datei anfordern, auf die eine Regel angewendet wird beziehungsweise nicht angewendet wird, um die Pfadbedingung zu überprüfen. 2. **Skills prüfen:** Einen Skill ausdrücklich aufrufen und prüfen, ob Eingabeargumente, Ergebnisse und Abbruchbedingungen funktionieren. 3. **Agents prüfen:** Eine risikoarme Aufgabe wie ein schreibgeschütztes Review zuweisen und das Ergebnisformat kontrollieren. 4. **Berechtigungen prüfen:** Überprüfen, ob verändernde Werkzeuge wie Bash und Edit nur Konfigurationen zugewiesen wurden, die sie tatsächlich benötigen. 5. **Automatische Prüfung:** AI-Ergebnisse unabhängig durch Tests, Typprüfung, Linter und Sicherheitsprüfungen kontrollieren. ### Bei Fehlern zu prüfende Punkte - Befindet sich `.claude` tatsächlich im Stammverzeichnis des Projekts? - Lautet der Dateiname des Skills exakt `SKILL.md`? - Befindet sich der Skill in der Struktur `.claude/skills//SKILL.md`? - Ist die Agent-Datei eine Markdown-Datei direkt unter `.claude/agents`? - Sind Anfang und Ende des YAML front matter mit `---` abgeschlossen? - Sind `name` und `description` konkret genug, um die Aufgabe zu unterscheiden? - Stimmen die Pfadmuster mit der tatsächlichen Projektstruktur überein? - Unterstützt die installierte Version von Claude Code die verwendeten Metadaten? - Wird die Ausführung durch Werkzeugberechtigungen oder Organisationsrichtlinien blockiert? ## Warum Kontextbudget und Sicherheit gemeinsam konzipiert werden müssen Rules, Skills und Agents dienen nicht nur dazu, Funktionen hinzuzufügen. Sie sind zugleich ein **Mittel des Kontext-Engineerings**, mit dem gesteuert wird, welche Informationen wann in den Kontext aufgenommen werden. Werden Regeln übermäßig lang, belegen für die aktuelle Aufgabe irrelevante Anweisungen den Kontext, und die Wahrscheinlichkeit von Konflikten steigt. Werden dagegen Recherche und Protokollanalyse an Sub-Agents delegiert, können in der Hauptkonversation nur Schlussfolgerungen und Belege verbleiben. Aus Sicherheitssicht sind die folgenden Grundsätze wichtig. - Rules und Skills werden wie anderer Code im Repository geprüft. - Extern bezogene Agent- oder Skill-Dateien werden vor der Ausführung gelesen. - Berechtigungen für Shell-Befehle, Netzwerkzugriff und Dateiänderungen werden minimiert. - Befehlen in Benutzereingaben oder Issue-Beschreibungen wird nicht bedingungslos vertraut. - Für Deployment, Löschvorgänge, Zahlungen und Datenmigrationen wird ein menschlicher Freigabeschritt vorgesehen. - Geheime Informationen werden nicht in Prompt-Dateien gespeichert; stattdessen wird ein separates Geheimnisverwaltungssystem verwendet. ## Welche Funktion sollte gewählt werden? Mit den folgenden Fragen lässt sich schnell eine Entscheidung treffen. - Müssen alle zugehörigen Aufgaben die Vorgabe befolgen? → **Rule** - Handelt es sich um einen wiederkehrenden Ablauf mit Anfang und Ende? → **Skill** - Werden eine separate Rolle und ein unabhängiger Kontext benötigt? → **Agent** - Muss vor oder nach einem bestimmten Ereignis ein deterministischer Befehl ausgeführt werden? → **Hook prüfen** „TypeScript verwenden“ ist beispielsweise eine Rule, während „von der Reproduktion eines Fehlers bis zum Regressionstest alles durchführen“ ein Skill ist. „Änderungen lesen und ausschließlich Sicherheitsdefekte melden“ eignet sich für einen Agent. Für an bestimmte Ereignisse gebundene Aktionen, etwa das obligatorische Ausführen eines Formatters nach der Bearbeitung einer Datei, können Hooks besser geeignet sein. Die stabilste Konfiguration betrachtet die drei Funktionen nicht als Konkurrenten, sondern kombiniert sie. Rules stellen gemeinsame Standards bereit, Skills führen standardisierte Abläufe aus, und Agents lagern kontextintensive Aufgaben wie Recherche und Reviews aus. Tests und Hooks ergänzen diese Struktur um deterministische Prüfungen. ## FAQ ### Ist der Ordner `.claude` in Claude Code zwingend erforderlich? Er wird verwendet, um projektbezogene Regeln, Skills und Agenten in einer Standardstruktur zu verwalten, ist aber nicht für alle Anweisungen zwingend erforderlich. Projektanweisungen können auch in `CLAUDE.md` im Stammverzeichnis oder in `.claude/CLAUDE.md` abgelegt werden, und persönliche Einstellungen lassen sich unter `~/.claude` verwalten. ### Was ist der Unterschied zwischen Regeln und `CLAUDE.md`? `CLAUDE.md` eignet sich dazu, die zentralen Anweisungen eines Projekts in einem einzigen Dokument bereitzustellen. `.claude/rules` erleichtert die Aufteilung in themenspezifische Dateien und die bedingte Anwendung je nach Pfad und hilft daher mit zunehmender Projektgröße dabei, Regeln zu modularisieren. ### Lautet der Dateiname für einen Skill `skill.md` oder `SKILL.md`? Der Name der Einstiegsdatei gemäß der offiziellen Agent-Skills-Struktur lautet in Großbuchstaben `SKILL.md`. Projekt-Skills sollten sicherheitshalber unter `.claude/skills//SKILL.md` abgelegt werden. Auf Betriebssystemen, die zwischen Groß- und Kleinschreibung unterscheiden, wird `skill.md` als andere Datei behandelt. ### Wird ein Claude Code Skill nur ausgeführt, wenn der Benutzer ihn aufruft? Nicht immer. Claude kann anhand der Beschreibung eines Skills entscheiden, ihn bei einer passenden Aufgabe automatisch auszuwählen; der Benutzer kann ihn außerdem mit `/` aufrufen. Wenn automatische Aufrufe verhindert werden sollen, kann bei unterstützten Versionen die Einstellung `disable-model-invocation` geprüft werden. ### Sollte ich einen Skill oder einen Agenten verwenden? Ein Skill eignet sich zur Ausführung wiederkehrender Abläufe innerhalb des aktuellen Workflows. Wenn wie bei umfangreichen Recherchen, Testanalysen oder Code-Reviews eine separate Rolle und ein isolierter Kontext erforderlich sind, eignet sich ein Agent. Inhalte, die wie gemeinsame Programmierrichtlinien dauerhaft angewendet werden sollen, werden als Regel ausgegliedert. ### Können Subagenten direkt miteinander kommunizieren oder andere Agenten aufrufen? Gewöhnliche Claude Code-Subagenten arbeiten in einem separaten Kontext und geben anschließend die Ergebnisse an den Hauptagenten zurück. Die direkte Zusammenarbeit mehrerer unabhängiger Sitzungen ist von der separaten Agent-Teams-Funktion zu unterscheiden; der Unterstützungsstatus und die Einschränkungen der verwendeten Version müssen geprüft werden. ### Hält sich Claude immer vollkommen an die Anweisungen, wenn Regeln erstellt werden? Nein. Regeln sind fortlaufend bereitgestellte Anweisungen, aber kein deterministischer Durchsetzungsmechanismus. Aufgrund von Konflikten oder Mehrdeutigkeiten in den Anweisungen können sie übergangen werden und sollten daher zusammen mit Lintern, Typprüfungen, Tests, Hooks und Code-Reviews verwendet werden. ### Ist es sicher, einen extern bezogenen Skill oder Agenten sofort zu verwenden? Es ist ratsam, ihn nicht sofort auszuführen. Zunächst sollten die in den Dateien enthaltenen Anweisungen, Shell-Befehle, zulässigen Werkzeuge sowie der Umfang des Netzwerk- und Dateizugriffs geprüft und anschließend mit minimalen Berechtigungen getestet werden. Außerdem ist zu prüfen, ob Inhalte enthalten sind, die zur Übermittlung geheimer Informationen oder zu riskanten Dateiänderungen verleiten. ## Sources - [Claude Code-Dokumentation: Den Speicher von Claude verwalten](https://code.claude.com/docs/en/memory) - [Claude Code-Dokumentation: Claude mit Fähigkeiten erweitern](https://code.claude.com/docs/en/skills) - [Claude Code-Dokumentation: Benutzerdefinierte Subagenten erstellen](https://code.claude.com/docs/en/sub-agents) - [Claude Code-Dokumentation: Claude Code-Einstellungen](https://code.claude.com/docs/en/settings) ## Images ![Person betrachtet ein Dashboard für Entwicklungsabläufe auf einem Laptop am Schreibtisch](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6OTgyOSwicHVyIjoiYmxvYl9pZCJ9fQ==--8ba3d33d24232863ea1d744998bca1e2dbb088c6/ai-7c680af1.webp) ![Workflow mit Ordnern, Filtern, Automatisierung, KI-Arbeitsplatz, Sicherheit und Validierung](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6OTgzNSwicHVyIjoiYmxvYl9pZCJ9fQ==--458d876e5a3cb0d4581f0909c6198e47789eda8b/ai-54d6eb4e.webp)