Zo gebruik je Claude als tech lead: Skill Guide

Bijgewerkt op 14 min lezen KissMySkills
Op deze pagina
  1. Question één: is dit een deur waar je door terug kunt lopen?
  2. Question twee: kan dit team het om 3 uur 's nachts beheren?
  3. Reviews: het probleem van de platte lijst
  4. De zaak naar boven toe bepleiten
  5. Blokkeren zonder een router te worden
  6. Waar het misgaat
  7. Hoe installeer je de Dante Skill?
  8. Voor wie is dit bedoeld?
  9. Gerelateerde Skill-gidsen
Skill · .md

De Skill achter deze gids: Dante - Tech Lead AI Skill. Bevat informatie over je stack, de daadwerkelijke operationele ervaring van je team en je beslissingen die nog in uitvoering zijn, zodat het advies wordt gefilterd op basis van wat je team kan beheren in plaats van wat technisch het beste is - $19, eenmalige betaling, permanent van jou.

Bekijk de Dante Skill →

Twee vragen beslechten de meeste technische beslissingen, en een model werpt geen van beide uit zichzelf op: hoe duur is het om dit terug te draaien, en kan dit team het om drie uur 's nachts beheren? Vraag een model welke database, welk framework of welke architectuur, en het kiest er een en verdedigt die goed - met precies hetzelfde vertrouwen of het verkeerde antwoord je een week of drie jaar kost, en zonder te weten wie er dienst heeft. Het niet-coderende deel van de techleadfunctie bestaat grotendeels uit die twee vragen. Deze gids is bedoeld om ze in het gesprek af te dwingen.

Question één: is dit een deur waar je door terug kunt lopen?

Amazon formuleert het in zijn aandeelhoudersbrief uit 2015 ongeveer zo helder als mogelijk. Sommige beslissingen zijn "ingrijpend en onomkeerbaar of vrijwel onomkeerbaar - eenrichtingsdeuren - en deze beslissingen moeten methodisch, zorgvuldig, langzaam, met grote bedachtzaamheid en overleg worden genomen." De meeste zijn dat niet: "ze zijn veranderbaar, omkeerbaar - het zijn tweerichtingsdeuren", en die "kunnen en moeten snel worden genomen door individuen of kleine groepen met een goed beoordelingsvermogen."

Dit is belangrijker met een model dan zonder, omdat een model het onderscheid afvlakt. Vraag het in dezelfde sessie naar je logindeling en naar je datamodel, en je krijgt twee even grondige, even zelfverzekerde antwoorden. Een van die beslissingen kun je op een dinsdagmiddag wijzigen. Met de andere leef je nog steeds wanneer de mensen die haar hebben genomen al vertrokken zijn.

De eerste stap is dus niet "welke optie". Het is de beslissing classificeren: wat kost het daadwerkelijk om dit terug te draaien, in welke eenheid, en wat maakt het duur. Een model is goed in die vraag wanneer je die stelt, maar zal haar nooit uit zichzelf opwerpen.

Er is nog een derde antwoord dat het model ook niet zal geven: dit hoeft nog niet beslist te worden. Een eenrichtingsdeur uitstellen totdat je meer weet, is vaak het meest ervaren wat een lead kan doen, en het lijkt op besluiteloosheid voor iedereen die niet goed oplet.

Question twee: kan dit team het om 3 uur 's nachts beheren?

Een model weet wat technisch goed is. Het heeft de architectuurblogs gelezen, en die architectuurblogs zijn geschreven door mensen bij bedrijven met een platformteam.

Wat het niet weet, is wie er dienst heeft, wat die persoon eerder heeft beheerd, waarvoor diegene wordt opgepiept en hoeveel van hen hier over achttien maanden nog zullen zijn. Dat zijn de feiten die de vraag daadwerkelijk bepalen, en juist die komen nooit in de prompt terecht. Het resultaat is een aanbeveling die in abstracte zin echt correct is, maar verkeerd uitpakt voor vier engineers die nog nooit een messagebroker hebben beheerd.

De vraag naar uitvoerbaarheid is niet "is dit goed", maar "wat kost dit ons tijdens de slechtste nacht van het jaar". Wie krijgt een melding. Wat die persoon moet weten. Wat er in het runbook staat. Wat er gebeurt wanneer de enige persoon die het begrijpt op vakantie is. Zet die punten als beperkingen in de prompt en de shortlist verandert, vaak drastisch.

