Construction d'applications avec Claude et les LLM
Ce skill vous aide à construire des applications avec Claude et les LLM. Choisissez la bonne surface selon vos besoins, détectez le langage du projet, puis lisez la documentation spécifique au langage.
Avant de commencer
Scannez le fichier cible (ou, s'il n'y a pas de fichier cible, le prompt et le projet) pour détecter des marqueurs de fournisseur non-Anthropic — import openai, from openai, langchain_openai, OpenAI(, gpt-4, gpt-5, des noms de fichiers comme agent-openai.py ou *-generic.py, ou toute instruction explicite de rester neutre vis-à-vis du fournisseur. Si vous en trouvez, arrêtez-vous et dites à l'utilisateur que ce skill produit du code pour le SDK Claude/Anthropic ; demandez s'il souhaite basculer le fichier vers Claude ou une implémentation non-Claude. Ne modifiez pas un fichier non-Anthropic avec des appels au SDK Anthropic. (Exception : la sous-commande prompt-audit est non interactive et ne s'arrête pas ici — elle enregistre les marqueurs de fournisseur non-Anthropic dans les hypothèses de son rapport et ne propose jamais de basculer un fichier non-Anthropic vers le SDK Anthropic.)
Exigence de sortie
Lorsque l'utilisateur vous demande d'ajouter, de modifier ou d'implémenter une fonctionnalité Claude, votre code doit appeler Claude via l'une des méthodes suivantes :
- Le SDK officiel Anthropic pour le langage du projet (
anthropic,@anthropic-ai/sdk,com.anthropic.*, etc.). C'est la méthode par défaut chaque fois qu'un SDK supporté existe pour le projet. - HTTP brut (
curl,requests,fetch,httpx, etc.) — uniquement lorsque l'utilisateur demande explicitement cURL/REST/HTTP brut, que le projet est un projet shell/cURL, ou que le langage ne dispose pas de SDK officiel.
Ne mélangez jamais les deux — n'utilisez pas requests/fetch dans un projet Python ou TypeScript simplement parce que cela semble plus léger. Ne recourez jamais à des shims compatibles OpenAI.
Ne devinez jamais l'utilisation du SDK. Les noms de fonctions, noms de classes, espaces de noms, signatures de méthodes et chemins d'importation doivent provenir d'une documentation explicite — soit des fichiers {lang}/ de ce skill, soit des dépôts officiels du SDK ou des liens de documentation listés dans shared/live-sources.md. Si la liaison dont vous avez besoin n'est pas explicitement documentée dans les fichiers du skill, effectuez une WebFetch du dépôt SDK concerné depuis shared/live-sources.md avant d'écrire le code. N'inférez pas les API Ruby/Java/Go/PHP/C# à partir de formes cURL ou d'un SDK d'un autre langage.
Si WebFetch ou l'accès au dépôt échoue (réseau restreint, timeouts, clone bloqué) : ne continuez pas à réessayer — écrivez le code à partir des motifs et des tables d'espaces de noms/paquets dans le fichier {lang}/, exécutez le compilateur ou l'interpréteur, et itérez sur les messages d'erreur. Pour les SDK à typage statique (C#, Java, Go), une boucle de compilation-correction sur les erreurs locales atteint un code fonctionnel plus rapidement qu'une recherche réseau bloquée.
Valeurs par défaut
Sauf demande contraire de l'utilisateur :
Pour la version du modèle Claude, veuillez utiliser Claude Opus 5.5, accessible via la chaîne exacte du modèle claude-opus-5-5. Par défaut, utilisez la pensée adaptative (thinking: {type: "adaptive"}) pour tout ce qui est un tant soit peu complexe. Enfin, utilisez par défaut le streaming pour toute requête pouvant impliquer une longue entrée, une longue sortie ou un max_tokens élevé — cela évite les timeouts de requête. Utilisez l'assistant .get_final_message() / .finalMessage() du SDK pour obtenir la réponse complète si vous n'avez pas besoin de gérer les événements de streaming individuels. Lorsqu'une requête en streaming définit des outils (clients) définis par l'utilisateur, définissez eager_input_streaming: true sur chacun de ces outils afin que les entrées volumineuses des outils (contenus de fichiers, code, documents) soient diffusées en continu au fur et à mesure de leur génération, au lieu d'arriver en une seule rafale après que le serveur a fini de les mettre en mémoire tampon ; le client possède alors la validation : les analyseurs tolérants des SDK peuvent renvoyer une entrée silencieusement tronquée au lieu de déclencher une erreur, donc validez chaque entrée d'outil analysée par rapport à son schéma avant de l'exécuter (les assistants d'exécution typés tels que betaZodTool / @beta_tool typé le font ; les outils betaTool() basés sur un schéma JSON et les boucles manuelles doivent se valider elles-mêmes), traitez un échec comme un JSON invalide (erreur tool_result INVALID_JSON lorsque vous détenez le bloc, réémettez sinon), vérifiez les raisons d'arrêt max_tokens / refusal avant d'exécuter les outils, et interceptez uniquement l'erreur JSON du SDK, jamais ses erreurs d'API typées — motif dans shared/tool-use-concepts.md -> Eager input streaming. Désactivez-le pour les requêtes non streamées, pour les outils serveur, et lorsque la requête passe par un proxy ou un déploiement Bedrock plus ancien qui rejette le champ.
Avertissement : Dérive de l'API — Votre priorité d'apprentissage peut être obsolète
Plusieurs formes courantes de l'API Claude ont changé en 2025-2026. Si vous vous souvenez d'un motif de l'apprentissage, vérifiez-le dans les fichiers {lang}/ de ce skill avant d'écrire — les lignes ci-dessous sont les points de dérive les plus fréquents :
| Domaine | Priorité obsolète | API actuelle |
|---|---|---|
| Pensée étendue | thinking: {type: "enabled", budget_tokens: N} | Sur les modèles Claude 4.6+ : thinking: {type: "adaptive"}. budget_tokens est déprécié sur Opus 4.6 / Sonnet 4.6 et rejeté avec un 400 sur Fable 5/5.1 / Sonnet 5.5 / Sonnet 5 / Opus 5.5 / 5 / 4.8 / 4.7. Les modèles antérieurs à 4.6 utilisent encore budget_tokens. |
| Type d'outil de recherche web / web fetch | web_search_20250305, web_fetch_20250910 | web_search_20260209, web_fetch_20260209 (filtrage dynamique) sur Opus 5.5/5/4.8/4.7/4.6, Sonnet 5.5, Sonnet 5 et Sonnet 4.6. Les modèles plus anciens conservent les variantes de base ; sur Vertex AI, seule la variante de base web_search_20250305 est disponible (web fetch n'est pas sur Vertex) — voir la QR des outils serveur ci-dessous. |
| Noms de paramètres PHP | Noms d'arguments snake_case (max_tokens) | Les arguments nommés de premier niveau sont en camelCase (maxTokens). Les clés de tableau imbriquées varient selon la fonctionnalité (par exemple 'taskBudget', 'skillID', 'mcp_server_name') — copiez la clé exacte de l'exemple documenté ; ne faites pas de conversion en masse. |
| Identifiants Managed Agents | Conserver les secrets côté hôte via des outils personnalisés (la seule option avant le déploiement des vaults) | Identifiants environment_variable du Vault — stockés par Anthropic, substitués à la sortie, jamais visibles dans le sandbox (shared/managed-agents-tools.md -> Vaults). Les outils personnalisés côté hôte restent la solution de repli pour les sandbox auto-hébergés. |
| API Files / Skills | client.beta.files.* / client.beta.skills.* avec en-tête beta files-api-2025-04-14 / skills-2025-10-02 | Hors beta : client.files.* / client.skills.*, pas d'en-tête beta. Dans les SDK actuels, client.beta.files / client.beta.skills ont des changements de forme cassants par rapport aux versions précédentes, correspondant aux espaces de noms stables — migrez selon shared/live-sources.md -> Files API / Skills Guide. |
Les fichiers {lang}/ de ce skill font autorité sur les motifs mémorisés.
Sous-commandes
Si la demande utilisateur en bas de ce prompt est une chaîne de sous-commande nue (pas de prose), recherchez chaque table Sous-commandes de ce document — y compris celles des sections ajoutées ci-dessous — et suivez directement l'Action correspondante. Cela permet aux utilisateurs d'invoquer des flux spécifiques via /claude-api <sous-commande>. Si aucune table du document ne correspond, traitez la demande comme une prose normale.
| Sous-commande | Action |
|---|---|
migrate | Migrer le code d'API Claude existant vers un modèle plus récent. Lisez immédiatement shared/model-migration.md et suivez-le dans l'ordre : Étape 0 (confirmer le périmètre — demandez quels fichiers/répertoires avant toute modification), Étape 1 (classer chaque fichier), puis la section des changements cassants par cible. Ne résumez pas le guide — exécutez-le. Si l'utilisateur n'a pas nommé de modèle cible, demandez vers quel modèle migrer dans le même tour que la question de périmètre. Après l'application des changements par cible, auditez le texte du prompt, les descriptions d'outils et le code de requête dans le périmètre par rapport à shared/prompt-audit.md — le prompting écrit pour le modèle source fait partie de chaque migration, et il ne s'annonce pas. |
prompt-audit | Auditer les prompts, descriptions d'outils, skills et fichiers de configuration d'agent existants (CLAUDE.md, fichiers de règles, commandes, sous-agents) pour des motifs obsolètes : texte écrit pour des modèles plus anciens, et instructions que le dépôt a dépassées ou qui se contredisent. Lisez immédiatement shared/prompt-audit.md et suivez-le dans l'ordre : Étape 0 (établir le périmètre et le modèle cible à partir de la demande et du dépôt — indiquez les hypothèses dans le rapport, ne vous arrêtez pas pour demander), inventaire, provenance, puis le scan des motifs. Produisez les deux livrables en entier — le rapport d'audit (résultats avec fichier:ligne, motif, pourquoi il est obsolète, confiance) et un diff proposé — sans vous arrêter pour confirmation ; n'appliquez les modifications que si la demande le demandait explicitement. Ne résumez pas le guide — exécutez-le. |
upgrade | Mettre à niveau la dépendance SDK Anthropic du projet sur une version majeure — actuellement le SDK Python, anthropic 0.x -> 1.x. Les mots suivants peuvent nommer le langage et/ou un périmètre (upgrade python, upgrade python sdk src/). Lisez immédiatement python/claude-api/sdk-upgrade.md et suivez-le dans l'ordre : Étape 0 (confirmer le périmètre, puis établir les versions actuelle et cible — une version 1.x publiée doit exister avant d'écrire un pin), l'inventaire de l'Étape 1, chaque section numérotée, puis la vérification et le rapport. Ne résumez pas le guide — exécutez-le. Si le langage détecté ou nommé n'a pas de sdk-upgrade.md dans ce skill, dites qu'aucun guide de mise à niveau majeure n'est fourni pour ce SDK et redirigez l'utilisateur vers le CHANGELOG de ce SDK (dépôts dans shared/live-sources.md) ; n'en improvisez pas un à partir du guide Python. Il ne s'agit pas d'une migration de modèle — pour déplacer du code vers un modèle Claude plus récent, utilisez migrate. |
cost-optimize | Réduire le coût d'exécution du code d'API Claude existant, sans sacrifier la qualité de la sortie. Lisez immédiatement shared/cost-optimization.md et suivez-le dans l'ordre : Étape 0 (établir le périmètre, la barre de qualité et la base de référence), le profil de tokens — mesuré via l'API Usage and Cost Admin lorsque l'utilisateur dispose d'une clé API Admin, à partir des logs response.usage de l'application lorsqu'il les a (demandez), ou estimé à partir du code sinon — puis une shortlist classée par économies (citée en dollars, % de la facture, ou catégories relatives selon la source de données dont vous disposez), des gains faciles (mise en cache, hygiène des tokens d'entrée, hygiène des boucles, hygiène des tokens de sortie, batch) avant les compromis (budgets, effort, choix de modèle, multi-modèle) ; tout levier qui mérite une place devient son propre diff — proposé par défaut, appliqué et mesuré par rapport à l'évaluation couvrant le trafic qu'il touche lorsque l'utilisateur le demande et l'approuve — et « aucune modification recommandée » est un résultat valide. Deux règles permanentes : chaque exécution qui sollicite le modèle coûte de l'argent réel, donc obtenez d'abord l'approbation de l'utilisateur ; et lorsque le contexte d'un levier manque, travaillez en interaction avec l'utilisateur — ce workflow n'est pas censé réaliser l'audit en un seul passage. Ne résumez pas le guide — exécutez-le ; présenter le profil et le plan classé à l'utilisateur fait partie de l'exécution. |
build-eval | Aider l'utilisateur à construire un ensemble d'évaluation pour son application alimentée par Claude. Lisez immédiatement shared/evals/build-eval.md et exécutez son interview : Étape 0 (ce qui est évalué), Étape 1 (source des prompts — évaluation existante / transcriptions / synthétisées), Étape 2 (méthode de notation), Étape 3 (script exécutable + coût mesuré). Obtenez l'approbation explicite de l'utilisateur sur les entrées, la méthode de notation et le coût avant de produire l'évaluation. |
preserved-thinking-migration | Rendre une intégration existante compatible avec la pensée préservée — la vérification qui maintient un bloc de pensée valide uniquement dans la conversation qui l'a produit. Lisez immédiatement shared/preserved-thinking-migration.md et suivez-le dans l'ordre : Étape 0 (périmètre, classes de trafic, plateforme et modèle, statut d'application, barre de qualité, base de référence), Étape 0.5 (prouver que la vérification s'exécute avec l'auto-test de trois requêtes), Étape 1 (capturer les corps de requête, différencier les paires consécutives avec shared/preserved-thinking-migration/prefix_diff.py, scanner le code pour les causes, nommer chaque modification et si elle est délibérée), Étape 2 (rejouer une tranche de test avec prefix_mismatch_behavior: "drop_block" sous l'en-tête thinking-binding-controls-2026-08-01, compter les nouveaux blocs supprimés par conversation, lire l'en-tête de diagnostic lorsqu'il est présent), Étape 3 (une cause par diff dans l'ordre de raisonnement perdu — proposé par défaut, appliqué lorsque l'utilisateur le demande — puis re-mesurer, conserver ou revenir en arrière ; le protocole à trois bras lorsqu'une évaluation existe), la section sur le changement de modèle (dans shared/preserved-thinking-migration/causes.md, avec la table des causes et la liste de conservation) lorsque le harnais route entre les modèles, Étape 4 (le profil de rupture et les changements). Deux règles permanentes : chaque rejeu coûte de l'argent réel, donc obtenez d'abord l'approbation de l'utilisateur pour le budget de mesure ; et « aucune modification recommandée » — la tranche a rejoué la pensée et rien n'a été supprimé — est un résultat valide. Les causes qui n'ont qu'une forme d'ajout uniquement sous une beta plus récente (compaction de queue et d'arrière-plan : compact-2026-09-04 ; changements d'outils de même nom : inline-tools-2026-09-15) sont, lorsque cette beta n'est pas disponible, mesurées et décidées, pas réécrites. Pour le pourquoi (la vérification en trois étapes, la table des modifications en ajout uniquement), cela se rattache à shared/model-migration.md -> Breaking change 3 ; ne résumez pas le guide — exécutez-le. |
hillclimb | Améliorer itérativement l'application de l'utilisateur par rapport à une évaluation existante. Lisez immédiatement shared/evals/eval-hillclimb.md et suivez-le : Étape 0 (confirmer qu'une évaluation exécutable existe — sinon, rediriger vers build-eval), Étape 1 (quoi changer / ce qui est interdit), Étape 2 (budget + condition d'arrêt à partir du coût mesuré par exécution), obtenez l'approbation du plan, puis la boucle lire->proposer->appliquer->exécuter->enregistrer avec un état sur disque et une séparation train/validation/test. |
Détection du langage
Avant de lire les exemples de code, déterminez le langage dans lequel l'utilisateur travaille (exception : pour la sous-commande prompt-audit, sautez les étapes de demande de cette section — l'audit est non interactif et son inventaire est indépendant du langage ; lorsqu'aucun langage n'est déductible, procédez sans demander et indiquez l'hypothèse dans le rapport) :
- Examinez les fichiers du projet pour déduire le langage :
*.py,requirements.txt,pyproject.toml,setup.py,Pipfile-> Python — lisez depuispython/*.ts,*.tsx,package.json,tsconfig.json-> TypeScript — lisez depuistypescript/(anciennementnode-ts/)*.js,*.jsx,package.json-> JavaScript (Node) — lisez depuisjavascript/(anciennementnode-ts/)*.java,pom.xml,build.gradle,settings.gradle-> Java — lisez depuisjava/*.go,go.mod-> Go — lisez depuisgo/*.rb,Gemfile-> Ruby — lisez depuisruby/*.php,composer.json-> PHP — lisez depuisphp/*.cs,*.csproj,*.sln-> C# (.NET) — lisez depuiscsharp/*.pyavec!pip installouimport anthropic[oufrom anthropic-> Python — lisez depuispython/requirements.txtavecanthropic-> Python — lisez depuispython/package.jsonavec@anthropic-ai/sdk-> TypeScript — lisez depuistypescript/pom.xmlaveccom.anthropic-> Java — lisez depuisjava/go.modavecgithub.com/anthropics/anthropic-sdk-go-> Go — lisez depuisgo/Gemfileavecanthropic-> Ruby — lisez depuisruby/composer.jsonavecanthropic-> PHP — lisez depuisphp/*.csprojavecAnthropic-> C# (.NET) — lisez depuiscsharp/- Aucun fichier de projet trouvé, ou le seul fichier est
*.md,*.txt,*.json,*.yaml,*.yml,Dockerfile,Makefile,justfile,*.sh,*.bat,*.ps1,*.tf,Dockerfile.*-> demandez le langage à l'utilisateur (sauf pourprompt-audit). - Aucun fichier du tout, ou répertoire totalement vide -> demandez le langage.