LLM-gestützte Anwendungen mit Claude erstellen
Diese Skill-Datei hilft Ihnen, LLM-gestützte Anwendungen mit Claude zu erstellen. Wählen Sie die richtige Oberfläche basierend auf Ihren Anforderungen, erkennen Sie die Projektsprache und lesen Sie dann die entsprechende sprachspezifische Dokumentation.
Bevor Sie beginnen
Durchsuchen Sie die Zieldatei (oder, wenn keine Zieldatei vorhanden ist, die Eingabeaufforderung und das Projekt) nach Markierungen für Nicht-Anthropic-Anbieter – import openai, from openai, langchain_openai, OpenAI(, gpt-4, gpt-5, Dateinamen wie agent-openai.py oder *-generic.py oder explizite Anweisungen, den Code anbieterneutral zu halten. Wenn Sie welche finden, brechen Sie ab und teilen Sie dem Benutzer mit, dass diese Skill-Datei Claude/Anthropic SDK-Code erzeugt; fragen Sie, ob er die Datei auf Claude umstellen möchte oder eine Nicht-Claude-Implementierung wünscht. Bearbeiten Sie keine Nicht-Anthropic-Datei mit Anthropic SDK-Aufrufen. (Ausnahme: Der Unterbefehl prompt-audit ist nicht-interaktiv und stoppt hier nicht – er zeichnet Markierungen für Nicht-Anthropic-Anbieter in den angegebenen Annahmen seines Berichts auf und schlägt niemals vor, eine Nicht-Anthropic-Datei auf das Anthropic SDK umzustellen.)
Ausgabeanforderung
Wenn der Benutzer Sie bittet, eine Claude-Funktion hinzuzufügen, zu ändern oder zu implementieren, muss Ihr Code Claude über eine der folgenden Möglichkeiten aufrufen:
- Das offizielle Anthropic SDK für die Sprache des Projekts (
anthropic,@anthropic-ai/sdk,com.anthropic.*, etc.). Dies ist die Standardeinstellung, sofern ein unterstütztes SDK für das Projekt existiert. - Raw HTTP (
curl,requests,fetch,httpx, etc.) – nur, wenn der Benutzer ausdrücklich cURL/REST/raw HTTP verlangt, das Projekt ein Shell/cURL-Projekt ist oder die Sprache kein offizielles SDK hat.
Mischen Sie niemals beides – greifen Sie nicht auf requests/fetch in einem Python- oder TypeScript-Projekt zurück, nur weil es sich leichter anfühlt. Verwenden Sie niemals OpenAI-kompatible Shimms.
Raten Sie niemals SDK-Nutzung. Funktionsnamen, Klassennamen, Namespaces, Methodensignaturen und Importpfade müssen aus expliziter Dokumentation stammen – entweder aus den {lang}/-Dateien in dieser Skill-Datei oder aus den offiziellen SDK-Repositorys oder Dokumentationslinks, die in shared/live-sources.md aufgeführt sind. Wenn die benötigte Bindung nicht explizit in den Skill-Dateien dokumentiert ist, rufen Sie vor dem Schreiben von Code das entsprechende SDK-Repository aus shared/live-sources.md mit WebFetch ab. Leiten Sie Ruby/Java/Go/PHP/C#-APIs nicht aus cURL-Formen oder aus dem SDK einer anderen Sprache ab.
Wenn WebFetch oder der Repository-Zugriff fehlschlägt (Netzwerkbeschränkung, Timeouts, Clone blockiert): Wiederholen Sie es nicht – schreiben Sie Code basierend auf den Mustern und Namespace/Paket-Tabellen in der {lang}/-Datei, führen Sie den Compiler oder Interpreter aus und iterieren Sie basierend auf der Fehlerausgabe. Bei statisch typisierten SDKs (C#, Java, Go) führt eine Compile-Fix-Schleife gegen lokale Fehler schneller zu funktionierendem Code als blockierte Netzwerkrecherche.
Voreinstellungen
Sofern der Benutzer nichts anderes wünscht:
Verwenden Sie für die Claude-Modellversion bitte Claude Opus 5.5, auf das Sie über die genaue Modellzeichenfolge claude-opus-5-5 zugreifen können. Verwenden Sie standardmäßig adaptives Denken (thinking: {type: "adaptive"}) für alles Komplexe. Und schließlich verwenden Sie standardmäßig Streaming für jede Anfrage, die lange Eingaben, lange Ausgaben oder hohe max_tokens beinhalten kann – dies verhindert das Erreichen von Anfragetimeouts. Verwenden Sie den SDK-Helfer .get_final_message() / .finalMessage(), um die vollständige Antwort zu erhalten, wenn Sie keine einzelnen Stream-Ereignisse behandeln müssen. Wenn eine Streaming-Anfrage benutzerdefinierte (Client-)Tools definiert, setzen Sie eager_input_streaming: true für jedes dieser Tools, sodass große Tool-Eingaben (Dateiinhalte, Code, Dokumente) gestreamt werden, während sie generiert werden, anstatt in einem Schub anzukommen, nachdem der Server sie gepuffert hat; der Client übernimmt dann die Validierung: Die tolerantenen Parser der SDKs können eine stillschweigend abgeschnittene Eingabe zurückgeben, anstatt eine Ausnahme auszulösen. Validieren Sie daher jede geparste Tool-Eingabe gegen ihr Schema, bevor Sie sie ausführen (die typisierten Runner-Helfer wie betaZodTool / getyptes @beta_tool tun dies; betaTool() JSON-Schema-Tools und manuelle Schleifen müssen sich selbst validieren), behandeln Sie einen Fehler wie ungültiges JSON (INVALID_JSON Fehler tool_result, wenn Sie den Block halten, andernfalls erneut ausgeben), überprüfen Sie die Stop-Gründe max_tokens / refusal, bevor Sie Tools ausführen, und fangen Sie nur den JSON-Fehler des SDKs ab, niemals seine typisierten API-Fehler – Muster in shared/tool-use-concepts.md -> Eager input streaming. Lassen Sie es für Nicht-Streaming-Anfragen, für Server-Tools und wenn die Anfrage über einen Proxy oder eine ältere Bedrock-Modell-Bereitstellung geht, die das Feld ablehnt, ausgeschaltet.
Warnung: API-Drift – Ihr Trainingswissen könnte veraltet sein
Mehrere gängige Claude-API-Formen haben sich in den Jahren 2025–2026 geändert. Wenn Sie sich an ein Muster aus dem Training erinnern, überprüfen Sie es anhand der {lang}/-Dateien in dieser Skill-Datei, bevor Sie Code schreiben – die folgenden Zeilen sind die häufigsten Driftpunkte:
| Bereich | Veraltete Form | Aktuelle API |
|---|---|---|
| Erweitertes Denken | thinking: {type: "enabled", budget_tokens: N} | Bei Modellen ab Claude 4.6: thinking: {type: "adaptive"}. budget_tokens ist bei Opus 4.6 / Sonnet 4.6 veraltet und wird bei Fable 5/5.1 / Sonnet 5.5 / Sonnet 5 / Opus 5.5 / 5 / 4.8 / 4.7 mit einem 400-Fehler abgelehnt. Modelle vor 4.6 verwenden weiterhin budget_tokens. |
| Websuche / Web-Fetch-Tool-Typ | web_search_20250305, web_fetch_20250910 | web_search_20260209, web_fetch_20260209 (dynamisches Filtern) bei Opus 5.5/5/4.8/4.7/4.6, Sonnet 5.5, Sonnet 5 und Sonnet 4.6. Ältere Modelle behalten die einfachen Varianten; auf Vertex AI ist nur die einfache web_search_20250305 verfügbar (Web-Fetch ist nicht auf Vertex) – siehe die Server-Tools-QR unten. |
| PHP-Parameternamen | snake_case-Wire-Namen als benannte Argumente (max_tokens) | Benannte Argumente der obersten Ebene sind camelCase (maxTokens). Verschachtelte Array-Schlüssel variieren je nach Funktion (z. B. 'taskBudget', 'skillID', 'mcp_server_name') – kopieren Sie den genauen Schlüssel aus dem dokumentierten Beispiel; konvertieren Sie nicht alle. |
| Managed Agents-Anmeldeinformationen | Geheimnisse hostseitig über benutzerdefinierte Tools aufbewahren (die einzige Option, bevor Tresore ausgeliefert wurden) | Vault environment_variable-Anmeldeinformationen – von Anthropic gespeichert, beim Egress substituiert, nie in der Sandbox sichtbar (shared/managed-agents-tools.md -> Vaults). Hostseitige benutzerdefinierte Tools bleiben der Fallback für selbst gehostete Sandboxen. |
| Files API / Skills | client.beta.files.* / client.beta.skills.* mit Beta-Header files-api-2025-04-14 / skills-2025-10-02 | Aus der Beta: client.files.* / client.skills.*, kein Beta-Header. In aktuellen SDKs haben client.beta.files / client.beta.skills brechende Formänderungen gegenüber früheren Versionen, die den stabilen Namespaces entsprechen – migrieren Sie gemäß shared/live-sources.md -> Files API / Skills Guide. |
Die {lang}/-Dateien in dieser Skill-Datei sind maßgeblich gegenüber erinnerten Mustern.
Unterbefehle
Wenn die Benutzeranfrage am Ende dieser Eingabeaufforderung eine reine Unterbefehl-Zeichenfolge ist (keine Prosa), durchsuchen Sie jede Unterbefehle-Tabelle in diesem Dokument – einschließlich solcher in Abschnitten, die unten angehängt sind – und folgen Sie direkt der passenden Aktion-Spalte. Dies ermöglicht es Benutzern, spezifische Abläufe über /claude-api <subcommand> aufzurufen. Wenn keine Tabelle im Dokument übereinstimmt, behandeln Sie die Anfrage als normale Prosa.
| Unterbefehl | Aktion |
|---|---|
migrate | Migrieren Sie vorhandenen Claude-API-Code zu einem neueren Modell. Lesen Sie sofort shared/model-migration.md und folgen Sie ihm der Reihe nach: Schritt 0 (Umfang bestätigen – fragen Sie, welche Dateien/Verzeichnisse, bevor Sie eine Bearbeitung vornehmen), Schritt 1 (jede Datei klassifizieren), dann den Abschnitt mit den Breaking Changes pro Ziel. Fassen Sie die Anleitung nicht zusammen – führen Sie sie aus. Wenn der Benutzer kein Zielmodell genannt hat, fragen Sie im selben Schritt wie die Umfragefrage, zu welchem Modell migriert werden soll. Nachdem die Änderungen pro Ziel angewendet wurden, prüfen Sie den im Umfang enthaltenen Prompt-Text, die Tool-Beschreibungen und den Anfragecode gegen shared/prompt-audit.md – Prompts, die für das Quellmodell geschrieben wurden, sind Teil jeder Migration und kündigen sich nicht selbst an. |
prompt-audit | Prüfen Sie vorhandene Prompts, Tool-Beschreibungen, Skills und Agent-Konfigurationsdateien (CLAUDE.md, Regeldateien, Befehle, Unteragenten) auf veraltete Muster („Cruft“): Text, der für ältere Modelle geschrieben wurde, und Anweisungen, die das Repository überwuchert hat oder die sich widersprechen. Lesen Sie sofort shared/prompt-audit.md und folgen Sie ihm der Reihe nach: Schritt 0 (Umfang und Zielmodell aus der Anfrage und dem Repository ermitteln – geben Sie die Annahmen im Bericht an, stoppen Sie nicht, um zu fragen), Bestandsaufnahme, Herkunft, dann die Musterüberprüfung. Erstellen Sie beide Ergebnisse vollständig – den Prüfbericht (Ergebnisse mit file:line, Muster, warum es veraltet ist, Konfidenz) und einen vorgeschlagenen Diff – ohne auf Bestätigung zu warten; wenden Sie Bearbeitungen nur an, wenn die Anfrage explizit danach gefragt hat. Fassen Sie die Anleitung nicht zusammen – führen Sie sie aus. |
upgrade | Aktualisieren Sie die Anthropic-SDK-Abhängigkeit des Projekts über eine Hauptversion hinweg – derzeit das Python-SDK, anthropic 0.x -> 1.x. Nachfolgende Wörter können die Sprache und/oder einen Umfang nennen (upgrade python, upgrade python sdk src/). Lesen Sie sofort python/claude-api/sdk-upgrade.md und folgen Sie ihm der Reihe nach: Schritt 0 (Umfang bestätigen, dann die aktuellen und Zielversionen ermitteln – eine veröffentlichte 1.x muss existieren, bevor Sie eine Festlegung schreiben), die Bestandsaufnahme in Schritt 1, jeden nummerierten Abschnitt, dann Überprüfung und Bericht. Fassen Sie die Anleitung nicht zusammen – führen Sie sie aus. Wenn die erkannte oder genannte Sprache keine sdk-upgrade.md in dieser Skill-Datei hat, sagen Sie, dass noch kein Upgrade-Leitfaden für eine Hauptversion für dieses SDK beigefügt ist, und verweisen Sie den Benutzer an das CHANGELOG dieses SDKs (Repositorys in shared/live-sources.md); improvisieren Sie keinen aus dem Python-Leitfaden. Dies ist keine Modellmigration – verwenden Sie migrate, um Code auf ein neueres Claude-Modell zu verschieben. |
cost-optimize | Reduzieren Sie die Kosten für die Ausführung vorhandenen Claude-API-Codes, ohne die Ausgabequalität zu beeinträchtigen. Lesen Sie sofort shared/cost-optimization.md und folgen Sie ihm der Reihe nach: Schritt 0 (Umfang, Qualitätsbarriere und Baseline ermitteln), das Token-Profil – gemessen über die Usage and Cost Admin API, wenn der Benutzer einen Admin-API-Schlüssel hat, aus den eigenen response.usage-Protokollen der App, wenn er diese hat (fragen), oder andernfalls aus dem Code geschätzt – dann eine nach Einsparungen sortierte Shortlist von Hebeln (in Dollar, % der Rechnung oder relativen Eimern angegeben, je nachdem, welche dieser Datenquellen Sie haben), kostenlose Gewinne (Caching, Input-Token-Hygiene, Schleifen-Hygiene, Output-Token-Hygiene, Batch) vor Kompromissen (Budgets, Aufwand, Modellauswahl, Multi-Modell); jeder Hebel, der einen Platz erhält, wird zu einem eigenen Diff – standardmäßig vorgeschlagen, angewendet und gegen die Eval gemessen, die den Traffic abdeckt, den er berührt, wenn der Benutzer fragt und zustimmt – und „keine Änderungen empfohlen“ ist ein gültiges Ergebnis. Zwei feste Regeln: Jeder Durchlauf, der das Modell beansprucht, kostet echtes Geld, holen Sie daher zuerst die Zustimmung des Benutzers ein; und wenn der Kontext für einen Hebel fehlt, arbeiten Sie interaktiv mit dem Benutzer – dieser Workflow soll den Audit nicht auf einmal erledigen. Fassen Sie die Anleitung nicht zusammen – führen Sie sie aus; die Präsentation des Profils und des Rankingplans gegenüber dem Benutzer ist Teil der Ausführung. |
build-eval | Helfen Sie dem Benutzer, einen Evaluierungssatz für seine Claude-betriebene App zu erstellen. Lesen Sie sofort shared/evals/build-eval.md und führen Sie dessen Interview durch: Schritt 0 (was wird evaluiert), Schritt 1 (Quelle der Prompts – vorhandene Eval / Transkripte / synthetisiert), Schritt 2 (Bewertungsmethode), Schritt 3 (ausführbares Skript + gemessene Kosten). Holen Sie die explizite Zustimmung des Benutzers zu den Eingaben, der Bewertungsmethode und den Kosten ein, bevor Sie die Eval erstellen. |
preserved-thinking-migration | Machen Sie eine bestehende Integration mit bewahrtem Denken kompatibel – die Prüfung, die einen Denkblock nur in dem Gespräch gültig hält, das ihn erzeugt hat. Lesen Sie sofort shared/preserved-thinking-migration.md und folgen Sie ihm der Reihe nach: Schritt 0 (Umfang, Verkehrsklassen, Plattform und Modell, Durchsetzungsstatus, Qualitätsbarriere, Baseline), Schritt 0.5 (beweisen Sie, dass die Prüfung mit dem Drei-Anfragen-Selbsttest läuft), Schritt 1 (Anfragekörper erfassen, aufeinanderfolgende Paare mit shared/preserved-thinking-migration/prefix_diff.py differenzieren, den Code nach den Ursachen durchsuchen, jede Bearbeitung benennen und ob sie beabsichtigt ist), Schritt 2 (einen Testschnitt mit prefix_mismatch_behavior: "drop_block" unter dem Header thinking-binding-controls-2026-08-01 wiederholen, neue verworfene Blöcke pro Gespräch zählen, den Diagnose-Header lesen, wenn vorhanden), Schritt 3 (eine Ursache pro Diff in der Reihenfolge des verlorenen Denkens – standardmäßig vorgeschlagen, angewendet, wenn der Benutzer fragt – dann neu messen, behalten oder rückgängig machen; das Drei-Arme-Protokoll, wenn eine Eval existiert), der Modellwechsel-Abschnitt (in shared/preserved-thinking-migration/causes.md, mit der Ursachentabelle und der Behalten-Liste), wenn das Geschirr zwischen Modellen routet, Schritt 4 (das Abbruchprofil und die Änderungen). Zwei feste Regeln: Jede Wiederholung kostet echtes Geld, holen Sie daher zuerst die Zustimmung des Benutzers für das Messbudget ein; und „keine Änderungen empfohlen“ – der Schnitt hat das Denken wiederholt und es wurde nichts verworfen – ist ein gültiges Ergebnis. Ursachen, die nur unter einer neueren Beta eine Append-Only-Form haben (Keep-Tail und Hintergrundkomprimierung: compact-2026-09-04; Tool-Änderungen mit demselben Namen: inline-tools-2026-09-15) werden dort, wo diese Beta nicht verfügbar ist, gemessen und entschieden, nicht neu geschrieben. Für das Warum (die Drei-Schritt-Prüfung, die Append-Only-Bearbeitungstabelle) verweist es auf shared/model-migration.md -> Breaking change 3; fassen Sie die Anleitung nicht zusammen – führen Sie sie aus. |
hillclimb | Verbessern Sie iterativ die App des Benutzers gegen eine bestehende Eval. Lesen Sie sofort shared/evals/eval-hillclimb.md und folgen Sie ihm: Schritt 0 (bestätigen, dass eine ausführbare Eval existiert – wenn nicht, leiten Sie zu build-eval weiter), Schritt 1 (was geändert werden soll / was tabu ist), Schritt 2 (Budget + Stoppbedingung aus den gemessenen Kosten pro Durchlauf), lassen Sie sich den Plan genehmigen, dann die Lese-/>Vorschlagen-/>Anwenden-/>Ausführen-/>Aufzeichnen-Schleife mit On-Disk-Zustand und einer Trainings-/Validierungs-/Testsplit. |
Spracherkennung
Bevor Sie Codebeispiele lesen, bestimmen Sie die Sprache, in der der Benutzer arbeitet (Ausnahme: Überspringen Sie für den Unterbefehl prompt-audit die Frageschritte dieses Abschnitts – der Audit ist nicht-interaktiv und seine Bestandsaufnahme ist sprachunabhängig; wenn keine Sprache ableitbar ist, fahren Sie fort, ohne zu fragen, und geben Sie die Annahme im Bericht an):
- Sehen Sie sich die Projektdateien an, um die Sprache abzuleiten:
*.py,requirements.txt,pyproject.toml,setup.py,Pipfile-> Python – lesen Sie auspython/*.ts,*.tsx,package.json,yarn.lock,pnpm-lock.yaml-> TypeScript – lesen Sie austypescript/*.js,package.json,yarn.lock,pnpm-lock.yaml(keintsconfig.json, keine*.ts-Dateien) -> JavaScript – lesen Sie ausjavascript/pom.xml,build.gradle,*.java-> Java – lesen Sie ausjava/go.mod,*.go-> Go – lesen Sie ausgo/composer.json,*.php-> PHP – lesen Sie ausphp/*.rb,Gemfile-> Ruby – lesen Sie ausruby/*.cs,*.csproj,*.sln-> C# – lesen Sie ausdotnet/csharp/*.fs,*.fsproj-> F# – lesen Sie ausdotnet/fsharp/Cargo.toml,*.rs-> Rust – lesen Sie ausrust/*.kt,*.kts-> Kotlin – lesen Sie auskotlin/*.swift,Package.swift-> Swift – lesen Sie ausswift/requirements.txt,*.pyUNDpyproject.tomlmit[tool.anthropic]-> Claude CLIMakefilemitcurl-Befehlen,*.shmitcurl-Aufrufen -> Shell/cURL – lesen Sie ausshell/
Wenn Sie keine eindeutige Sprache ableiten können, fragen Sie den Benutzer: „In welcher Sprache soll ich die Codebeispiele verwenden? (Python / TypeScript / JavaScript / Java / Go / PHP / Ruby / C# / F# / Rust / Kotlin / Swift / Shell)“
[Der Rest des Dokuments ist aus Gründen der Kürze abgeschnitten, aber die Struktur mit sprachspezifischen Abschnitten wird fortgesetzt.]