Prompt 1 - orden de beslissing voordat je haar neemt

Beveel nog geen optie aan. Dit is een technische beslissing die ik moet nemen: [DESCRIBE] Classificeer het eerst: - Is dit omkeerbaar, moeilijk terug te draaien of feitelijk permanent? - Wat zouden we specifiek moeten doen om dit over 12 maanden terug te draaien, en wat zijn de kosten in engineer-weken en risico? - Wat maakt het duur om dit terug te draaien: data, contracten, publieke API, aannemen, iets anders? - Moet dit nu worden beslist? Zo niet, wat zouden we later weten dat nu nog niet, en wat kost wachten? - Wie is de juiste persoon om hierover te beslissen: alleen ik, ik en één de ander, of het hele team met een schriftelijk voorstel? Zeg me dan duidelijk: is dit een deur die maar één kant op werkt of een deur die twee kanten op werkt, en besteed ik er de juiste hoeveelheid proces aan? Als ik zeg dat dan als ik te lang blijf wikken over een omkeerbare beslissing.

Prompt 2 - de filter voor uitvoerbaarheid

Geef het team mee, niet alleen het probleem. De onderstaande feiten zijn de feiten die het antwoord veranderen.

Beoordeel deze opties voor MIJN team, niet tegenover de beste praktijk. BESLISSING: [DESCRIBE] OPTIES: [LIST] MIJN TEAM: - [N] engineers. Ervaringsmix: [BESCHRIJF EERLIJK] - Wat we eerder daadwerkelijk in productie hebben beheerd: [LIST] - Wat we nog nooit hebben uitgevoerd: [LIST] - Piketdienst: [WIE, HOE VAAK EN OF HET BETAALD IS] - Verwacht verloop: wie kan vertrekken, en wat alleen die persoon weet - Ons werkelijke verhaal over implementatie en terugdraaien vandaag Beantwoord voor elke optie: 1. Wie krijgt een melding als dit stukgaat, en wat moeten zij weet om het om 3 uur 's nachts te repareren? 2. Wat is de foutmodus die een week lang niemand opmerkt? 3. Wat moet het runbook bevatten, en wie schrijft het? 4. Wat gebeurt er als de persoon die dit heeft bepleit vertrekt? 5. Wat zijn de operationele kosten in uren per maand, niet in dollars? Rangschik de opties vervolgens op basis van wat DIT team kan uitvoeren, en zeg expliciet waar die rangschikking afwijkt van wat technisch het beste is antwoord. Ik wil beide zien.
Skill uitgelicht
Dante - Tech Lead AI Skill
Dante - Tech Lead AI Skill
$19 · één betaling

Draagt de feiten over het team mee tussen sessies, en dat maakt hier het volledige verschil. Elke keer opnieuw je stack, je piketrooster en wat je team nog nooit heeft beheerd in een nieuwe chat typen is waarom de meeste mensen afhaken en genoegen nemen met het algemene antwoord. Het ordent beslissingen ook op omkeerbaarheid voordat het iets aanbeveelt en houdt je beslissingen in uitvoering bij, zodat het de beslissing van vorige week niet meer tegenspreekt.

Bekijk Dante - Tech Lead AI Skill →

Reviews: het probleem van de platte lijst

Vraag een model om een diff te reviewen en je krijgt een lijst. Een naamgevingsvoorkeur, een ontbrekende test en een race condition, allemaal op dezelfde grootte weergegeven, in dezelfde afgemeten toon, met hetzelfde vertrouwen. Dat maakt feedback van AI-reviews vermoeiend om te ontvangen en nutteloos als onderwijsmiddel: de auteur kan niet zien wat belangrijk is en lost dus alles mechanisch op of scant het.

Twee correcties. Ten eerste: dwing een scheiding naar ernst af met een limiet: hoogstens drie must-fix-items, en al het andere expliciet optioneel. Een limiet dwingt het om te kiezen, en wat het kiest is informatief.

Ten tweede, en belangrijker voor een lead: het kent je conventies niet, dus zal het ze verzinnen. Het zal een junior vertellen dat volkomen redelijke code een standaard schendt die niet jullie standaard is, alsof die universeel is. Dat is erger dan geen review, omdat de junior gelooft dat jij dit onderschrijft. Geef het je conventies en verbied het om regels te beweren die je niet hebt aangeleverd.

