IA Ingenieria & MLOps Meta-Skill Referencia Avanzado

Descubrimiento e Invocación de Skills de Agente

Árbol de decisión + ciclo de vida completo para ingeniería de software con agentes IA

NeuralBridge SaaS
4 devs · ARR 280k€ · Sprint 3 sem.
Panel Observabilidad Agentes
Árbol de Decisión — ¿Qué skill aplicar?
¿No sabes qué quieres exactamente? interview-me
Concepto vago, necesitas variantes idea-refine
Nuevo proyecto / feature / cambio spec-driven-development
Tienes spec, necesitas tareas planning-and-task-breakdown
Implementando código incremental-implementation
UI → frontend-ui-engineering
API → api-and-interface-design
Código de alto riesgo → doubt-driven-development
Escribiendo / ejecutando tests test-driven-development
Algo se rompió debugging-and-error-recovery
Revisando código code-review-and-quality
Muy complejo → code-simplification
Seguridad → security-and-hardening
Añadiendo logs / métricas / alertas observability-and-instrumentation
Desplegando / lanzando shipping-and-launch
Ciclo de Vida Completo — Secuencia de Skills
1
interview-me
Extraer lo que el usuario realmente quiere
2
idea-refine
Refinar ideas vagas con divergencia/convergencia
3
spec-driven-development ⭐
Definir qué construimos — CRÍTICO para NeuralBridge
4
planning-and-task-breakdown
Descomponer en chunks verificables (sprint 3 sem.)
5-9
incremental-implementation
+ context-engineering + source-driven + doubt-driven
8P
observability-and-instrumentation
Paralelo con build — instrumentar desde el inicio
10
test-driven-development
TDD adaptado a agentes async (falla primero)
11
code-review-and-quality
5 ejes de revisión antes del merge
12
code-simplification
Reducir complejidad preservando comportamiento
13-16
git-workflow → ci-cd → docs → shipping-and-launch
Commits atómicos, gates automáticos, lanzamiento seguro
🧭 Ruta recomendada para NeuralBridge — Panel de Observabilidad de Agentes (sprint 3 semanas)
interview-me
spec-driven-development
planning-and-task-breakdown
source-driven-development
incremental-implementation
observability-and-instrumentation
test-driven-development
doubt-driven-development
shipping-and-launch
Decisiones clave: La duda SSE vs WebSockets debe resolverse en spec-driven-development antes de tocar código (no durante la implementación). La deuda técnica en la API actual NO se toca sin aprobación explícita — scope discipline. El TDD para agentes async usa mocks de eventos antes de conectar el sistema real.
6 Comportamientos Base No Negociables
1
Aflorar Supuestos
Antes de implementar, declara explícitamente tus asunciones.
"Asumo SSE. ¿Correcto o usamos WS?"
2
Gestionar Confusión
STOP ante inconsistencias. Nombra la confusion, presenta el tradeoff.
"Spec dice X, código dice Y. ¿Cuál manda?"
3
Rebatir si Procede
No eres una máquina de «sí». Señala problemas con cuantificación.
"Esto añade ~200ms de latencia. Propongo alternativa."
4
Aplicar Simplicidad
Pregunta: ¿puede hacerse en menos líneas? ¿Las abstracciones se justifican?
1000 líneas cuando 100 bastan = fracaso
5
Disciplina de Alcance
Toca solo lo que te piden. Precisión quirúrgica, no renovación no solicitada.
No «limpiar» código adyacente sin permiso
6
Verificar Siempre
Una tarea no está completa hasta que pase la verificación. «Parece correcto» no basta.
Tests en verde + build output = evidencia
10 Modos de Fallo a Evitar
# Fallo Consecuencia
1 Asumir sin verificar Retrabajo masivo
2 Avanzar confundido Bug sistemático
3 Silenciar inconsistencias Deuda técnica oculta
4 No presentar tradeoffs Decisiones sin info
5 Sycophancy ("¡Por supuesto!") Mala idea ejecutada
6 Sobrecomplicar código Mantenimiento imposible
7 Modificar código ortogonal Bugs no relacionados
8 Eliminar sin entender Pérdida de funcionalidad
9 Construir sin spec Entregar lo incorrecto
10 Saltar verificación Roto en producción