Comment utiliser Claude comme responsable technique : le guide du Skill Dante

Updated
Skill · .md

Le Skill derrière ce guide : Dante - Skill IA pour responsables techniques. Il contient votre stack, l'expérience réelle d'exploitation de votre équipe et vos décisions en cours, afin que les conseils soient filtrés par ce que votre équipe peut exploiter plutôt que par ce qui est techniquement optimal - 29 $, un seul paiement, à vous définitivement.

Voir le Skill Dante →

Deux questions suffisent à trancher la plupart des décisions techniques, et un modèle ne propose spontanément ni l'une ni l'autre : combien coûte le fait de revenir en arrière, et cette équipe peut-elle l'exploiter à trois heures du matin ? Demandez à un modèle quelle base de données, quel framework ou quelle architecture choisir, et il en sélectionnera un et le défendra très bien - avec exactement le même degré de confiance, que la mauvaise réponse vous coûte une semaine ou trois ans, et sans savoir qui est d'astreinte. La moitié non technique du travail de responsable technique consiste essentiellement en ces deux questions. Ce guide sert à les imposer dans la conversation.

0:15 · loop Same AI, same question. One file makes it a specialist.

Question un : pouvez-vous franchir cette porte dans l'autre sens ?

La lettre aux actionnaires d'Amazon de 2015 le formule aussi clairement que possible. Certaines décisions sont « lourdes de conséquences et irréversibles, ou presque irréversibles - des portes à sens unique - et ces décisions doivent être prises de manière méthodique, soigneusement, lentement, avec mûre réflexion et concertation. » La plupart ne le sont pas : « elles sont modifiables, réversibles - ce sont des portes à double sens », et ces décisions « peuvent et doivent être prises rapidement par des personnes ou de petits groupes faisant preuve d'un grand discernement. »

La raison pour laquelle c'est plus important avec un modèle que sans modèle, c'est qu'un modèle aplatit la distinction. Demandez-lui le format de vos journaux et votre modèle de données au cours de la même session, et vous obtiendrez deux réponses tout aussi détaillées et tout aussi sûres d'elles. L'une de ces décisions peut être modifiée un mardi après-midi. L'autre vous suivra encore lorsque les personnes qui l'ont prise seront parties.

La première étape n'est donc pas « quelle option ». Il faut classer la décision : combien coûte réellement le fait de revenir en arrière, dans quelle unité, et qu'est-ce qui la rend coûteuse ? Un modèle est doué pour répondre à cette question quand on la lui pose, mais ne la soulèvera jamais de lui-même.

Il y a une troisième réponse que le modèle ne proposera pas non plus : ce choix n'a pas encore besoin d'être tranché. Reporter une décision irréversible jusqu'à ce que vous en sachiez davantage est souvent la chose la plus avisée qu'un responsable puisse faire, et cela ressemble à de l'indécision pour tous ceux qui ne prêtent pas attention.

Question deux : cette équipe peut-elle l'exploiter à 3 heures du matin ?

Un modèle sait ce qui est techniquement bon. Il a lu les blogs sur l'architecture, et ces blogs sont écrits par des personnes travaillant dans des entreprises qui disposent d'une équipe plateforme.

Ce qu'il ne sait pas, c'est qui est d'astreinte, ce qu'ils ont déjà exploité, pour quelles alertes ils seront appelés et combien d'entre eux seront encore là dans dix-huit mois. Ce sont les faits qui tranchent réellement la question, et ce sont ceux qui ne figurent jamais dans le prompt. Le résultat est une recommandation véritablement correcte dans l'abstrait, mais erronée pour quatre ingénieurs qui n'ont jamais exploité de courtier de messages.

La question de l’exploitabilité n’est pas « est-ce une bonne solution ? », mais « que nous coûtera-t-elle lors de la pire nuit de l’année ? ». Qui reçoit l’alerte. Ce qu’il doit savoir. Ce que dit le runbook. Ce qui se passe lorsque l’unique personne qui maîtrise le sujet est en vacances. Intégrez ces éléments au prompt en tant que contraintes, et la liste restreinte change, souvent de manière spectaculaire.

prompt 1 - classez la décision avant de la prendre