Prompt 3 - een review die onderwijst

Review deze diff als feedback die ik aan de auteur zal doorgeven. OUR CONVENTIONS: [PLAK HIER OF LINK NAAR DE STIJLGIDS] CONTEXT: [WAAR DEZE WIJZIGING VOOR IS EN NIVEAU VAN DE AUTEUR] Regels: - Hoogstens 3 MUST FIX-items. Als je meer kandidaten hebt, kies en vertel me wat je hebt weggelaten. - Al het andere valt onder OPTIONAL en wordt gemarkeerd als mijn voorkeur in plaats van een regel. - Geef voor elke MUST FIX: de specifieke fout die ermee wordt voorkomen, met de invoer of de volgorde die dit activeert. "Dit kan problemen" is geen reviewopmerking. - Beweer geen enkele standaard die niet in de conventies staat die ik je hebt gegeven. Als je denkt dat iets fout is, maar het slechts een elders een conventie is, zeg dat dan met die woorden. - Noem één ding dat de auteur goed heeft gedaan, maar alleen als dat waar en specifiek. - Geen opmerking over opmaak. Een linter doet dat. En los van de review: vertel me wat deze diff suggereert dat de auteur het nog niet begrijpt, dus weet ik wat ik moet te onderwijzen in plaats van wat te corrigeren.

De zaak naar boven toe bepleiten

Tech leads besteden verrassend veel tijd aan het vragen om tijd. Refactor dat ding, werk de technische schuld weg, besteed een sprint aan de deploy-pipeline. Vraag een model om die businesscase te schrijven en het levert er graag een met cijfers in - een percentage vermeden incidenten, een aantal engineeringuren, een snelheidswinst. Die cijfers heb je het niet gegeven. Het heeft ze verzonnen, en je staat op het punt je naam eronder te zetten tegenover een directeur.

Dezelfde regel als overal: geen getal dat het model niet is gegeven. Maar er is hier een beter gebruik voor dan de casus überhaupt op te stellen.

Vraag het om tegen je in te gaan. Laat het de sterkste reden schrijven waarom een verstandige directeur nee zou moeten zeggen. Die uitvoer is echt nuttig, omdat die je vertelt waar je daadwerkelijk antwoord op moet geven, en modellen zijn hier goed in als je ze erop richt en slecht in het opmerken dat dit moet gebeuren.

Prompt 4 - speel de weigering zo sterk mogelijk

Ik wil vragen om [TIJD / EXTRA MENSEN / EEN SPRINT] om [HET WERK]. Dit is mijn casus: [PLAKKEN] Verbeter mijn casus niet. Ga ertegenin. Schrijf de sterkste versie van de weigering die een competente, zou geven, schrijf de sterkste versie van de weigering die een competente, goedbedoelende [DIRECTEUR / VP / OPRICHTER] zou geven, gegeven dat ze ook verantwoordelijk zijn voor [DE CONCURRERENDE PRIORITEIT]. Gebruik hun woordenschat, niet die van mij. Daarna: - benoem de zwakste schakel in mijn argument en waarom die het zwakst is - benoem het ding waarvan ik aanneem dat ze het er al mee eens zijn, maar dat dat misschien niet zo is - vertel me welk bewijs hen daadwerkelijk van mening zou doen veranderen, en of Het staat er nu zo voor - markeer elk getal in mijn casus en waar het vandaan kwam. Als ik als ik je geen cijfer geef, verzin er dan geen - schrijf [AANTAL NODIG: wat] achter. Als mijn casus echt zwak is, zeg dat dan. Ik kom er liever hier.

Blokkeren zonder een router te worden

Een engineer loopt vast. De snelle route is om hun probleem in een chat te plakken, het antwoord te krijgen en het aan hen door te geven. Het werkt, het kost negentig seconden en maakt de zaken stilletjes erger: de engineer leert niets, de volgende keer komen ze sneller naar jou toe en je hebt jezelf veranderd in een trage API vóór een snelle.

De schaalbare versie is om het model om de vragen te vragen in plaats van om het antwoord. Het is echt goed in het genereren van het diagnostische pad als je het verbiedt dat pad zelf te bewandelen.

Prompt 5 - vragen, geen antwoorden

