CommunityCodierung & Entwicklunggithub.com

Kelet-ai/skills

Claude Code Fähigkeiten zur Integration von Kelet in KI-Anwendungen

Was ist skills?

Dieses Skill integriert Kelet, einen KI-Detektiv, der Traces und Signale analysiert, Fehler clustert und Lösungen vorschlägt, in Claude Code. Es arbeitet ausschließlich im Planungsmodus, um bis zur Implementierungsfreigabe keine Änderungen vorzunehmen. Der Fokus liegt auf einer brillanten Entwicklererfahrung mit minimalen Codeänderungen – idealerweise nur `kelet.configure()`. Kelet generiert automatisch synthetische Signale aus Tracedaten und ermöglicht das Hinzufügen von bis zu 2 benutzerdefinierten Signalen über bestehende Hooks. Der Skill analysiert die Anwendungsstruktur (Abhängigkeiten, Einstiegspunkte, Sitzungsverfolgung, bestehende Feedback-UI und Deployment-Infrastruktur), erstellt eine Projektlandkarte und ein ASCII-Architekturdiagramm, bevor er maximal 3 Fragen an den Entwickler stellt.

Funktioniert mit✓Claude Code~Codex CLI~Cursor✓Antigravity
npx skills add Kelet-ai/skills

Installed? Explore more Codierung & Entwicklung skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

Kelet-Integration

Sofort in den Plan-Modus wechseln. Erste Aktion des Skills: Rufe EnterPlanMode auf, sodass die gesamte Analyse → Mapping → Signale → Plan-Sequenz schreibgeschützt abläuft. Rufe ExitPlanMode erst auf, nachdem der Benutzer den endgültigen Implementierungsplan bei der Implementierungsfreigabe genehmigt hat.

Leitstern: brillante Entwicklererfahrung, schnellste Time-to-Value. Der Entwickler soll das Gefühl haben, dass sich Kelet selbst integriert hat – minimale Eingaben von ihm, maximaler Wert sofort in der Konsole sichtbar.

Kelet löst niemals Ausnahmen aus. Alle SDK-Fehler werden unterdrückt – eine falsch konfigurierte Integration sieht genauso aus wie eine funktionierende.

Live-Dokumente abrufen, bevor Code geschrieben wird: GET https://docs-ai.kelet.ai/chat?q=<Frage> (bevorzugt) oder https://kelet.ai/docs/llms.txt für den Index abrufen.


Onboarding

Öffnen Sie mit einem Willkommensbanner: 🕵️ Willkommen bei Kelet – Ihrem KI-Detektiv. Kelet ist ein Reasoning-Agent, der Traces + Signale aufnimmt, Fehler clustert und Korrekturen vorschlägt. Vermitteln Sie diese Konzepte vor jeglichem Code – halten Sie die Detektiv-Metapher in den Aufzählungspunkten lebendig:

  • Trace = der Tatort. Jeder LLM-Aufruf + jede Toolnutzung wird nach kelet.configure() automatisch aufgezeichnet.
  • Signal = der Hinweis. 👎, Bearbeitung, Abbruch – weist den Detektiv auf etwas hin, das eine Untersuchung wert ist. Kein Urteil: 👎 bedeutet hier mit der Suche beginnen.
  • Synthetisch = forensische Werkzeuge. Automatisierte Signale aus Tracedaten. Kein Code.
  • Session = die Fallakte. Traces, die nach einer Arbeitseinheit gruppiert sind.
  • Projekt = der Zuständigkeitsbereich. Eines pro agentischem Anwendungsfall. Falsches Projekt = unsichtbar in der Ursachenanalyse.
  • Als nächstes: Stille Analyse + ≤3 AskUserQuestion-Aufrufe (idealerweise 2)

Integrationsmodi

Lightweight (Standard): Möglichst wenige Codeänderungen – idealerweise nur kelet.configure(). Füge agentic_session() nur hinzu, wenn erforderlich (siehe Sessions), verwaltete Synthetics (null Code) und höchstens 1–2 codierte Signale, nur wenn sie trivial an einen vorhandenen Hook angebunden werden können. Standardmäßig diesen Modus verwenden, es sei denn, der Entwickler sagt „erweitern“, „mehr Signale hinzufügen“ oder „gründlich vorgehen“.

Vollständig: Alle Signalebenen + VoteFeedback-UI + vollständige Fehlermodus-Zuordnung.

Im Zweifelsfall: Lightweight. Jede zusätzliche Codeänderung ist ein Kostenfaktor für den Entwickler.