Ne recommandez pas encore d’option. Voici une décision technique que je dois prendre : [DESCRIBE] Commencez par la classer : - Est-elle réversible, difficile à inverser ou effectivement permanente ? - Que faudrait-il précisément faire pour revenir en arrière dans 12 mois, et quel est le coût en semaines-ingénieur et en risques ? - Qu’est-ce qui rend difficile et coûteux le retour en arrière : données, contrats, API publique, recrutement, autre chose ? - Doit-elle être prise maintenant ? Sinon, que saurions-nous - Devons-nous la prendre maintenant, ou que saurions-nous - Qui est la bonne personne pour prendre cette décision : moi seul, moi et une l’autre, ou toute l’équipe avec une proposition écrite ? Dites-moi ensuite franchement : s’agit-il d’une porte à sens unique ou à double sens, et est-ce que j’y consacre le niveau de processus approprié ? Si je si je réfléchis trop longtemps à une décision réversible, dites-le.

prompt 2 - le filtre d’exploitabilité

Donnez-lui les informations sur l’équipe, pas seulement sur le problème. Les faits ci-dessous sont ceux qui changent la réponse.

Évalue ces options par rapport à MON équipe, et non aux meilleures pratique. DÉCISION : [DESCRIBE] OPTIONS : [LIST] MON ÉQUIPE : - [N] ingénieurs. Répartition des niveaux d’expérience : [DESCRIBE HONESTLY] - Ce que nous avons effectivement exploité en production auparavant : [LIST] - Ce que nous n’avons jamais exploité : [LIST] - Astreinte : [QUI, À QUELLE FRÉQUENCE ET SI ELLE EST RÉMUNÉRÉE] - Rotation attendue : qui pourrait partir, et quelles connaissances sont détenues uniquement par ces personnes - Notre processus réel de déploiement et de retour en arrière aujourd’hui Pour chaque option, répondez à ces questions : 1. Qui reçoit l’alerte quand cela tombe en panne, et que doit-il savoir comment le corriger à 3 heures du matin ? 2. Quel est le mode de défaillance que personne ne remarque pendant une semaine ? 3. Que doit contenir le runbook, et qui l’écrit ? 4. Que se passe-t-il si la personne qui a défendu cette option part ? 5. Quel est le coût opérationnel en heures par mois, et non en dollars ? Classe ensuite les options selon ce que CETTE équipe peut réellement exploiter, et dis explicitement en quoi ce classement diffère de la meilleure option sur le plan technique réponse. Je veux voir les deux.
À la une : Skill
Dante - Skill AI de Tech Lead
Dante - Skill AI de Tech Lead
29 $ · paiement unique

Conserve les faits sur l’équipe d’une session à l’autre, ce qui fait toute la différence ici. Retaper votre stack, votre rotation d’astreinte et ce que votre équipe n’a jamais exploité dans une nouvelle conversation à chaque fois explique pourquoi la plupart des gens abandonnent et se contentent de la réponse générique. Il classe aussi les décisions selon leur réversibilité avant de recommander quoi que ce soit, et conserve les décisions en cours pour éviter qu’il se contredise avec la décision de la semaine dernière.

Voir Dante - Skill AI pour responsable technique →

Revues : le problème de la liste plate

Demandez à un modèle de réviser un diff et vous obtenez une liste. Une préférence de nommage, un test manquant et une condition de concurrence, tous présentés avec la même importance, sur le même ton mesuré, avec le même degré de confiance. C'est ce qui rend les retours de revue générés par l'AI épuisants à recevoir et inutiles pour l'enseignement : l'auteur ne peut pas discerner ce qui compte, alors soit il corrige tout mécaniquement, soit il survole la revue.

Deux corrections. Premièrement, imposez une séparation des niveaux de gravité avec un budget : au plus trois éléments must-fix, tout le reste étant explicitement optionnel. Un budget l'oblige à choisir, et ce qu'il choisit est révélateur.

Deuxièmement, et c'est plus important pour un responsable : il ne connaît pas vos conventions, donc il va les inventer. Il dira à un junior qu'un code parfaitement raisonnable enfreint une norme qui n'est pas la vôtre, en la présentant comme universelle. C'est pire que l'absence de revue, parce que le junior croit que vous l'avez cautionnée. Donnez-lui vos conventions et interdisez-lui d'affirmer une règle que vous ne lui avez pas fournie.

