How to Use Claude as a Tech Lead: The Dante Skill Guide

Updated
Skill · .md

The skill behind this guide: Dante - Tech Lead AI Skill. Holds your stack, your team's actual operating experience and your in-flight decisions, so the advice is filtered by what your team can run rather than by what is technically best - $19, one payment, yours permanently.

View the Dante skill →

Two questions settle most technical decisions, and a model volunteers neither of them: how expensive is this to undo, and can this team run it at three in the morning. Ask a model which database, which framework, which architecture, and it will pick one and defend it well - at exactly the same confidence whether the wrong answer costs you a week or three years, and without knowing who is on call. The non-coding half of the tech lead job is mostly those two questions. This guide is about forcing them into the conversation.

Question one: is this a door you can walk back through?

Amazon's 2015 shareholder letter puts it about as cleanly as it can be put. Some decisions are "consequential and irreversible or nearly irreversible - one-way doors - and these decisions must be made methodically, carefully, slowly, with great deliberation and consultation." Most are not: "they are changeable, reversible - they're two-way doors", and those "can and should be made quickly by high judgment individuals or small groups."

The reason this matters more with a model than without one is that a model flattens the distinction. Ask it about your log format and about your data model in the same session and you get two equally thorough, equally confident answers. One of those decisions you can change on a Tuesday afternoon. The other one you will still be living with when the people who made it have left.

So the first move is not "which option". It is sort the decision: what does undoing this actually cost, in what unit, and what makes it expensive. A model is good at that question when you ask it, and will never raise it on its own.

There is a third answer the model will also not offer: this does not need deciding yet. Deferring a one-way door until you know more is often the most senior thing a lead does, and it looks like indecision to everyone who is not paying attention.

Question two: can this team run it at 3am?

A model knows what is technically good. It has read the architecture blogs, and the architecture blogs are written by people at companies with a platform team.

What it does not know is who is on call, what they have operated before, what they will be paged for, and how many of them will still be here in eighteen months. Those are the facts that actually decide the question, and they are the ones that never make it into the prompt. The result is a recommendation that is genuinely correct in the abstract and wrong for four engineers who have never run a message broker.

The operability question is not "is this good", it is "what does this cost us on the worst night of the year". Who gets paged. What they have to know. What the runbook says. What happens when the one person who understands it is on holiday. Put those in the prompt as constraints and the shortlist changes, often dramatically.

Prompt 1 - sort the decision before making it

Do not recommend an option yet. Here is a technical decision I have to make: [DESCRIBE] First, classify it: - Is this reversible, hard to reverse, or effectively permanent? - What specifically would we have to do to undo it in 12 months, and what is the cost in engineer-weeks and in risk? - What makes it expensive to undo: data, contracts, public API, hiring, something else? - Does it have to be decided now? If not, what would we know later that we do not know now, and what does waiting cost? - Who is the right person to decide this: me alone, me and one other, or the whole team with a written proposal? Then tell me plainly: is this a one-way door or a two-way door, and am I spending the right amount of process on it? If I am over-deliberating a reversible decision, say so.

Prompt 2 - the operability filter

Give it the team, not just the problem. The facts below are the ones that change the answer.

Evaluate these options against MY team, not against best practice. DECISION: [DESCRIBE] OPTIONS: [LIST] MY TEAM: - [N] engineers. Seniority mix: [DESCRIBE HONESTLY] - What we have actually operated in production before: [LIST] - What we have never run: [LIST] - On-call: [WHO, HOW OFTEN, AND WHETHER IT IS PAID] - Expected turnover: who might leave, and what only they know - Our real deployment and rollback story today For each option, answer: 1. Who gets paged when this breaks, and what do they need to know to fix it at 3am? 2. What is the failure mode nobody notices for a week? 3. What does the runbook have to contain, and who writes it? 4. If the person who championed this leaves, what happens? 5. What is the operational cost in hours per month, not in dollars? Then rank the options by what THIS team can run, and say explicitly where that ranking differs from the technically best answer. I want to see both.
Skill spotlight
Dante - Tech Lead AI Skill
Dante - Tech Lead AI Skill
$19 · one payment

Carries the team facts between sessions, which is the whole difference here. Re-typing your stack, your on-call rota and what your team has never operated into a fresh chat every time is why most people give up and take the generic answer. It also sorts decisions by reversibility before recommending anything, and holds your in-flight decisions so it stops contradicting last week's call.