Präsentationsstil

Ton: warm + fachkundig. Konzept vor Mechanik. Öffne jeden Meilenstein mit einem Banner: <Emoji> <PHASE> – ein Wort, Großbuchstaben, nichts weiter. Phasen: MAPPING, SIGNALS, PLAN, IMPLEMENT, VERIFY.

Fortschrittsanzeige – genau diese Bezeichnungen:

📍  Mapping 🔄 → Signale ○ → Plan ○ → Implementieren ○ → Verifizieren ○

Interne Arbeit (z. B. 0a, 0b, 1, Unterschritte) bleibt unsichtbar. Der Benutzer sieht Fortschritte nur, wenn eine Phase auf ✅ wechselt.


Wichtige Regeln

  • Sei prägnant – wiederhole dich niemals. Jedes Token kostet Zeit. Nenne jede Tatsache einmal, sammle Daten methodisch, erkläre nicht noch einmal, was bereits behandelt wurde.
  • Verwende immer AskUserQuestion für Eingaben – niemals Freitext. Verwende multiSelect: true für Listen.
  • Maximal 3 AskUserQuestion-Aufrufe insgesamt (idealerweise 2). Wenn du es ableiten kannst – frage nicht.
  • Vorab (außerhalb des Budgets): Wenn in der Trigger-Nachricht keine App-Beschreibung enthalten ist, frage: "Was macht Ihre KI-App und wie interagieren Benutzer mit ihr?", bevor du Dateien liest.
  • Zuerst stille Analyse. Bleibe während der Meilensteine 1 und 2 im Plan-Modus; rufe ExitPlanMode erst bei der Implementierungsfreigabe auf.
  • Wenn Kelet bereits in den Abhängigkeiten ist: Überspringe die Einrichtung, konzentriere dich auf das, was gefragt wurde. Analyse-Durchlauf + Verifizieren gelten trotzdem.
  • Passe dich dem visuellen Stil der App an. Jegliche hinzugefügte UI (VoteFeedback-Buttons, Kopier-Button, Wiederholung usw.) muss die vorhandenen CSS-Klassen, Design-Tokens und Komponentenmuster der App verwenden – keine willkürlichen Inline-Stile oder Standard-Emojis. Lese die Stylesheets und vorhandenen Komponenten, bevor du Kinderkomponenten schreibst.

Frage-Slots:

  1. Meilenstein 1 – Projekt-/Workflow-Karte bestätigen
  2. Meilenstein 2 – Plan bestätigen + Schlüssel + Projektnamen sammeln
  3. Nur wenn die Bereitstellung wirklich unbekannt ist und Geheimnisse nicht sicher verarbeitet werden können

Keine Mikro-Bestätigungen zwischen diesen.


Analyse-Durchlauf (Still)

🧠 Lies alles, bevor du etwas fragst. Der Entwickler sollte bestätigt, nicht geprüft werden.

Still lesen – noch keine Fragen. Abdecken:

  1. Abhängigkeiten – KI-Frameworks, UI-Stack, Paketmanager
  2. Einstiegspunkt – wo configure() platziert wird
  3. LLM-Aufrufstellen – Abläufe, Orchestrierungsmuster
  4. Session-Tracking – Konversations-IDs, Request-IDs, Redis-Keys, DB-Spalten. Semantik bewerten: Ändert sich die Kandidaten-ID bei Zurücksetzen/neuer Konversation? Wenn nicht, den Konflikt aufzeigen. Siehe references/implementation.md.
  5. Vorhandene Feedback-UI – Daumen, Bewertungen, Bearbeitungen, Wiederholungen, Kopier-Buttons. Hier anbinden; nicht ersetzen.
  6. Bereitstellungsinfrastruktur – Vor dem Fragen scannen: helm/, charts/, .github/workflows/, vercel.json, railway.json, render.yaml, fly.toml, docker-compose.yml, Procfile, *.tf, template.yaml

Styling, Authentifizierung und nicht zusammenhängende Geschäftslogik überspringen. Andere Repos/Dienste im agentischen Ablauf kennzeichnen – der Entwickler sollte diesen Skill auch dort ausführen.

Die Projektkarte erstellen:

Anwendungsfall: [was die Agenten tun]
Abläufe → Kelet-Projekte:
  - Ablauf "X" → Projekt "X"