Prompt 3 - une revue qui enseigne

Révise ce diff en rédigeant des retours que je transmettrai à l'auteur. NOS CONVENTIONS : [COLLEZ-LES OU AJOUTEZ UN LIEN VERS LE GUIDE DE STYLE] CONTEXTE : [À QUOI SERT CETTE MODIFICATION ET QUEL EST LE NIVEAU DE L'AUTEUR] Règles : - Au maximum 3 éléments MUST FIX. Si tu as davantage de candidats, choisis et dis-moi ce que tu as supprimé. - Tout le reste va sous OPTIONAL et est marqué comme ma préférence plutôt qu'une règle. - Pour chaque MUST FIX : l'échec précis qu'il évite, avec le entrée ou la séquence qui le déclenche. « Cela pourrait provoquer « problèmes » n'est pas un commentaire de revue. - Ne pas affirmer de règle qui ne figure pas dans les conventions que je a donné. Si vous pensez que quelque chose ne va pas, mais qu'il ne s'agit que d'une convention ailleurs, dis-le avec ces mots. - Nommer une chose que l'auteur a bien faite, uniquement si c'est vrai et précis. - Aucun commentaire sur la mise en forme. Un linter s'en charge. Puis, séparément de la revue : dis-moi ce que fait ce diff suggère que l'auteur n'a pas encore compris, donc je sais quoi enseigner plutôt que ce qu'il faut corriger.

Présenter un dossier à la hiérarchie

Les responsables techniques passent une quantité surprenante de temps à demander du temps. Refactoriser ce composant, résorber la dette, consacrer un sprint au pipeline de déploiement. Demandez à un modèle de rédiger cet argumentaire métier et il en produira volontiers un contenant des chiffres - un pourcentage d'incidents évités, un nombre d'heures d'ingénierie, un gain de vélocité. Vous ne lui avez pas fourni ces chiffres. Il les a inventés, et vous êtes sur le point d'y apposer votre nom devant un directeur.

La même règle s'applique ici : aucun chiffre que le modèle n'a pas reçu. Mais il y a ici une meilleure façon de l'utiliser que de rédiger tout l'argumentaire.

Demandez-lui d'argumenter contre vous. Faites-lui rédiger la raison la plus solide pour laquelle un directeur raisonnable devrait dire non. Cette réponse est réellement utile, car elle vous indique ce à quoi vous devez effectivement répondre, et les modèles sont bons dans cet exercice lorsqu'on les oriente vers lui, mais mauvais pour remarquer qu'il faut le faire.

Prompt 4 - défendre le refus

Je veux demander [DU TEMPS / DES EFFECTIFS / UN SPRINT] pour faire [LE TRAVAIL]. Voici mon argument : [COLLER] N'améliorez pas mon argument. Argumentez contre lui. Rédigez la version la plus solide du refus qu'un un [DIRECTEUR / VP / FONDATEUR] bien intentionné donnerait, étant donné qu'ils sont également responsables de [LA PRIORITÉ CONCURRENTIELLE]. Utilisez leur vocabulaire, pas le mien. Ensuite : - nommez le maillon le plus faible de mon argument et expliquez pourquoi il est le plus faible - nommez la chose que je suppose qu'ils acceptent déjà, mais qu' ils pourraient ne pas - dites-moi quelles preuves les feraient réellement changer d'avis et si Je l'ai actuellement - signalez chaque chiffre dans mon cas et son origine. ne me donnez pas de chiffre, n'en fournissez pas - indiquez [NOMBRE REQUIS : lequel] à la place. Si mon cas est réellement faible, dites-le. Je préfère le découvrir ici.

Débloquer sans devenir un routeur

Un ingénieur est bloqué. La voie rapide consiste à coller son problème dans un chat, à obtenir la réponse et à la lui transmettre. Cela fonctionne, cela prend quatre-vingt-dix secondes et, insidieusement, cela aggrave les choses : l'ingénieur n'apprend rien, il reviendra vous voir plus tôt la prochaine fois et vous vous êtes transformé en API lente devant une API rapide.

