La Skill detrás de esta guía: Dante - Tech Lead AI Skill. Contiene tu stack, la experiencia operativa real de tu equipo y tus decisiones en curso, para que el asesoramiento se filtre por lo que tu equipo puede operar, en lugar de por lo que es técnicamente mejor - $29, un solo pago, tuyo para siempre.
Ver la Skill de Dante →Dos preguntas resuelven la mayoría de las decisiones técnicas, y un modelo no ofrece ninguna de las dos: cuánto cuesta deshacer esto y si este equipo puede operarlo a las tres de la madrugada. Pregúntale qué base de datos, qué framework o qué arquitectura elegir, y escogerá una opción y la defenderá bien - con exactamente la misma seguridad tanto si la respuesta equivocada te cuesta una semana como tres años, y sin saber quién está de guardia. La mitad no relacionada con la programación del trabajo de líder técnico consiste principalmente en esas dos preguntas. Esta guía trata de obligar a incluirlas en la conversación.
Question one: ¿es esta una puerta por la que puedes volver?
La carta de 2015 a los accionistas de Amazon lo expresa con tanta claridad como es posible. Algunas decisiones son «trascendentales e irreversibles, o casi irreversibles - puertas de un solo sentido - y deben tomarse de forma metódica, cuidadosa y lenta, con mucha deliberación y consulta». La mayoría no lo son: «son modificables, reversibles - son puertas de doble sentido», y esas «pueden y deben tomarse rápidamente por personas con buen criterio o grupos pequeños».
La razón por la que esto importa más con un modelo que sin él es que el modelo aplana la distinción. Pregúntale por el formato de tus registros y por tu modelo de datos en la misma sesión y obtendrás dos respuestas igual de exhaustivas e igual de seguras. Una de esas decisiones puedes cambiarla un martes por la tarde. La otra seguirá afectándote cuando las personas que la tomaron ya se hayan marchado.
Así que el primer paso no es «qué opción». Es clasificar la decisión: cuánto cuesta realmente deshacer esto, en qué unidad y qué es lo que lo encarece. Un modelo es bueno para responder esa pregunta cuando se la haces, pero nunca la planteará por sí solo.
También hay una tercera respuesta que el modelo nunca ofrecerá: esto todavía no necesita decidirse. Posponer una decisión irreversible hasta saber más suele ser lo más propio de un líder sénior, y a todos los que no están prestando atención les parece indecisión.
Question two: ¿puede este equipo operarlo a las 3 de la madrugada?
Un modelo sabe qué es técnicamente bueno. Ha leído los blogs de arquitectura, y esos blogs están escritos por personas de empresas con un equipo de plataforma.
Lo que no sabe es quién está de guardia, qué han operado antes, por qué recibirán alertas y cuántos seguirán aquí dentro de dieciocho meses. Esos son los hechos que realmente deciden la cuestión, y son precisamente los que nunca llegan al prompt. El resultado es una recomendación genuinamente correcta en abstracto y errónea para cuatro ingenieros que nunca han ejecutado un agente de mensajes.
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
Prompt 2 - el filtro de operabilidad
Dale el contexto del equipo, no solo el problema. Los datos de abajo son los que cambian la respuesta.
Conserva los datos del equipo entre sesiones, y ahí está toda la diferencia. Volver a escribir tu stack, tu rotación de guardias y lo que tu equipo nunca ha operado en un chat nuevo cada vez es la razón por la que la mayoría se rinde y acepta la respuesta genérica. También clasifica las decisiones según su reversibilidad antes de recomendar nada y conserva las decisiones en curso para dejar de contradecir la decisión de la semana pasada.
Ver Dante - Skill de IA para líderes técnicos →Revisiones: el problema de la lista plana
Pídele a un modelo que revise un diff y obtendrás una lista. Una preferencia de nomenclatura, una prueba que falta y una condición de carrera, todo presentado con el mismo tamaño, en el mismo tono mesurado y con la misma confianza. Eso es lo que hace que los comentarios de revisión de IA sean agotadores de recibir e inútiles para enseñar: el autor no puede distinguir qué importa, así que corrige todo mecánicamente o lo hojea.
Dos correcciones. Primero, obliga a separar la gravedad con un límite: como máximo tres elementos que deban corregirse, y todo lo demás debe marcarse explícitamente como opcional. Un límite hace que elija, y lo que elige es informativo.
Segundo, y más importante para un líder: no conoce tus convenciones, así que se las inventará. Le dirá a un desarrollador junior que un código perfectamente razonable infringe un estándar que no es el tuyo, presentándolo como si fuera universal. Eso es peor que no hacer ninguna revisión, porque el desarrollador junior creerá que tú lo aprobaste. Dale tus convenciones y prohíbele afirmar cualquier regla que no le hayas proporcionado.
Prompt 3 - una revisión que enseña
Presentar el caso ante la dirección
Los líderes técnicos pasan una cantidad sorprendente de tiempo pidiendo tiempo. Refactoriza esto, reduce la deuda, dedica un sprint al pipeline de despliegue. Pídele a un modelo que redacte ese caso de negocio y con gusto producirá uno con cifras: un porcentaje de incidentes evitados, una cifra de horas de ingeniería, una mejora de la velocidad. Tú no le diste esas cifras. Se las inventó, y estás a punto de ponerles tu nombre delante de un director.
La misma regla que en cualquier otro lugar: ninguna cifra que el modelo no haya recibido. Pero aquí hay un uso mejor que redactar el caso completo.
Pídele que argumente en tu contra. Haz que escriba la razón más sólida por la que un director sensato debería decir que no. Ese resultado es realmente útil, porque te dice qué debes responder en realidad, y los modelos son buenos en esto cuando se les orienta y malos para darse cuenta de que necesitan hacerlo.
Prompt 4 - defender la negativa más sólida
Desbloquear sin convertirse en un enrutador
Un ingeniero está atascado. El camino rápido es pegar su problema en un chat, obtener la respuesta y pasársela. Funciona, tarda noventa segundos y empeora las cosas discretamente: el ingeniero no aprende nada, la próxima vez acudirá a ti antes y te has convertido en una API lenta delante de una rápida.
La versión que escala consiste en pedirle al modelo las preguntas en lugar de la respuesta. Es realmente bueno generando el camino de diagnóstico si le prohíbes recorrerlo.
Prompt 5 - preguntas, no respuestas
Prompt 6 - el registro de decisiones que nadie escribe
El artefacto que no le cuesta nada a un responsable técnico y le ahorra seis meses al siguiente. Ejecútalo al final de la conversación, mientras las opciones rechazadas todavía están incluidas.
Resuelve la cuestión de compartir código de una vez, antes del flujo de trabajo y no dentro de él
Un responsable técnico suele ser la persona que establece, o al menos modela, qué pega el equipo en una ventana de chat. El código fuente, los datos de clientes, las credenciales y la arquitectura interna se rigen por tu contrato laboral, la política de tu empresa y, a menudo, un contrato con el cliente, y la respuesta depende del nivel y la cuenta que estés utilizando, no de lo conveniente que resulte en ese momento.
Decídelo deliberadamente y por escrito antes de que se convierta en un hábito. Prácticas que funcionan en cualquier caso: razona sobre la forma de un problema en lugar de pegar el archivo, redacta los identificadores y secretos antes de introducir cualquier cosa, mantén completamente fuera los datos de clientes y recuerda que un fragmento lo bastante pequeño, junto con tu repositorio público, puede identificar el código base con la misma certeza que un comentario de cabecera. Si tu empresa tiene una política, esta prevalece sobre esta página. Si no la tiene, probablemente tú seas quien debería redactarla.
Dónde falla
| Fallo | Qué sucede | Qué hacer al respecto |
|---|---|---|
| Importancia aplanada | Una decisión reversible y otra permanente reciben la misma respuesta segura y exhaustiva | Ordena primero por reversibilidad. Nunca preguntes «qué opción» antes de preguntar «cuánto cuesta deshacer esto» |
| La arquitectura de una publicación de blog | Recomienda lo que haría una empresa con un equipo de plataforma, porque ese es quien escribe el material de origen | Incluye en el prompt como restricciones la rotación de guardias, el riesgo de rotación de personal y aquello que nunca has operado |
| Cifras empresariales inventadas | Porcentajes y horas ahorradas en tu argumento sobre la deuda técnica que aparecieron de la nada | Prohíbe cualquier cifra que no hayas proporcionado. Úsala para defender tu argumento, no para redactarlo |
| Convenciones inventadas | Le dice a alguien junior que su código infringe una regla que no es la tuya, con un tono que suena como el tuyo | Proporciona tus convenciones y prohíbele afirmar cualquier estándar que no le hayas dado tú |
| Listas de revisión planas | Un detalle de nomenclatura y una condición de carrera con el mismo peso y nivel de confianza | Un presupuesto de gravedad. Como máximo, tres problemas que deben corregirse, y tiene que elegir |
| No dirá que esperes | Cuando se le pide que decida, decide. No ofrecerá voluntariamente que la decisión es prematura | Pregúntale explícitamente si esto debe decidirse ahora y qué beneficios aporta esperar |
| Acuerdo | Pregúntale si tu plan es sólido y te dirá que sí | Pídele que exponga el argumento más sólido en contra, con la voz de la persona que tiene que aprobarlo |
| Nada de la confianza | No estuvo presente en el incidente, no sabe que este ingeniero está agotado y no tiene autoridad sobre el equipo | Esa mitad del trabajo no se delega. Esto es para el razonamiento y la redacción |
¿Cómo se instala la Skill de Dante?
La descarga es un ZIP con SKILL.md en la raíz del archivo, no dentro de una carpeta anidada; esa estructura de carpetas es la razón habitual por la que falla la carga. En la aplicación de escritorio de Claude, abre Personalizar → Skills, carga el ZIP y actívala.
Las Skills necesitan tener habilitada la ejecución de código, en Configuración → Capacidades. El centro de ayuda de Anthropic actualmente incluye Skills en los planes Free, Pro, Max, Team y Enterprise, mientras que su tutorial de Academy incluye Pro, Max, Team y Enterprise; por eso, si tienes el plan gratuito, comprueba Configuración → Capacidades en tu propia cuenta en lugar de confiar en lo que dice cualquiera de esas páginas. La guía completa está en la guía de instalación de Skills.
En ChatGPT o Gemini no hay ningún paso de carga: abre SKILL.md, copia el contenido y pégalo en las instrucciones personalizadas. Pierdes la activación automática, pero conservas el método.
¿Para quién es esto?
Líderes técnicos e ingenieros sénior que marcan la dirección técnica mientras siguen entregando su propio trabajo, y líderes primerizos que ya tienen la responsabilidad, pero todavía no el título. Funciona en Claude, ChatGPT o cualquier chat de AI.
Los roles de ingeniería están divididos en Skills independientes, cada uno cuesta $29 y se descarga una sola vez:
- Viktor - Arquitecto de software - las decisiones irreversibles, cuando la decisión está por encima de tu equipo
- Priya - Gerente de ingeniería - la mitad relacionada con las personas, una vez que deja de ser técnica
- Yuri - Revisor de código - revisar como disciplina propia, en lugar de como un paso
- Max - Desarrollador Full Stack - la mitad del trabajo en la que sigues entregando
- Rami - Ingeniero de DevOps - la estrategia de despliegue y reversión que la cuestión de la operabilidad sigue planteando
- Oleg - Ingeniero de bases de datos - dónde están realmente las decisiones irreversibles, la mayoría de las veces
El conjunto más amplio incluye los skills para desarrolladores de software y los skills de software y TI.
En resumen:
Ordena la decisión antes de tomarla, porque un modelo da la misma respuesta segura a una opción reversible y a una permanente, y nunca te dirá cuál de las dos tienes. Incluye a tu equipo en el prompt como una restricción estricta: quién está de guardia, qué no han operado nunca, quién podría irse, y pide ambas clasificaciones: la técnicamente mejor y la que tu equipo realmente puede ejecutar. Limita tus revisiones a tres elementos que deban corregirse y prohíbe al modelo afirmar convenciones que no le hayas proporcionado, o enseñará a tus perfiles júnior reglas que nunca estableciste. Úsalo para argumentar en contra de tu propio caso de deuda técnica, en lugar de redactarlo, y no permitas que invente ningún número que no hayas proporcionado. Después, redacta el registro de decisiones mientras las opciones rechazadas aún están en la conversación. Para conservar los datos del equipo entre sesiones, Dante - Skill de AI para Tech Lead. Funciona en Claude, ChatGPT y cualquier chat de AI, con una garantía de devolución del dinero de 30 días.
Dante - Skill de AI para Tech Lead
Ordena las decisiones según lo que cuesta deshacerlas antes de recomendar nada, filtra las opciones según lo que tu equipo realmente ha operado, limita sus comentarios de revisión y argumenta en contra de tu postura cuando se lo pidas. Sin suscripción. Tuyo para siempre.
KissMySkills es un marketplace con más de 1.800 skills de AI, más de 80 packs de prompts, más de 75 agentes y herramientas gratuitas para Claude, ChatGPT y cualquier chat de AI.
Guías de Skills relacionadas
- Cómo usar Claude como arquitecto de software: la guía del Skill de Viktor
- Cómo usar Claude como gerente de ingeniería: la guía del Skill de Priya
- Cómo usar Claude para programar: la guía de Max, desarrollador full stack
- Cómo usar Claude como ingeniero de bases de datos: la guía del Skill de Oleg
- Cómo usar Claude para DevOps: la guía del Skill de Rami
- Cómo instalar un Skill de Claude (paso a paso, 2026)