Benutzerschnittstelle: ja/nein
Stack: [Server] + [LLM-Framework]
Konfiguration: .env / .envrc / k8s
Bereitstellung: [Plattform | keine gefunden]
Modus: Lightweight | Vollständig

Ein ASCII-Architekturdiagramm erstellen, das den Datenfluss und die Orte zeigt, an denen Session-IDs transportiert werden.


Meilenstein 1: Mapping-Bestätigung

Diagramm + Projektkarte + Integrationsmodus + kurze Workflow-Zusammenfassung präsentieren (Schritte, wie Erfolg/Fehler aus Sicht des Agenten aussehen).

AskUserQuestion: "Stimmen dieses Diagramm, diese Karte und diese Workflow-Zusammenfassung Ihr System genau ab? Habe ich etwas übersehen?"

Wenn die Session-Semantik wirklich mehrdeutig ist – in diese Frage aufnehmen, keinen separaten Slot verschwenden.

Wenn Korrekturen die Ablaufanzahl, das Framework oder die Session-Struktur ändern – den Analyse-Durchlauf wiederholen. Erst mit der Signalanalyse fortfahren, wenn dies bestätigt wurde.


Signalanalyse-Durchlauf (Interne Überlegung)

🧠 ZEIGE DIESE ÜBERLEGUNG DEM BENUTZER NICHT. Präsentiere endgültige Vorschläge bei Meilenstein 2.

Denke wie ein Ermittler, der Hinweise platziert: Wenn später etwas schiefgeht, welche Brotkrumen würden helfen, die Quelle zurückzuverfolgen? Sage keine Fehler voraus – instrumentiere die Momente, die sie nachträglich offenbaren würden.

Der eine Filter: Kann Kelet diesen Hinweis aus dem Session-Trace ableiten? → synthetisch (null Code). Erfordert eine menschliche Handlung oder ein externes Ereignis? → codiertes Signal.

Synthetisch (Plattform, kein Kunden-Code):

Wähle Evaluatoren aus, die aussagekräftige Qualitätssignale für diesen spezifischen Anwendungsfall erfassen. Anker: Aufgabenabschluss. Füge 1–2 hinzu, die widerspiegeln, wie „gut“ und „schlecht“ für diese App aussehen. EIN Evaluator pro Dimension – das Duplizieren einer Dimension vervielfacht das Rauschen. Siehe references/signals.md für eine voreingestellte Liste.

Codiert – Frontend (Lightweight: max. 0–2):

Fast immer Frontend – Menschen reagieren auf KI-Ausgaben. Serverseitig nur, wenn der Consumer ein anderes System ist oder Feedback über einen Endpunkt eintrifft (z. B. /approve).

  • Vote → VoteFeedback, Bearbeitungen → useFeedbackState, Verhaltensereignisse → useKeletSignal
  • kind: FEEDBACK · EDIT · EVENT · METRIC · ARBITRARY — source: HUMAN · LABEL · SYNTHETIC
  • React-UI-Scan: Bearbeitungsfelder bei KI-Ausgabe → useFeedbackState; Kopieren-in-Zwischenablage, Wiederholen, Session-Zurücksetzen → useKeletSignal. Kopieren ist immer einen Vorschlag wert bei Apps, die KI-Text rendern – selbst wenn noch kein Button existiert, ist es eine natürliche Affordanz und ein starkes implizites Signal. Maximal 1–2 vorschlagen.

Codiert – Serverseitig: nur, wenn keine Browser-UI vorhanden ist oder Feedback endpointgesteuert ist.

Bereite dich auf Meilenstein 2 vor: Signalvorschläge + Projektnamen-Vorschlag + „Was Sie sehen werden“-Vorschau.


Meilenstein 2: Plan bestätigen + Eingaben sammeln

Signalergebnisse + vollständigen Lightweight-Plan präsentieren. Bitte den Entwickler nicht, ihn zu entwerfen – schlage ihn vor.

Noch im Plan-Modus – ExitPlanMode noch nicht aufrufen.

