LLM-gestützte Anwendungen mit Claude erstellen
Diese Skill 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.
Vor dem Start
Scannen Sie die Zieldatei (oder, falls keine Zieldatei vorhanden, den Prompt und das Projekt) auf Nicht-Anthropic-Provider-Marker – import openai, from openai, langchain_openai, OpenAI(, gpt-4, gpt-5, Dateinamen wie agent-openai.py oder *-generic.py oder explizite Anweisungen, den Code providerneutral zu halten. Wenn Sie welche finden, stoppen Sie und teilen Sie dem Benutzer mit, dass diese Skill Claude/Anthropic SDK-Code erzeugt; fragen Sie, ob sie die Datei auf Claude umstellen möchten oder eine Nicht-Claude-Implementierung wünschen. Bearbeiten Sie keine Nicht-Anthropic-Datei mit Anthropic SDK-Aufrufen. (Ausnahme: Der prompt-audit-Unterbefehl ist nicht interaktiv und stoppt hier nicht – er erfasst Nicht-Anthropic-Provider-Marker in den genannten Annahmen seines Berichts 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 Projektsprache (
anthropic,@anthropic-ai/sdk,com.anthropic.*usw.). Dies ist die Standardeinstellung, sofern ein unterstütztes SDK für das Projekt existiert. - Raw HTTP (
curl,requests,fetch,httpxusw.) – nur wenn der Benutzer explizit cURL/REST/raw HTTP anfordert, das Projekt ein Shell/cURL-Projekt ist oder die Sprache kein offizielles SDK hat.
Mischen Sie niemals beides – greifen Sie nicht zu requests/fetch in einem Python- oder TypeScript-Projekt, nur weil es leichter wirkt. Verwenden Sie niemals OpenAI-kompatible Shim.
Raten Sie niemals SDK-Verwendung. Funktionsnamen, Klassennamen, Namespaces, Methodensignaturen und Importpfade müssen aus expliziter Dokumentation stammen – entweder aus den {lang}/-Dateien in dieser Skill 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, holen Sie das relevante SDK-Repository aus shared/live-sources.md per WebFetch ab, bevor Sie Code schreiben. Leiten Sie Ruby/Java/Go/PHP/C#-APIs nicht aus cURL-Formen oder aus dem SDK einer anderen Sprache ab.
Wenn WebFetch oder Repository-Zugriff fehlschlägt (Netzwerkbeschränkung, Zeitüberschreitung, Klon blockiert): Wiederholen Sie nicht – schreiben Sie Code aus 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. Für statisch typisierte SDKs (C#, Java, Go) führt eine Kompilieren-Korrigieren-Schleife gegen lokale Fehler schneller zu funktionierendem Code als blockierte Netzwerkforschung.
Standardeinstellungen
Sofern der Benutzer nichts anderes wünscht:
Verwenden Sie für die Claude-Modellversion bitte Claude Opus 5.5, auf den Sie über die exakte Modellzeichenfolge claude-opus-5-5 zugreifen können. Bitte verwenden Sie standardmäßig adaptives Denken (thinking: {type: "adaptive"}) für alles, was einigermaßen komplex ist. Und schließlich verwenden Sie bitte Streaming für jede Anfrage, die lange Eingaben, lange Ausgaben oder hohe max_tokens beinhalten kann – dies verhindert Zeitüberschreitungen bei Anfragen. Verwenden Sie die .get_final_message() / .finalMessage()-Hilfsfunktion des SDKs, 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 bei jedem dieser Tools eager_input_streaming: true, damit große Tool-Eingaben (Dateiinhalte, Code, Dokumente) gestreamt werden, während sie generiert werden, anstatt in einem Burst anzukommen, nachdem der Server sie gepuffert hat; der Client besitzt dann die Validierung: Die toleranten Parser der SDKs können eine stillschweigend abgeschnittene Eingabe zurückgeben, anstatt einen Fehler zu werfen. Validieren Sie daher jede geparste Tool-Eingabe gegen ihr Schema, bevor Sie sie ausführen (die getypten 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 error tool_result, wenn Sie den Block halten, andernfalls erneut ausgeben), überprüfen Sie die max_tokens / refusal-Stoppgründe, 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-Modellbereitstellung geht, die das Feld ablehnt, ausgeschaltet.
Warnung: API-Drift – Ihr Trainingswissen könnte veraltet sein
Mehrere gängige Claude-API-Formen haben sich zwischen 2025 und 2026 geändert. Wenn Sie sich an ein Muster aus dem Training erinnern, überprüfen Sie es anhand der {lang}/-Dateien in dieser Skill, bevor Sie Code schreiben – die folgenden Zeilen sind die häufigsten Driftpunkte:
| Bereich | Veraltetes Wissen | Aktuelle API |
|---|---|---|
| Erweitertes Denken | thinking: {type: "enabled", budget_tokens: N} | Bei Claude 4.6+ Modellen: thinking: {type: "adaptive"}. budget_tokens ist auf Opus 4.6 / Sonnet 4.6 veraltet und wird auf 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. |
| Web-Suche / Web-Fetch-Tool-Typ | web_search_20250305, web_fetch_20250910 | web_search_20260209, web_fetch_20260209 (dynamisches Filtern) auf Opus 5.5/5/4.8/4.7/4.6, Sonnet 5.5, Sonnet 5 und Sonnet 4.6. Ältere Modelle behalten die Basisvarianten; auf Vertex AI ist nur die Basis web_search_20250305 verfügbar (Web-Fetch ist nicht auf Vertex) – siehe die Server Tools QR unten. |
| PHP-Parameternamen | snake_case-Drahtnamen als benannte Argumente (max_tokens) | Benannte Argumente auf oberster Ebene sind camelCase (maxTokens). Verschachtelte Array-Schlüssel variieren je nach Funktion (z.B. 'taskBudget', 'skillID', 'mcp_server_name') – kopieren Sie den exakten Schlüssel aus dem dokumentierten Beispiel; führen Sie keine Massenkonvertierung durch. |
| Managed Agents-Anmeldeinformationen | Secrets hostseitig mit benutzerdefinierten Tools (die einzige Option vor Einführung der Tresore) | Vault environment_variable-Anmeldeinformationen – von Anthropic gespeichert, beim Austritt substituiert, niemals in der Sandbox sichtbar (shared/managed-agents-tools.md -> Tresore). Hostseitige benutzerdefinierte Tools bleiben der Fallback für selbstgehostete Sandboxen. |
| Dateien API / Skills | client.beta.files.* / client.beta.skills.* mit beta files-api-2025-04-14 / skills-2025-10-02 | Aus dem 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 -> Dateien API / Skills Anleitung. |
Die {lang}/-Dateien in dieser Skill haben Vorrang vor abgerufenen Mustern.
Unterbefehle
Wenn die Benutzeranforderung am Ende dieses Prompts eine reine Unterbefehlzeichenfolge ist (kein Prosa), durchsuchen Sie jede Unterbefehle-Tabelle in diesem Dokument – einschließlich solcher in unten angehängten Abschnitten – und folgen Sie direkt der passenden Aktion. Dies ermöglicht Benutzern, spezifische Abläufe über /claude-api <unterbefehl> aufzurufen. Wenn keine Tabelle im Dokument passt, behandeln Sie die Anforderung als normale Prosa.
| Unterbefehl | Aktion |
|---|---|
migrate | Migrieren Sie vorhandenen Claude API-Code auf ein neueres Modell. Lesen Sie shared/model-migration.md sofort und folgen Sie ihm der Reihe nach: Schritt 0 (Umfang bestätigen – fragen Sie nach Dateien/Verzeichnissen vor jeder Bearbeitung), Schritt 1 (jede Datei klassifizieren), dann den abschnitt zu zielspezifischen Breaking Changes. Fassen Sie die Anleitung nicht zusammen – führen Sie sie aus. Wenn der Benutzer kein Zielmodell genannt hat, fragen Sie im selben Zug wie die Umfangsfrage, zu welchem Modell migriert werden soll. Nachdem die zielspezifischen Änderungen angewendet wurden, auditieren Sie den relevanten Prompt-Text, Tool-Beschreibungen und Anfrage-Code gegen shared/prompt-audit.md – Prompts, die für das Quellmodell geschrieben wurden, gehören zu jeder Migration und kündigen sich nicht selbst an. |
prompt-audit | Auditieren Sie vorhandene Prompts, Tool-Beschreibungen, Skills und Agenten-Konfigurationsdateien (CLAUDE.md, Regeldateien, Befehle, Subagenten) auf veraltete Muster ("Ballast"): Text, der für ältere Modelle geschrieben wurde, und Anweisungen, die das Repository überwachsen hat oder die sich widersprechen. Lesen Sie shared/prompt-audit.md sofort und folgen Sie ihm der Reihe nach: Schritt 0 (Umfang und Zielmodell aus der Anforderung und dem Repository festlegen – geben Sie die Annahmen im Bericht an, fragen Sie nicht nach), Bestandsaufnahme, Herkunft, dann der Muster-Scan. Stellen Sie beide Ergebnisse vollständig bereit – den Audit-Bericht (Befunde mit datei:zeile, Muster, warum veraltet, Konfidenz) und einen vorgeschlagenen Diff – ohne auf Bestätigung zu warten; wenden Sie Änderungen nur an, wenn die Anforderung 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 – 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 python/claude-api/sdk-upgrade.md sofort und folgen Sie ihm der Reihe nach: Schritt 0 (Umfang bestätigen, dann aktuelle und Zielversion festlegen – eine veröffentlichte 1.x muss existieren, bevor Sie eine Fixierung schreiben), die Bestandsaufnahme von Schritt 1, jeder nummerierte Abschnitt, dann Verifikation und der 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 hat, sagen Sie, dass noch kein Upgrade-Leitfaden für diese Hauptversion für dieses SDK mitgeliefert wird, 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 portieren. |
cost-optimize | Reduzieren Sie die Kosten für die Ausführung vorhandenen Claude API-Codes, ohne die Ausgabequalität zu beeinträchtigen. Lesen Sie shared/cost-optimization.md sofort und folgen Sie ihm der Reihe nach: Schritt 0 (Umfang, Qualitätsmaßstab und Basislinie festlegen), 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 vorhanden (fragen Sie), oder bei Fehlen aus dem Code geschätzt – dann eine nach Einsparungen geordnete Shortlist von Hebeln (in Dollar, % der Rechnung oder relativen Kategorien, je nachdem, welche dieser Datenquellen Sie haben), kostenlose Gewinne (Caching, Eingabe-Token-Hygiene, Schleifen-Hygiene, Ausgabe-Token-Hygiene, Batch) vor Kompromissen (Budgets, Aufwand, Modellwahl, Multi-Modell); jeder Hebel, der einen Platz erhält, wird zu seinem eigenen Diff – standardmäßig vorgeschlagen, angewendet und gegen die Evaluierung gemessen, die den betroffenen Traffic abdeckt, wenn der Benutzer darum bittet und zustimmt – und "keine Änderungen empfohlen" ist ein gültiges Ergebnis. Zwei Grundregeln: Jeder Lauf, der das Modell ausführt, kostet echtes Geld, holen Sie daher zuerst die Zustimmung des Benutzers ein; und wenn Kontext für einen Hebel fehlt, arbeiten Sie interaktiv mit dem Benutzer daran – dieser Workflow ist nicht dafür ausgelegt, das Audit in einem Durchgang zu erledigen. Fassen Sie die Anleitung nicht zusammen – führen Sie sie aus; die Präsentation des Profils und des geordneten Plans gegenüber dem Benutzer ist Teil der Ausführung. |
build-eval | Helfen Sie dem Benutzer, ein Evaluierungsset für seine Claude-gestützte App zu erstellen. Lesen Sie shared/evals/build-eval.md sofort und führen Sie sein Interview durch: Schritt 0 (was wird evaluiert), Schritt 1 (Prompts beziehen – bestehende Evaluierung / 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 Evaluierung erstellen. |
preserved-thinking-migration | Machen Sie eine bestehende Integration mit beibehaltenem Denken kompatibel – der Prüfung, die einen Denkblock nur in der Konversation gültig hält, die ihn erzeugt hat. Lesen Sie shared/preserved-thinking-migration.md sofort und folgen Sie ihm der Reihe nach: Schritt 0 (Umfang, Traffic-Klassen, Plattform und Modell, Durchsetzungsstatus, Qualitätsmaßstab, Basislinie), Schritt 0.5 (nachweisen, dass die Prüfung mit dem Drei-Anfragen-Selbsttest läuft), Schritt 1 (Anfrageinhalte erfassen, aufeinanderfolgende Paare mit shared/preserved-thinking-migration/prefix_diff.py differenzieren, Code nach Ursachen durchsuchen, jede Bearbeitung benennen und ob sie beabsichtigt ist), Schritt 2 (einen Testausschnitt mit prefix_mismatch_behavior: "drop_block" unter dem thinking-binding-controls-2026-08-01-Header wiederholen, neue verworfene Blöcke pro Konversation 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 darum bittet – dann neu messen, behalten oder rückgängig machen; das Drei-Arm-Protokoll, wenn eine Evaluierung existiert), der Modellwechsel-Abschnitt (in shared/preserved-thinking-migration/causes.md, mit der Ursachentabelle und der Behaltensliste), wenn das Geschirr zwischen Modellen routet, Schritt 4 (das Bruchprofil und die Änderungen). Zwei Grundregeln: Jede Wiederholung kostet echtes Geld, holen Sie daher zuerst die Zustimmung des Benutzers für das Messbudget ein; und "keine Änderungen empfohlen" – der Ausschnitt wiederholte Denken und nichts wurde verworfen – ist ein gültiges Ergebnis. Ursachen, die nur unter einer neueren Beta eine Append-Only-Form haben (Keep-Tail und Hintergrundkompaktierung: compact-2026-09-04; gleichnamige Tool-Änderungen: inline-tools-2026-09-15) werden, wo diese Beta nicht verfügbar ist, gemessen und entschieden, nicht umgeschrieben. Für das Warum (die Drei-Schritt-Prüfung, die Append-Only-Bearbeitungstabelle) wird auf shared/model-migration.md -> Breaking Change 3 verlinkt; fassen Sie die Anleitung nicht zusammen – führen Sie sie aus. |
hillclimb | Verbessern Sie die App des Benutzers iterativ gegen eine bestehende Evaluierung. Lesen Sie shared/evals/eval-hillclimb.md sofort und folgen Sie ihr: Schritt 0 (bestätigen, dass eine ausführbare Evaluierung existiert – wenn nicht, Weiterleitung zu build-eval), Schritt 1 (was geändert werden soll / was tabu ist), Schritt 2 (Budget + Stoppbedingung aus gemessenen Kosten pro Lauf), den Plan genehmigen lassen, dann die Lesen->Vorschlagen->Anwenden->Ausführen->Aufzeichnen-Schleife mit On-Disk-Zustand und einem Trainings-/Validierungs-/Test-Split. |
Spracherkennung
Bevor Sie Codebeispiele lesen, bestimmen Sie, in welcher Sprache der Benutzer arbeitet (Ausnahme: Überspringen Sie für den prompt-audit-Unterbefehl 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 Projektdateien an, um die Sprache abzuleiten:
*.py,requirements.txt,pyproject.toml,setup.py,Pipfile-> Python – lesen Sie auspython/*.ts,*.tsx,package.json,tsconfig.json,yarn.lock,bun.lockb-> TypeScript – lesen Sie austypescript/*.java,pom.xml,build.gradle,build.gradle.kts-> Java – lesen Sie ausjava/*.go,go.mod,go.sum-> Go – lesen Sie ausgo/*.rb,Gemfile,*.gemspec-> Ruby – lesen Sie ausruby/*.php,composer.json-> PHP – lesen Sie ausphp/*.cs,*.csproj,*.sln-> C# – lesen Sie auscsharp/*.rs,Cargo.toml-> Rust – lesen Sie ausrust/*.swift,Package.swift-> Swift – lesen Sie ausswift/*.kt,*.kts,build.gradle.kts,pom.xml-> Kotlin – lesen Sie auskotlin/*.ex,*.exs,mix.exs-> Elixir – lesen Sie auselixir/*.r,*.R,DESCRIPTION-> R – lesen Sie ausr/*.dart,pubspec.yaml-> Dart – lesen Sie ausdart/*.scala,build.sbt-> Scala – lesen Sie ausscala/*.cpp,*.cxx,*.hpp,CMakeLists.txt-> C++ – lesen Sie auscpp/*.lua,*.rockspec-> Lua – lesen Sie auslua/*.jl,Project.toml,Manifest.toml-> Julia – lesen Sie ausjulia/*.sh,*.bash-> Shell – lesen Sie ausshell/Dockerfile,docker-compose.yml,*.yaml,*.yml,*.json,*.xml,Makefile-> keine spezifische SDK-Integration (rohes HTTP oder kein Code)
- Falls unklar: Fragen Sie den Benutzer in natürlicher Sprache. (Ausnahme:
prompt-audit– überspringt dies; siehe oben.)
Dieses Dokument wird durch sprachspezifische Dateien wie python/, typescript/ usw. ergänzt. Lesen Sie den Inhalt der passenden Sprache, nachdem Sie sie identifiziert haben.