Tenía una skill de IA funcional para tareas de ingeniería.
Al principio parecía una instrucción normal: rol, tarea, formato de respuesta y unas pocas restricciones. Eso era suficiente mientras los escenarios eran cortos: revisar un fragmento de código, proponer un plan, analizar un error evidente.
Luego la skill empezó a recibir tareas más complejas.
Por ejemplo: “revisa este PR antes del merge”.
En una frase tan corta hay mucho trabajo oculto. Hay que entender qué cambia, qué restricciones existen, dónde puede estar el riesgo, en qué se basa la conclusión, qué observaciones bloquean realmente la aceptación del cambio y cuáles son solo recomendaciones.
Cada nuevo error añadía otra regla a la instrucción.
La IA proponía una corrección demasiado rápido — así que apareció el requisito de definir primero el límite de la tarea.
Mezclaba observaciones importantes con cambios de gusto — así que apareció la regla de separar bloqueadores, preguntas y sugerencias.
Escribía conclusiones seguras sin verificación — así que apareció un bloque sobre evidencia.
La respuesta se volvió técnicamente correcta, pero pesada de leer — así que se añadió una regla editorial.
Así es como un prompt normal se convierte poco a poco en un protocolo de trabajo.
En algún momento, el problema ya no está solo en el contenido. El problema está en la propia forma: un solo texto intenta sostener el trabajo de un analista de entrada, un desarrollador, un arquitecto, un revisor de riesgos, QA y un editor final.
A esta estructura la llamo, para mí, consejo de skill: una sola skill de IA para el usuario, pero con varias zonas de responsabilidad claramente separadas dentro.
Qué entiendo por una skill de IA
Por skill de IA entiendo una instrucción estable para un escenario de trabajo repetido.
Puede ser una skill para Codex, un asistente separado, un system prompt, un conjunto de reglas dentro de un repositorio o cualquier mecanismo parecido. El nombre de la herramienta es secundario. Lo importante es el sentido práctico: el usuario trae una tarea de un mismo tipo, y la IA la ejecuta siguiendo un orden esperado.
Ejemplos de esos escenarios:
- hacer una review de un pull request;
- analizar un bug;
- preparar un plan de cambio seguro;
- revisar una lista de release;
- preparar un handoff después de una tarea larga — es decir, transferir el estado de la tarea a otra persona o a otra sesión de IA;
- convertir un borrador de documentación en una versión utilizable.
Mientras el escenario es simple, una instrucción corta funciona bien.
Pero una tarea de ingeniería repetida acumula detalles rápidamente. Hay que entender la entrada, mantener restricciones, ver riesgos, verificar el resultado y entregar a una persona una respuesta con la que pueda actuar.
Un consejo de skill aparece en el momento en que, dentro de una sola skill, resulta útil nombrar explícitamente distintos tipos de comprobación.
Por qué un prompt grande empieza a estorbar
Un prompt grande suele crecer a partir de reacciones correctas ante errores.
El modelo se apresura a cambiar el código — añadimos una regla: primero entender la tarea.
Pasa por alto un riesgo — añadimos un bloque separado sobre datos, permisos de acceso y compatibilidad.
Escribe una conclusión demasiado general — añadimos el requisito de indicar en qué se basa.
Pierde el tono de la respuesta — añadimos requisitos editoriales.
Todas estas reglas son útiles por separado. La complejidad empieza cuando están todas en un mismo flujo.
El modelo tiene que leer la entrada, planificar la acción, comprobar consecuencias arquitectónicas, buscar riesgos, pensar en pruebas y escribir la respuesta final al mismo tiempo.
Para una tarea pequeña, esto es tolerable.
Para una tarea con varias capas, la respuesta puede verse ordenada, pero el proceso de comprobación queda oculto.
El usuario ve el texto final. Tiene que reconstruir por su cuenta:
- qué hechos consideró fiables la IA;
- dónde vio riesgo;
- por qué una observación pasó a ser bloqueante;
- en qué se basa la conclusión;
- qué quedó como suposición;
- si el cambio puede aceptarse.
Una respuesta así puede ser agradable de leer y, aun así, débil como herramienta de ingeniería.
Cómo funciona el consejo de skill
Desde fuera todo sigue siendo familiar: el usuario se dirige a una sola skill de IA y recibe una única respuesta final.
Dentro, la tarea pasa por varios roles.
| Rol dentro de la skill | De qué se encarga | Cuándo debe detener el trabajo |
|---|---|---|
| Especialista de entrada | Entiende qué se ha recibido: diff, descripción de la tarea, logs, restricciones, datos faltantes | Cuando no hay suficiente contexto para una conclusión fiable |
| Especialista de dominio | Mira el sentido de la tarea en un área concreta | Cuando la solución se aleja del problema original |
| Arquitecto de acción | Elige el orden de trabajo y el cambio mínimo seguro | Cuando el plan toca una zona poco clara |
| Revisor de riesgos | Busca datos, permisos, compatibilidad, acciones irreversibles y consecuencias inesperadas | Cuando hay un riesgo que no puede cerrarse solo con texto |
| Revisor de calidad | Mira pruebas, reproducción, criterios de aceptación y evidencia | Cuando la conclusión no se puede verificar |
| Editor del resultado | Construye la respuesta para que una persona entienda rápido la decisión y el siguiente paso | Cuando una respuesta técnicamente correcta es difícil de aplicar |
Los nombres pueden cambiar según el tipo de tarea.
Para una review de código los acentos son unos. Para un bugfix, otros. Para documentación, otros.
Lo importante es que cada rol haga un trabajo separado: encuentre su propio tipo de problema, tome su propia decisión o añada su propia comprobación.
Para el usuario, el esquema interno solo tiene sentido cuando mejora el resultado. Un consejo de skill mantiene una respuesta final cómoda y añade disciplina: la entrada se analiza, el riesgo se nombra, la verificación queda visible y el resultado se puede usar.
Ejemplo: review de pull request
Tomemos una petición corta: “revisa este PR”.
En una versión débil, la IA devuelve una lista de observaciones:
- Conviene mejorar el nombre de la variable.
- Quizá haga falta una prueba.
- Revisa el manejo de permisos.
- El código puede hacerse más legible.Formalmente, hay una review.
En la práctica, se mezclan cosmética, una posible prueba, un riesgo de permisos y una frase general sobre legibilidad.
El autor del PR todavía tiene que entender por sí mismo qué impide el merge, qué pregunta debe aclararse y qué puntos pueden posponerse.
En un consejo de skill, la misma petición pasa de otra manera.
El especialista de entrada comprueba si hay descripción de la tarea, diff, pruebas y restricciones importantes.
El especialista de dominio mira si el cambio resuelve el problema declarado.
El arquitecto de acción evalúa el alcance: ¿es una corrección local o un cambio de contrato?
El revisor de riesgos busca lugares donde un cambio pequeño pueda afectar a usuarios, datos, permisos o compatibilidad hacia atrás.
El revisor de calidad mira con qué se confirma la conclusión: una prueba, una reproducción, una comprobación manual o solo razonamiento.
El editor arma la respuesta en un formato de trabajo:
Bloqueadores:
- Después de un error de autorización, el código devuelve datos cacheados. Esto puede mostrar al usuario un estado desactualizado o datos a los que ya no tiene acceso.
Preguntas:
- ¿Existe una prueba para el escenario de fallo de autorización?
Sugerencias:
- Separar el fallback para errores técnicos del fallback para denegación de acceso.
Conclusión:
- El PR aún no está listo para merge. Primero hay que manejar explícitamente la denegación de acceso y confirmarlo con una prueba.El valor está en la priorización.
Una observación seria recibe el peso correcto. La incertidumbre se nombra directamente. La persona entiende mejor qué hacer después.
Ejemplo: bugfix
Otra petición frecuente: “aquí está el error, arréglalo”.
Este tipo de petición empuja fácilmente a la IA a buscar enseguida un archivo y proponer una corrección.
A veces funciona.
En el desarrollo real, un bugfix suele empezar antes: hay que entender el síntoma, la reproducción, el entorno, los límites del cambio y la forma de comprobarlo.
En la estructura por roles, el especialista de entrada separa hechos de suposiciones:
- qué ocurrió exactamente;
- dónde está el log;
- qué pasos reproducen el problema;
- qué versión del entorno se usa;
- qué ya se ha comprobado.
El especialista de dominio busca el área probable de la causa.
El arquitecto de acción propone el camino mínimo: dónde mirar, qué cambiar y qué opciones dejar fuera de esta corrección.
El revisor de riesgos hace las preguntas incómodas:
- ¿El cambio afecta datos?
- ¿Hay migraciones?
- ¿Afecta permisos?
- ¿Cambia una API pública?
- ¿Toca tareas en segundo plano?
- ¿Puede crear riesgo en producción?
El revisor de calidad exige un escenario de confirmación: una prueba, un comando, reproducción antes y después, comprobación manual o una nota honesta de que la verificación todavía es limitada.
La respuesta final debe ser corta, pero con contenido:
- cuál fue la causa;
- qué se cambió;
- cómo se verificó;
- qué riesgo queda.
Aquí lo más importante es conservar los pasos que un desarrollador con experiencia normalmente mantiene en la cabeza.
Qué cambia en la práctica
Primer cambio: menos puntos ciegos
Un asistente general suele optimizar hacia el objetivo visible más cercano.
Le piden una review — escribe observaciones.
Le piden un bugfix — propone una corrección.
Le piden un plan — construye una lista de pasos.
La estructura por roles añade antes de actuar varias preguntas obligatorias:
- ¿Qué se sabe?
- ¿Qué no está claro?
- ¿Dónde está el riesgo?
- ¿Cómo se puede verificar el resultado?
Segundo cambio: mejora más fácil
Cuando todo está en un solo prompt, es difícil entender qué se rompió exactamente.
¿Las respuestas se volvieron demasiado secas?
¿Desaparecieron las comprobaciones?
¿Los riesgos se suavizaron demasiado?
¿El modelo empezó a actuar con seguridad cuando faltaban datos?
Cada nueva modificación en el prompt general puede afectar accidentalmente a un comportamiento vecino.
Cuando las zonas de responsabilidad están separadas, el lugar del fallo se ve más rápido.
Si la skill añade hechos no confirmados, reforzamos el trabajo con la entrada y las fuentes.
Si omite riesgos, ajustamos el rol de revisión de riesgos.
Si las conclusiones son difíciles de aplicar, corregimos el armado de la respuesta final.
Si una review se convierte en una lista larga de todo lo posible, cambiamos la priorización de observaciones.
Tercer cambio: crecimiento gradual
Al principio puede tener solo un ejecutor y un formato simple de respuesta.
Luego aparece la comprobación de entrada.
Luego una revisión de riesgos separada.
Luego calidad y evidencia.
Luego un editor del resultado.
Los nuevos roles aparecen allí donde una tarea repetida ya exige una responsabilidad separada.
Ese crecimiento es más claro que intentar escribir desde el principio el prompt perfecto para todos los casos.
Cuándo merece la pena usarlo
Este enfoque compensa cuando una tarea tiene varias capas de responsabilidad.
Buenos candidatos
- una decisión antes de merge;
- un bug con causa poco clara;
- un cambio en una API pública;
- una revisión de release;
- una tarea con datos de usuarios;
- un handoff después de un trabajo largo;
- una review de material que se publicará fuera.
Para tareas pequeñas, una estructura por roles será peso innecesario.
Recordar un comando de Git, explicar un error de compilación, corregir una frase o esbozar un ejemplo corto de código suele ser más rápido con una petición normal.
Otro riesgo: roles por tener roles
Si cada “especialista” escribe lo mismo, el usuario recibe ruido.
Si la respuesta final se convierte en una discusión larga, la skill estorba.
Cada rol debe encontrar un tipo separado de problema o tomar una decisión práctica separada.
Cómo probarlo sin una herramienta aparte
El experimento más simple se puede hacer directamente en un chat.
Si tu prompt de trabajo ya se convirtió en una pared de reglas, prueba primero a separar un solo rol: comprobación de entrada o revisión de riesgos.
Toma un escenario repetido, por ejemplo review de PR o análisis de bug, y pide a la IA que recorra la tarea por roles:
Analiza la tarea como un consejo de skill dentro de una sola skill de IA:
1. Entrada: qué se sabe y qué falta.
2. Comportamiento: qué cambia para el sistema o el usuario.
3. Riesgos: qué puede romperse o requerir cautela.
4. Verificación: con qué confirmar la conclusión.
5. Resultado: bloqueadores, preguntas, sugerencias, conclusión.Después de varias ejecuciones, se verá dónde falla más a menudo la IA.
Si inventa hechos faltantes, hace falta un trabajo más estricto con la entrada.
Si escribe una conclusión pulida sin verificación, hace falta un rol de calidad.
Si mezcla observaciones bloqueantes y sugerencias opcionales, hace falta una priorización separada.
Si la respuesta es difícil de leer, hace falta un editor del resultado.
Cuando el escenario se repite con regularidad, esta estructura puede formalizarse como una skill de IA estable.
Qué saqué de esta experiencia
El consejo de skill me ayudó a detener el engorde infinito de un solo prompt.
En lugar de añadir cada vez más reglas a un texto general, empecé a separar responsabilidades:
- quién entiende la entrada;
- quién mira la parte de dominio;
- quién elige el orden de acción;
- quién busca riesgo;
- quién controla calidad;
- quién arma la respuesta.
La IA sigue equivocándose.
La responsabilidad sigue siendo humana.
Pero la skill empieza a comportarse de forma más tranquila y comprensible: detrás del texto seguro aparecen comprobaciones de trabajo visibles.
En desarrollo esto es especialmente importante.
Un buen resultado rara vez se reduce aquí a una sola respuesta correcta. Importa el camino: qué se consideró un hecho, dónde estaba el riesgo, con qué se confirmó la conclusión y qué decisión debe tomar la persona.
Las skills de IA útiles para trabajo de ingeniería, en mi opinión, avanzarán precisamente en esta dirección: de la esperanza en un prompt perfecto a una distribución clara de responsabilidad dentro de la herramienta.
Me interesa saber cómo resuelven ustedes un problema parecido en su propio trabajo.