Einzelner AskUserQuestion-Aufruf (multiSelect: true), strukturiert als:

  1. Vorgeschlagene synthetische Evaluatoren (multiSelect) – Liste jeden vorgeschlagenen Evaluator als Option auf, damit der Entwickler explizit auswählt, welche in das Projekt aufgenommen werden sollen. "Keine" als Option einschließen.
  2. Planfreigabe – „Sieht der Rest des Plans richtig aus?"
  3. Schlüssel + Projektname (nur, was fehlt):
    • KELET_API_KEY (sk-kelet-...) – abrufen unter console.kelet.ai/api-keys. Erforderlich für synthetische Auto-Erstellung.
    • Öffentlicher Schlüssel (pk-kelet-...) – nur, wenn VoteFeedback im Plan enthalten ist.
    • Projektname: zuerst erstellen unter console.kelet.ai → obere Navigation → Neues Projekt. Falscher Name = stiller Routing-Fehler; Server gibt 404 mit einem Hinweis zurück, dies anzeigen.
  4. API-Key-Modus (nur, wenn synthetische Evaluatoren ausgewählt wurden):
    • „Geheimen Schlüssel einfügen (sk-kelet-...)" → primäre Auto-Erstellung.
    • „Ich hole mir einen" → anhalten: „Holen Sie sich einen Schlüssel unter console.kelet.ai/api-keys (10 Sekunden), fügen Sie ihn hier ein, um fortzufahren."
    • „Ich kann hier keine Geheimnisse einfügen" → Deeplink-Fallback.

Evaluatoren erstellen

Primär (Schlüssel eingefügt): Vor dem curl wörtlich ausgeben:

⏳ Ihre Evaluatoren werden erstellt. Dies dauert 1–3 Minuten (manchmal bis zu 5) – Kelet generiert jede Konfiguration mit einem LLM und führt einen Deduplizierungsdurchlauf durch. Bleiben Sie dran; brechen Sie nicht ab.

Dann gemäß references/signals.md § Primär: API-Aufruf ausführen.

Bei 200: ✅ Kelet beobachtet jetzt {Projekt}. Erste Evaluator-Ergebnisse in ~3min unter https://console.kelet.ai/{Projekt}/signals

Fallback (kann nicht eingefügt werden): Baue den Base64-Markdown-Link gemäß references/signals.md.

Was Sie sehen werden

Zeige die Tabelle – nur Zeilen für Elemente im vorgeschlagenen Plan:

Nach der ImplementierungSichtbar in der Kelet-Konsole
kelet.configure()LLM-Spannen in Traces: Modell, Tokens, Latenz, Fehler
agentic_session()Sessions-Ansicht: vollständige Konversation für Ursachenanalyse gruppiert
VoteFeedbackSignale: 👍/👎 korreliert mit genauem Trace
Bearbeitungssignale (useFeedbackState)Signale: was Benutzer korrigiert haben – zeigt Modellfehler
Plattform-SyntheticsSignale: automatisierte Qualitätsbewertungen

Schreibe Code mit source=SYNTHETIC nur, wenn der Entwickler explizit danach fragt UND die Plattform es nicht implementieren kann – erkläre, warum die Plattform es nicht handhaben kann und bitte den Entwickler, vor dem Fortfahren zu bestätigen.


Implementierungsfreigabe

Ausnahme: Wenn die Bereitstellung als unbekannt gekennzeichnet wurde UND Geheimnisse nicht sicher verarbeitet werden können, verwende Frage-Slot 3: "Wie stellen Sie bereit? Wie werden Geheimnisse verwaltet?" → befolge references/deployment.md. Überspringe, wenn die Bereitstellung identifiziert oder irrelevant war.

Den vollständigen Implementierungsplan präsentieren, ExitPlanMode zur Freigabe aufrufen, dann implementieren.


API-Schlüssel

Zwei Typen – niemals verwechseln:

  • Geheim (KELET_API_KEY, sk-kelet-...): nur serverseitig. Das SDK akzeptiert beide Schlüsseltypen ohne Fehler – die Verwendung des falschen ist ein stiller Fehler.
  • Öffentlich (VITE_KELET_PUBLISHABLE_KEY / NEXT_PUBLIC_KELET_PUBLISHABLE_KEY, pk-kelet-...): nur frontend.

In die Konfiguration schreiben: .env → KEY=Wert · .envrc → export KEY=Wert · K8s → Secrets-Manifest. Zu .gitignore hinzufügen. Niemals Projektnamen hartcodieren – immer Umgebungsvariable. Wenn die App sowohl einen Server als auch ein Frontend hat, Schlüssel in beide .env-Dateien schreiben – geheimen Schlüssel in das Server-.env, öffentlichen Schlüssel in frontend/.env (oder wo auch immer Vite/Next ihn aufnimmt). Befolge references/deployment.md für die Produktion.


Sessions

Eine Session = eine Arbeitseinheit. Neuer Kontext = neue Session.