La version qui passe à l'échelle consiste à demander au modèle les questions plutôt que la réponse. Il est vraiment bon pour générer le parcours de diagnostic si vous lui interdisez de le suivre.

Prompt 5 - des questions, pas des réponses

Un ingénieur de mon équipe est bloqué sur ceci : [DÉCRIVEZ LE PROBLÈME ET CE QU'ILS ONT ESSAYÉ] Ne résolvez pas le problème. Ne donnez pas d'indice sur la solution. Ne dites pas ce que vous pensez que la cause est. Donnez-moi les trois questions que je devrais leur poser, dans l'ordre où je devrait leur poser et qui les conduirait le plus probablement à le trouver eux-mêmes. Pour chaque question, dites ce qu'un oui et un non écarter chaque règle. Alors dites-moi : que faudrait-il que cet ingénieur sache déjà pour question une pour être utile ? S'ils ne le savent pas, cette lacune est la vraie chose à enseigner, et la session de débogage est la mauvaise intervention.

Prompt 6 - le compte rendu de décision que personne n'écrit

Le document qui ne coûte rien à un responsable technique et fait gagner six mois au suivant. Faites-le à la fin de la conversation, tant que les options rejetées y figurent encore.

Transformez notre conversation en fiche de décision. Courte. Écrite pour quelqu’un qui rejoindra l’équipe dans un an et demandera pourquoi cela fonctionne de cette manière. Sections : - La décision, en une phrase - La date et la personne qui a décidé - Si cette décision ouvrait une porte à sens unique ou à double sens, et le coût pour revenir en arrière - Les options que nous avons rejetées, et la véritable raison pour laquelle chacune a été rejetées - pas « c’était moins bien » - Les contraintes qui ont déterminé la décision, notamment l’équipe et opérationnelles - Ce à quoi nous avons sciemment renoncé - Ce qui nous ferait réexaminer cette décision : un déclencheur précis, pas « si les choses changent » Utilisez uniquement ce qui a été dit dans cette conversation. Lorsque j’ai affirmé quelque chose sans preuve, formulez-le comme une supposition plutôt plutôt qu’un fait. Marquez tout ce dont vous n’êtes pas sûr que je l’ai réellement dit.

Tranchez une fois pour toutes la question du partage de code, avant le workflow plutôt qu’à l’intérieur de celui-ci

Un responsable technique est généralement la personne qui définit, ou du moins montre par l’exemple, ce que l’équipe colle dans une fenêtre de chat. Le code source, les données clients, les identifiants et l’architecture interne sont régis par votre contrat de travail, la politique de votre entreprise et souvent un contrat client, et la réponse dépend du niveau et du compte que vous utilisez, pas de ce qui est pratique sur le moment.

Décidez-le délibérément, par écrit, avant que cela ne devienne une habitude. Les pratiques qui restent valables quoi qu’il arrive : raisonner sur la structure d’un problème plutôt que de coller le fichier, masquer les identifiants et les secrets avant toute transmission, exclure entièrement les données clients, et se rappeler qu’un extrait assez petit, associé à votre dépôt public, peut identifier la base de code aussi sûrement qu’un commentaire d’en-tête. Si votre entreprise a une politique, elle prime sur cette page. Si elle n’en a pas, vous êtes probablement la personne qui devrait la rédiger.

Là où ça échoue

Échec Ce qui se passe Que faire
Enjeux nivelés Une décision réversible et une décision définitive reçoivent la même réponse assurée et exhaustive Trier d’abord selon la réversibilité. Ne jamais demander « quelle option » avant de demander « quel est le coût de revenir en arrière »
L’architecture d’un article de blog Recommander ce que ferait une entreprise dotée d’une équipe plateforme, parce que c’est elle qui rédige les sources Présenter comme contraintes dans le prompt l’astreinte, le risque de turnover et ce que vous n’avez jamais exploité
Chiffres commerciaux inventés Pourcentages et économies d’heures sortis de nulle part dans votre argumentaire sur la dette technique Interdire tout chiffre que vous n’avez pas fourni. L’utiliser pour défendre votre position, pas pour l’étayer
Conventions inventées Dit à un junior que son code enfreint une règle qui n’est pas la vôtre, sur un ton qui semble être le vôtre Fournissez vos conventions et interdisez-lui d'affirmer l'existence d'une norme que vous ne lui avez pas donnée
Des listes de révision sans hiérarchie Une remarque sur le nom et une condition de course avec le même poids et le même niveau de confiance Un budget de gravité. Trois corrections indispensables au maximum, et elle doit choisir
Elle ne dira pas d'attendre Lorsqu'on lui demande de décider, elle décide. Elle ne signalera pas spontanément que la décision est prématurée Demandez explicitement s'il faut prendre cette décision maintenant et ce que l'attente permettrait de gagner
Acquiescement Demandez-lui si votre plan est solide et on vous répondra que oui Demandez-lui l'argument le plus solide contre cette proposition, avec la voix de la personne qui doit l'approuver
Aucune des bases de la confiance Elle n'était pas présente lors de l'incident, ne sait pas que cet ingénieur est épuisé et n'a aucune autorité au sein de l'équipe Cette moitié du travail ne se délègue pas. Elle concerne le raisonnement et la rédaction

Comment installer la Skill Dante ?

Le téléchargement est un fichier ZIP contenant SKILL.md à la racine de l'archive, et non dans un dossier imbriqué - cette structure de dossiers est la raison la plus courante d'un échec du téléversement. Dans l'application de bureau Claude, ouvrez Personnaliser → Skills, téléversez le ZIP et activez-le.

L'exécution de code doit être activée pour les Skills, dans Paramètres → Capacités. Le centre d'aide d'Anthropic répertorie actuellement les Skills sur les offres Free, Pro, Max, Team et Enterprise, tandis que son tutoriel Academy mentionne les offres Pro, Max, Team et Enterprise - si vous utilisez l'offre gratuite, vérifiez donc Paramètres → Capacités pour votre propre compte plutôt que de vous fier aux informations de l'une ou l'autre page. Le guide complet se trouve dans le guide d'installation de la Skill.

Dans ChatGPT ou Gemini, il n'y a pas d'étape de téléversement : ouvrez SKILL.md, copiez le contenu et collez-le dans les instructions personnalisées. Vous perdez le déclenchement automatique, mais conservez la méthode.

À qui s'adresse cet outil ?

Les responsables techniques et les ingénieurs principaux qui définissent la direction technique tout en continuant à livrer, ainsi que les responsables débutants qui en ont déjà la responsabilité sans encore en avoir le titre. Cela fonctionne dans Claude, ChatGPT ou n'importe quel chat AI.

Les rôles d'ingénierie sont répartis en Skills distinctes, à 29 $ chacune et disponibles en téléchargement unique :

L’ensemble plus large comprend les skills pour développeurs logiciels et les skills logiciels et IT.

En résumé :

Classez la décision avant de la prendre, car un modèle donne la même réponse assurée à un choix réversible et à un choix définitif, et ne vous dira jamais lequel vous avez entre les mains. Intégrez votre équipe au prompt comme contrainte stricte - qui est d’astreinte, ce qu’elle n’a jamais exploité, qui pourrait partir - et demandez les deux classements : le meilleur sur le plan technique et celui que votre équipe peut réellement faire fonctionner. Limitez vos revues à trois éléments à corriger impérativement et interdisez au modèle d’affirmer des conventions que vous ne lui avez pas données, sinon il enseignera à vos juniors des règles que vous n’avez jamais définies. Utilisez-le pour contester votre propre argumentaire sur la dette technique plutôt que pour le rédiger, et ne le laissez inventer aucun chiffre que vous ne lui avez pas fourni. Rédigez ensuite la fiche de décision tant que les options rejetées sont encore dans la conversation. Pour conserver les informations de l’équipe entre les sessions, Dante - Skill AI de Tech Lead. Fonctionne avec Claude, ChatGPT et tout chat AI, avec une garantie de remboursement de 30 jours.

Skill · .md · Fonctionne avec Claude et ChatGPT

Dante - Skill AI de Tech Lead

Classe les décisions selon le coût de leur annulation avant de recommander quoi que ce soit, filtre les options selon ce que votre équipe a réellement exploité, limite le nombre de commentaires de revue et défend la position opposée à la vôtre quand vous le lui demandez. Aucun abonnement. Il est à vous définitivement.

$19
Obtenez le Skill de Dante →

KissMySkills est une marketplace proposant plus de 1 800 skills AI, plus de 80 packs de prompts, plus de 75 agents et des outils gratuits pour Claude, ChatGPT et tout chat AI.

Guides de Skill associés

Passez à la pratique

Ou tous les skills avec Unlimited Voir les offres →

Foire aux questions

Can Claude help with technical decisions?+

It can reason through options well, but it will not raise the two questions that actually settle most of them. The first is reversibility: ask it about your log format and your data model in the same session and you get two equally confident answers, though one is changeable on a Tuesday and the other outlives everyone who chose it. The second is operability: it does not know who is on call. Ask it to sort the decision by what undoing it costs before you ask it which option, and put your team in the prompt as a hard constraint.

What is a one-way door decision?+

Amazon's 2015 shareholder letter frames it as decisions that are consequential and irreversible or nearly irreversible, which must be made methodically, carefully and slowly with great deliberation and consultation. Most decisions are not like that: they are changeable, two-way doors, and those can and should be made quickly by high-judgement individuals or small groups. The practical value for a tech lead is spotting when a team is applying one-way-door process to a two-way-door decision, which is where most of the slowness comes from.

Why does AI recommend architecture my team cannot run?+

Because it optimises for what is technically good, and the material it learned from was written largely by people at companies with a platform team. It does not know who is on call, what they have operated before, what they will be paged for, or how many of them will still be there in eighteen months. Give it those facts as constraints and ask for two rankings: the technically best answer and the one this team can actually run. Where they differ is the interesting part.

Is AI good at code review?+

It is good at finding candidates and bad at weighting them. The default output is a flat list where a naming preference, a missing test and a race condition all appear at the same size in the same confident tone, which is exhausting to receive and teaches nothing. Two fixes: impose a budget of at most three must-fix items so it has to choose, and supply your conventions while forbidding it from asserting any standard you did not give it. Otherwise it will tell a junior their code breaks a rule that is not your rule.

Will it invent numbers in a tech-debt business case?+

Yes. Ask it to make the case for paying down debt and you get percentages of incidents avoided and engineering hours saved that you never supplied. Forbid any figure you did not give it, with a placeholder instead. The better use is to point it the other way entirely: ask it to write the strongest refusal a competent director would give, in their vocabulary. That tells you what you actually have to answer, and models are good at it when asked and bad at noticing it needs doing.

How do I unblock an engineer without doing the work for them?+

Do not paste their problem in and hand back the answer. It takes ninety seconds and it makes you a slow API in front of a fast one, while the engineer learns nothing and comes to you sooner next time. Ask the model for the three questions to ask, in order, with what a yes and a no would each rule out, and forbid it from hinting at the cause. Then ask what the engineer would need to already know for the first question to land - if they do not know it, the gap is the thing to teach and the debugging session is the wrong intervention.

Is it safe to paste work code into an AI chat?+

That is a policy question rather than a technical one, and as a tech lead you are usually the person who sets it or models it. Source code, customer data, credentials and internal architecture are governed by your employment agreement, your company's policy and often a customer contract, and the answer depends on your tier and account. Settle it in writing before it becomes a habit. Practices that hold regardless: reason about the shape of a problem rather than pasting the file, redact identifiers and secrets, keep customer data out, and remember a small snippet plus your public repo can identify the codebase.

How do I install the Dante skill?+

The download is a ZIP with SKILL.md at the root of the archive rather than inside a nested folder, which is the usual reason an upload fails. In the Claude desktop app open Customize, then Skills, upload the ZIP and toggle it on. Skills need code execution enabled, under Settings then Capabilities. Anthropic's help centre currently lists Skills on Free, Pro, Max, Team and Enterprise, while its Academy tutorial lists Pro, Max, Team and Enterprise, so if you are on the free plan check Settings then Capabilities for your own account rather than trusting either page. In ChatGPT or Gemini there is no upload step, so open SKILL.md, copy the contents and paste them into custom instructions.

~/get-started

Skills qui fonctionnent. Sans fioritures.

Parcourez chaque skill, prompt pack et agent de la boutique.

Parcourir toutes les compétences →Ou essayez les outils gratuits