Et comme annoncé, si une marketplace de skills sort aussi, je me disais que ça pourrait être plutôt pas mal de ne récupérer que les skills nécessaires et de les activer quand on en a besoin.
Je me demande si cela pourrait aussi s’appliquer quand on utilise Claude Code pour le développement.
Actuellement aussi, j’ai mis des consignes dans Claude.md, puis je poursuis en séparant les directives détaillées dans chaque partie.
Pour réaliser beaucoup de tâches avec peu de tokens, j’ai l’impression qu’on peut régler ça assez simplement en misant sur des agents multiples et des résumés plutôt que sur l’optimisation des prompts. Je suis d’accord sur le problème, mais la solution proposée me semble avoir ses limites.
Quel lien peut-il y avoir entre la gestion du contexte et les Claude Skills ? Je me suis d’abord demandé en quoi c’était différent des commandes personnalisées de Claude Code qui existaient déjà, mais en lisant la documentation, j’ai eu l’impression que la plus grande différence est surtout qu’on peut inclure et exécuter du code de script comme du Python ou du JavaScript à l’intérieur d’une même skill.
Il semble que, dans le contexte, ce ne soit pas tout le SKILLS.md qui soit inclus, mais seulement la partie en haut avec le nom et la description ci-dessous qui soit toujours ajoutée d’abord.
name: skill-creator
description: Guide pour créer des skills efficaces. Cette skill doit être utilisée lorsque les utilisateurs veulent créer une nouvelle skill (ou mettre à jour une skill existante) qui étend les capacités de Claude grâce à des connaissances spécialisées, des workflows ou des intégrations d’outils.
license: Conditions complètes dans LICENSE.txt
On dirait qu’ils défendent une philosophie du logiciel libre à un niveau excessif, alors qu’on utilise soit l’Internet via les câbles en cuivre installés par les opérateurs, soit une soi-disant alternative via une parabole satellitaire.
Même si tout ce qui est écrit ici se réalisait, j’ai l’impression qu’ils diraient quand même que l’open source n’a pas gagné.
Il est vrai que Livewire est amusant, mais dès que l’UI devient un peu plus complexe, ça tourne à l’enfer. À partir de ce moment-là, Phoenix perd brutalement ses avantages. Comme cela devient de plus en plus difficile à mesure que le cycle s’allonge, je ne peux pas vraiment le recommander.
Les Skills n’utilisent-ils pas aussi des tokens ? Si c’est le cas, j’ai l’impression que le problème de consommation de tokens risque de se reposer, et je ne vois pas très bien comment on y répondra à ce moment-là.
Moi aussi, à une époque, j’étais presque un adepte inconditionnel du serverless et j’appliquais des architectures serverless à tout-va, mais ces temps-ci je préfère davantage une structure construite avec une seule instance EC2 et une seule base RDS. Et ensuite, j’en détache progressivement les éléments nécessaires un par un. L’adoption du serverless est devenue quelque chose que j’examine mûrement avant de la faire.
Il y a plusieurs raisons à cela, mais j’ai constaté que s’il y a ne serait-ce qu’une seule personne dans l’équipe qui n’a pas de connaissances en serverless, les coûts de communication et de maintenance augmentent considérablement. Et en remettant des serveurs en service, j’ai de nouveau réalisé que le serverless n’était ni aussi économique ni aussi pratique que je l’avais imaginé.
Quand on travaille avec Claude Code, on finit par lui injecter en permanence des consignes ou des règles dans le contexte, et au final on se retrouve à devoir arbitrer entre la consommation de tokens et la taille du contexte. Du coup, j’ai pensé à créer un dossier, à y écrire les détails de façon très précise dans des fichiers .md par fonctionnalité, puis à ne mettre dans claude.md qu’une foule de pointeurs du genre « pour faire ceci, voir cela » ; et ça a plutôt bien marché pour un coût assez faible. Comme les Skills reviennent au fond à regrouper ce genre de choses, ça a l’air d’être assez utile.
J’aime le fait que l’interface SQL ait été unifiée.
Comme c’était une entreprise appelée void(0), il lui fallait sans doute un business model.
Et comme annoncé, si une marketplace de skills sort aussi, je me disais que ça pourrait être plutôt pas mal de ne récupérer que les skills nécessaires et de les activer quand on en a besoin.
On dirait qu’on en arrive maintenant à l’étape de la commercialisation de la popularité de vite...
Il doit y avoir une raison pour laquelle Vite ne l’a pas intégré, mais je serais curieux d’avoir des retours d’expérience sur Bun en usage réel.
Je me demande si cela pourrait aussi s’appliquer quand on utilise Claude Code pour le développement.
Actuellement aussi, j’ai mis des consignes dans
Claude.md, puis je poursuis en séparant les directives détaillées dans chaque partie.Oh, merci pour cette explication essentielle.
En réalité... même si on comprend ça, il y a beaucoup de choses qui vont au-delà...
Pour réaliser beaucoup de tâches avec peu de tokens, j’ai l’impression qu’on peut régler ça assez simplement en misant sur des agents multiples et des résumés plutôt que sur l’optimisation des prompts. Je suis d’accord sur le problème, mais la solution proposée me semble avoir ses limites.
Les Claude Skills sont formidables, cela pourrait être une innovation encore plus importante que MCP
Quel lien peut-il y avoir entre la gestion du contexte et les Claude Skills ? Je me suis d’abord demandé en quoi c’était différent des commandes personnalisées de Claude Code qui existaient déjà, mais en lisant la documentation, j’ai eu l’impression que la plus grande différence est surtout qu’on peut inclure et exécuter du code de script comme du Python ou du JavaScript à l’intérieur d’une même skill.
Il semble que, dans le contexte, ce ne soit pas tout le
SKILLS.mdqui soit inclus, mais seulement la partie en haut avec le nom et la description ci-dessous qui soit toujours ajoutée d’abord.name: skill-creator
description: Guide pour créer des skills efficaces. Cette skill doit être utilisée lorsque les utilisateurs veulent créer une nouvelle skill (ou mettre à jour une skill existante) qui étend les capacités de Claude grâce à des connaissances spécialisées, des workflows ou des intégrations d’outils.
license: Conditions complètes dans LICENSE.txt
On dirait quand même qu’au final, ils ont fait quelque chose de bien.
On dirait qu’ils défendent une philosophie du logiciel libre à un niveau excessif, alors qu’on utilise soit l’Internet via les câbles en cuivre installés par les opérateurs, soit une soi-disant alternative via une parabole satellitaire.
Même si tout ce qui est écrit ici se réalisait, j’ai l’impression qu’ils diraient quand même que l’open source n’a pas gagné.
Il est vrai que Livewire est amusant, mais dès que l’UI devient un peu plus complexe, ça tourne à l’enfer. À partir de ce moment-là, Phoenix perd brutalement ses avantages. Comme cela devient de plus en plus difficile à mesure que le cycle s’allonge, je ne peux pas vraiment le recommander.
Les Skills n’utilisent-ils pas aussi des tokens ? Si c’est le cas, j’ai l’impression que le problème de consommation de tokens risque de se reposer, et je ne vois pas très bien comment on y répondra à ce moment-là.
C’est vraiment exagéré
Moi aussi, à une époque, j’étais presque un adepte inconditionnel du serverless et j’appliquais des architectures serverless à tout-va, mais ces temps-ci je préfère davantage une structure construite avec une seule instance EC2 et une seule base RDS. Et ensuite, j’en détache progressivement les éléments nécessaires un par un. L’adoption du serverless est devenue quelque chose que j’examine mûrement avant de la faire.
Il y a plusieurs raisons à cela, mais j’ai constaté que s’il y a ne serait-ce qu’une seule personne dans l’équipe qui n’a pas de connaissances en serverless, les coûts de communication et de maintenance augmentent considérablement. Et en remettant des serveurs en service, j’ai de nouveau réalisé que le serverless n’était ni aussi économique ni aussi pratique que je l’avais imaginé.
Quand on travaille avec Claude Code, on finit par lui injecter en permanence des consignes ou des règles dans le contexte, et au final on se retrouve à devoir arbitrer entre la consommation de tokens et la taille du contexte. Du coup, j’ai pensé à créer un dossier, à y écrire les détails de façon très précise dans des fichiers
.mdpar fonctionnalité, puis à ne mettre dansclaude.mdqu’une foule de pointeurs du genre « pour faire ceci, voir cela » ; et ça a plutôt bien marché pour un coût assez faible. Comme les Skills reviennent au fond à regrouper ce genre de choses, ça a l’air d’être assez utile.MSA, OneDrive, Copilot, etc. J’aimerais qu’ils arrêtent de forcer ce genre de choses dans la gorge des utilisateurs.