Een engineer in mijn team loopt hierop vast: [BESCHRIJF HET PROBLEEM EN WAT ZE HEBBEN GEPROBEERD] Los het niet op. Hint niet naar de oplossing. Zeg niet wat je denkt dat de oorzaak is. Geef me de drie vragen die ik hun moet stellen, in de volgorde waarin ik moeten vragen, die hen waarschijnlijk het meest zou helpen om het te vinden zelf. Zeg bij elke vraag wat een ja en een nee zou elke regel uit te sluiten. Zeg me dan: wat zou deze engineer al moeten weten om vraag één om nuttig te zijn? Als ze het niet weten, is die lacune wat er werkelijk moet worden aangeleerd, en de debug-sessie is de verkeerde interventie.

Prompt 6 - het beslisverslag dat niemand schrijft

Het artefact dat een techlead niets kost en de volgende zes maanden bespaart. Doe dit aan het einde van het gesprek, zolang de afgewezen opties er nog in staan.

Maak van ons gesprek een beslisdocument. Kort. Schriftelijk voor iemand die over een jaar bij het team komt en vraagt waarom het zo werkt op deze manier. Secties: - De beslissing, in één zin - De datum en wie de beslissing nam - Of dit eenrichtings- of tweerichtingsverkeer was en wat het kostte om het te omkeren - De opties die we hebben afgewezen en de werkelijke reden waarom elke optie werd afgewezen - niet "het was slechter" - De beperkingen die de doorslag gaven, inclusief het team en operationele - Wat we bewust hebben opgegeven - Wat zou ons dit opnieuw laten bekijken: een specifieke aanleiding, niet "als er dingen veranderen" Gebruik alleen wat in dit gesprek is gezegd. Waar ik beweerde iets zonder bewijs, schrijf het dan als een aanname dan een feit. Markeer alles waarvan je niet zeker weet of ik het echt heb gezegd.

Neem de vraag over het delen van code één keer door, voordat je aan de workflow begint in plaats van er middenin

Een techlead is meestal de persoon die bepaalt, of op zijn minst voordoet, wat het team in een chatvenster plakt. Broncode, klantgegevens, inloggegevens en interne architectuur vallen onder je arbeidsovereenkomst, het beleid van je bedrijf en vaak een klantcontract, en het antwoord hangt af van welke laag en welk account je gebruikt, niet van wat op dat moment handig is.

Bepaal dit bewust en leg het schriftelijk vast voordat het een gewoonte wordt. Praktijken die altijd standhouden: redeneer over de vorm van een probleem in plaats van het bestand te plakken, maak identificerende gegevens en geheimen onherkenbaar voordat er iets wordt ingevoerd, houd klantgegevens er volledig buiten en onthoud dat een klein genoeg fragment plus je openbare repository de codebase net zo zeker kan identificeren als een commentaarregel bovenaan. Als je bedrijf een beleid heeft, gaat dat vóór deze pagina. Als dat niet zo is, ben jij waarschijnlijk degene die het moet schrijven.

Waar het misgaat

Mislukking Wat er gebeurt Wat je eraan doet
Afgevlakte inzet Een omkeerbare keuze en een permanente keuze krijgen hetzelfde zelfverzekerde, grondige antwoord Sorteer eerst op omkeerbaarheid. Vraag nooit "welke optie" voordat je vraagt "wat kost het om dit ongedaan te maken"
De architectuur van een blogbericht Beveelt aan wat een bedrijf met een platformteam zou doen, omdat dat de partij is die het bronmateriaal schrijft Zet de piketdienstplanning, het verlooprisico en wat je nooit hebt beheerd in de prompt als beperkingen
Verzonnen bedrijfscijfers Percentages en tijdsbesparingen in je tech-debt-argument die uit het niets komen Verbied elk cijfer dat je niet zelf hebt aangeleverd. Gebruik het om je standpunt te onderbouwen, niet om het te schrijven
Verzonnen conventies Vertelt een junior dat diens code een regel overtreedt die niet jouw regel is, op een toon die klinkt als de jouwe Lever je conventies aan en verbied het om een standaard te poneren die je niet hebt opgegeven
Platte reviewlijsten Een pietluttigheid over naamgeving en een raceconditie met exact hetzelfde gewicht en dezelfde mate van zekerheid Een severitybudget. Hooguit drie punten die absoluut moeten worden opgelost, en het moet kiezen
Het zal niet zeggen dat je moet wachten Als het gevraagd wordt om te beslissen, beslist het. Het zal niet uit zichzelf aangeven dat de beslissing voorbarig is Vraag expliciet of hierover nu een beslissing nodig is en wat wachten oplevert
Instemming Vraag of je plan deugt en je krijgt te horen dat dat zo is Vraag om het sterkste argument ertegen, in de stem van degene die het moet goedkeuren
Niets van het vertrouwen Het was niet bij het incident betrokken, weet niet dat deze engineer opgebrand is en heeft geen gezag binnen het team Die helft van het werk delegeer je niet. Dit is voor het redeneren en schrijven