agentic_session() NICHT erforderlich (automatisch instrumentiert): LangChain/LangGraph · LlamaIndex · CrewAI · Haystack · Google ADK (kelet[google-adk] empfohlen) · pydantic-ai · DSPy · Langfuse · Langroid · alles, was OpenInference/OpenLLMetry verwendet

⚠️ Überschreibung – lies zuerst den ERFORDERLICH-Block unten. Die obige Liste geht davon aus, dass das Framework auch die Session-ID besitzt (kurzlebige In-Prozess-Läufe). Wenn die App die Session-ID selbst generiert (Redis, DB, serverausgestellte UUID) oder du mehrere LLM-Aufrufe über Anfragen hinweg orchestrierst, ist agentic_session(session_id=...) ERFORDERLICH unabhängig vom Framework – das Framework kennt deine ID nicht und Spannen werden unverlinkt. Im Zweifelsfall einkapseln.

⚠️ Reines LiteLLM – Traces werden automatisch erfasst, aber LiteLLM propagiert keine Session-/Agent-Kontexte in seine Spannen. Wenn LiteLLM direkt aufgerufen wird (nicht über ein anderes unterstütztes Framework wie Google ADK), kapsele die Aufrufe in agentic_session() (und optional kelet.agent()) ein, um sie zu gruppieren. Wenn LiteLLM unter einem anderen instrumentierten Framework läuft, liefert die übergeordnete Spanne den Kontext – kein Einkapseln erforderlich.

Wenn nicht aufgeführt – vor dem Weglassen recherchieren.

agentic_session(session_id=...) ERFORDERLICH (beide still, wenn weggelassen):

  • App besitzt die Session-ID (Redis, DB, servergeneriert): Framework kennt sie nicht → VoteFeedback-Verknüpfung bricht
  • Du besitzt die Schleife (Agent A → Agent B, Temporal, benutzerdefinierte Orchestratoren): kein Framework setzt die gesamte Session-ID → Spannen erscheinen als unverlinkte Traces. TS: agenticSession({ sessionId }, callback).

⚠️ Vercel AI SDK – unterstütztes Framework, setzt aber keine Session-IDs: Verwende agenticSession() auf Routenebene.

Benutzeridentität ≠ Session-ID. Stabile Identifikatoren (Telefon, E-Mail, user_id) überdauern Sessions. Wenn die App eine stabile Benutzeridentität hat: Generiere UUID pro Konversation als kelet_session_id, generiere bei Zurücksetzen neu. Bewerte den Identifikator still: Nicht-PII (interne Benutzer-ID, undurchsichtige UUID) → als user_id= ohne Nachfragen verdrahten. Offensichtliche PII (Telefon, E-Mail) → weglassen, aber deutlich hervorheben: "⚠️ user_id= wurde nicht gesetzt – Ihr Benutzeridentifikator ist PII (Telefon/E-Mail). Wenn Sie eine Nicht-PII-Benutzer-ID haben, übergeben Sie sie hier, um eine Ursachenanalyse pro Benutzer zu ermöglichen." Wirklich mehrdeutig → in Meilenstein 1 aufnehmen, keinen separaten Slot verschwenden.

Siehe references/api.md für Signaturen. Siehe references/stack-notes.md für pro-Stack-typische Fallstricke.


Implementierungsreferenz

Siehe references/implementation.md für Details.


Sprachspezifische Details

Python:

import kelet

kelet.configure(api_key="sk-...", project="my-project")

Node.js / TypeScript:

import * as kelet from "kelet";

kelet.configure({ apiKey: "sk-...", project: "my-project" });

Go:

import "github.com/kelet-ai/kelet-go"

kelet.Configure(kelet.Config{APIKey: "sk-...", Project: "my-project"})

Fehlerbehebung

ProblemMögliche UrsacheLösung
Keine Traces in der KonsoleFalscher API-Schlüssel-Typ (öffentlich statt geheim)Verwende sk-kelet-... Schlüssel
Traces erscheinen, aber keine SignaleFalscher ProjektnameÜberprüfe den Projektnamen in der Konsole
VoteFeedback funktioniert nichtFehlender öffentlicher SchlüsselFüge VITE_KELET_PUBLISHABLE_KEY oder NEXT_PUBLIC_KELET_PUBLISHABLE_KEY hinzu

Nächste Schritte

  1. Vollständige Dokumentation durchlesen
  2. Kelet in deiner App konfigurieren
  3. Signale und Analysen in der Kelet-Konsole erkunden
  4. Bei Bedarf mehr codierte Signale hinzufügen

Verwandte Skills