View Dante - Tech Lead AI Skill →

Reviews: the flat-list problem

Ask a model to review a diff and you get a list. A naming preference, a missing test, and a race condition, all rendered at the same size, in the same measured tone, with the same confidence. That is what makes AI review feedback exhausting to receive and useless as teaching: the author cannot tell what matters, so they either fix everything mechanically or skim it.

Two corrections. First, force a severity split with a budget: at most three must-fix items, everything else explicitly optional. A budget makes it choose, and what it chooses is informative.

Second, and more important for a lead: it does not know your conventions, so it will invent them. It will tell a junior that perfectly reasonable code violates a standard that is not your standard, stated as though it were universal. That is worse than no review, because the junior believes you endorsed it. Give it your conventions, and forbid it from asserting any rule you did not supply.

Prompt 3 - a review that teaches

Review this diff as feedback I will pass to the author. OUR CONVENTIONS: [PASTE, or link the style guide] CONTEXT: [WHAT THIS CHANGE IS FOR, AND THE AUTHOR'S LEVEL] Rules: - At most 3 MUST FIX items. If you have more candidates, choose and tell me what you dropped. - Everything else goes under OPTIONAL and is marked as my preference rather than a rule. - For each MUST FIX: the specific failure it prevents, with the input or the sequence that triggers it. "This could cause issues" is not a review comment. - Do not assert any standard that is not in the conventions I gave you. If you think something is wrong but it is only a convention elsewhere, say so in those words. - Name one thing the author did well, only if it is true and specific. - No comment on formatting. A linter does that. Then, separately from the review: tell me what this diff suggests the author does not yet understand, so I know what to teach rather than what to correct.

Making the case upward

Tech leads spend a surprising amount of time asking for time. Refactor the thing, pay down the debt, spend a sprint on the deploy pipeline. Ask a model to write that business case and it will happily produce one with numbers in it - a percentage of incidents avoided, an engineering-hours figure, a velocity gain. You did not give it those numbers. It made them up, and you are about to put your name on them in front of a director.

The same rule as anywhere: no figure the model was not given. But there is a better use of it here than drafting the case at all.

Ask it to argue against you. Have it write the strongest reason a sensible director should say no. That output is genuinely useful, because it tells you what you actually have to answer, and models are good at this when pointed at it and bad at noticing it needs doing.

Prompt 4 - steelman the refusal

I want to ask for [TIME / HEADCOUNT / A SPRINT] to do [THE WORK]. Here is my case: [PASTE] Do not improve my case. Argue against it. Write the strongest version of the refusal a competent, well-intentioned [DIRECTOR / VP / FOUNDER] would give, given that they are also accountable for [THE COMPETING PRIORITY]. Use their vocabulary, not mine. Then: - name the weakest link in my argument, and why it is weakest - name the thing I am assuming they already agree with, that they may not - tell me what evidence would actually move them, and whether I currently have it - flag every number in my case and where it came from. If I did not give you a figure, do not supply one - write [NUMBER NEEDED: what] instead. If my case is genuinely weak, say that. I would rather find out here.

Unblocking without becoming a router

An engineer is stuck. The fast path is to paste their problem into a chat, get the answer, and hand it over. It works, it takes ninety seconds, and it quietly makes things worse: the engineer learns nothing, they come to you sooner next time, and you have turned yourself into a slow API in front of a fast one.

The version that scales is to ask the model for the questions rather than the answer. It is genuinely good at generating the diagnostic path if you forbid it from walking it.

Prompt 5 - questions, not answers

An engineer on my team is stuck on this: [DESCRIBE THE PROBLEM AND WHAT THEY HAVE TRIED] Do not solve it. Do not hint at the solution. Do not say what you think the cause is. Give me the three questions I should ask them, in the order I should ask them, that would most likely lead them to find it themselves. For each question, say what a yes and a no would each rule out. Then tell me: what would this engineer have to already know for question one to be useful? If they do not know it, that gap is the actual thing to teach, and the debugging session is the wrong intervention.

Prompt 6 - the decision record nobody writes

The artefact that costs a tech lead nothing and saves the next one six months. Run it at the end of the conversation, while the rejected options are still in it.

Turn our conversation into a decision record. Short. Written for someone who joins the team in a year and asks why it works this way. Sections: - The decision, in one sentence - The date, and who decided - Whether this was a one-way or two-way door, and the cost to reverse - The options we rejected, and the actual reason each one was rejected - not "it was worse" - The constraints that decided it, including the team and operational ones - What we knowingly traded away - What would make us revisit this: a specific trigger, not "if things change" Use only what was said in this conversation. Where I asserted something without evidence, write it as an assumption rather than a fact. Mark anything you are unsure I actually said.

Settle the code-sharing question once, before the workflow rather than inside it

A tech lead is usually the person who sets, or at least models, what the team pastes into a chat window. 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 which tier and which account you are using, not on what is convenient at the time.

Decide it deliberately, in writing, before it becomes a habit. Practices that hold up regardless: reason about the shape of a problem rather than pasting the file, redact identifiers and secrets before anything goes in, keep customer data out entirely, and remember that a small enough snippet plus your public repo can identify the codebase as surely as a header comment. If your company has a policy, it outranks this page. If it does not, you are probably the person who should write it.

Where it fails

Failure What happens What to do about it
Flattened stakes A reversible choice and a permanent one get the same confident, thorough answer Sort by reversibility first. Never ask "which option" before asking "what does undoing this cost"
The blog-post architecture Recommends what a company with a platform team would do, because that is who writes the source material Put the on-call rota, the turnover risk and what you have never operated into the prompt as constraints
Invented business numbers Percentages and hour-savings in your tech-debt case that came from nowhere Forbid any figure you did not supply. Use it to attack your case, not to write it
Invented conventions Tells a junior their code breaks a rule that is not your rule, in a tone that sounds like yours Supply your conventions and forbid asserting any standard you did not give it
Flat review lists A naming nit and a race condition at identical weight and confidence A severity budget. Three must-fix at most, and it has to choose
It will not say wait Asked to decide, it decides. It will not volunteer that the decision is premature Ask explicitly whether this needs deciding now and what waiting buys
Agreement Ask whether your plan is sound and you will be told it is Ask for the strongest case against it, in the voice of the person who has to approve it
None of the trust It was not in the incident, does not know this engineer is burnt out, and carries no authority with the team That half of the job does not delegate. This is for the reasoning and the writing

How do you install the Dante skill?

The download is a ZIP with SKILL.md at the root of the archive, not inside a nested folder - that folder structure is the usual reason an upload fails. In the Claude desktop app, open Customize → Skills, upload the ZIP and toggle it on.

Skills need code execution enabled, under Settings → 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 → Capabilities for your own account rather than taking either page's word for it. The full walkthrough is in the skill installation guide.

In ChatGPT or Gemini there is no upload step: open SKILL.md, copy the contents, and paste them into custom instructions. You lose automatic triggering and keep the method.

Who is this for?

Tech leads and staff engineers carrying technical direction alongside their own delivery, and first-time leads who have the responsibility without the title yet. It works in Claude, ChatGPT or any AI chat.

The engineering roles are split into their own skills, each $19 and a one-time download:

The wider set is the software developer skills and the software & IT skills.

In summary:

Sort the decision before making it, because a model gives a reversible choice and a permanent one the same confident answer, and will never tell you which kind you have. Put your team into the prompt as a hard constraint - who is on call, what they have never operated, who might leave - and ask for both rankings, the technically best and the one your team can actually run. Budget your reviews to three must-fix items and forbid the model from asserting conventions you did not give it, or it will teach your juniors rules you never set. Use it to argue against your own tech-debt case rather than to write it, and let it invent no number you did not supply. Then write the decision record while the rejected options are still in the conversation. For the team facts held between sessions, Dante - Tech Lead AI Skill ($19). Works in Claude, ChatGPT and any AI chat, with a 30-day money-back guarantee.

Skill · .md · Works with Claude & ChatGPT

Dante - Tech Lead AI Skill

Sorts decisions by what they cost to undo before recommending anything, filters options through what your team has actually operated, budgets its review comments, and argues against your case when you ask it to. No subscription. Yours permanently.

$19
Get the Dante skill →

KissMySkills is a marketplace of 1,900+ AI skills, 60+ prompt packs, 90+ agents & free tools for Claude, ChatGPT & any AI chat.

Related Skill Guides

Put this into practice

Or get every skill with Unlimited See plans →

Frequently asked 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 that work. No fluff.

Browse every skill, prompt pack, and agent in the store.

Browse all skills →Or try the free tools