Hoe installeer je de Dante Skill?

De download is een ZIP met SKILL.md in de hoofdmap van het archief, niet in een geneste map - die mapstructuur is de gebruikelijke reden waarom uploaden mislukt. Open in de Claude-desktopapp Aanpassen → Skills, upload de ZIP en schakel de Skill in.

Skills moeten code-uitvoering ingeschakeld hebben, onder Instellingen → Mogelijkheden. Het helpcentrum van Anthropic vermeldt momenteel Skills voor Free, Pro, Max, Team en Enterprise, terwijl de Academy-tutorial Pro, Max, Team en Enterprise vermeldt - dus als je het gratis abonnement gebruikt, controleer dan Instellingen → Mogelijkheden voor je eigen account in plaats van de informatie op een van beide pagina's zonder meer aan te nemen. De volledige uitleg staat in de installatiegids voor Skills.

In ChatGPT of Gemini is er geen uploadstap: open SKILL.md, kopieer de inhoud en plak die in aangepaste instructies. Je verliest het automatisch activeren, maar behoudt de methode.

Voor wie is dit bedoeld?

Tech leads en staff engineers die naast hun eigen oplevering de technische koers bepalen, en beginnende leads die de verantwoordelijkheid al dragen maar de titel nog niet hebben. Het werkt in Claude, ChatGPT of elke AI-chat.

De engineeringrollen zijn opgesplitst in afzonderlijke Skills, elk €29 en als eenmalige download:

De bredere verzameling bestaat uit de skills voor softwareontwikkelaars en de software- & IT-skills.

Samengevat:

Sorteer de beslissing voordat je haar neemt, want een model geeft een omkeerbare keuze en een permanente keuze met hetzelfde zelfverzekerde antwoord en zal je nooit vertellen met welk soort keuze je te maken hebt. Neem je team in de prompt op als harde randvoorwaarde - wie dienst heeft, wat ze nog nooit hebben beheerd, wie mogelijk vertrekt - en vraag om beide ranglijsten: de technisch beste en de ranglijst met de keuze die je team daadwerkelijk kan uitvoeren. Beperk je reviews tot drie punten die absoluut moeten worden opgelost en verbied het model om conventies te poneren die je niet hebt aangeleverd, anders leert het je junioren regels die je nooit hebt vastgesteld. Gebruik het om tegen je eigen argument voor technische schuld in te gaan in plaats van dat argument te schrijven, en laat het geen enkel getal verzinnen dat je niet hebt aangeleverd. Leg vervolgens de beslissing vast zolang de afgewezen opties nog in het gesprek staan. Voor de teamfeiten die tussen sessies worden bewaard: Dante - Tech Lead AI Skill ($19). Werkt in Claude, ChatGPT en elke AI-chat, met een 30 dagen niet-goed-geld-teruggarantie.

Skill · .md · Werkt met Claude & ChatGPT

Dante - Tech Lead AI Skill

Sorteert beslissingen op basis van de kosten om ze terug te draaien voordat het iets aanbeveelt, toetst opties aan wat je team daadwerkelijk heeft beheerd, beperkt zijn reviewcommentaar en pleit tegen jouw standpunt wanneer je dat vraagt. Geen abonnement. Permanent van jou.

$19
Ontvang de Dante Skill →

KissMySkills is een marketplace met meer dan 2.000 AI-skills, meer dan 80 promptpakketten, meer dan 75 agents & gratis tools voor Claude, ChatGPT & elke AI-chat.

Gerelateerde Skill-gidsen

Veelgestelde vragen

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 die werken. Geen onzin.

Blader door elke skill, prompt pack en agent in de winkel.

Bekijk alle vaardigheden →Of probeer de gratis tools