El Squad Starter Pack, equipar a un equipo para trabajar con la IA
Un conjunto de archivos y de skills puestos en el repositorio del
equipo le da a la IA el contexto que necesita, de forma duradera,
compartida entre sesiones y entre personas. Cuatro fundaciones primero,
extensiones contextuales después, y un self-check que dice dónde está
el equipo y por dónde empezar. El objetivo no es la conformidad: es
crear las condiciones para que la IA sea realmente útil, de forma
duradera y colectiva.
Problema abordado
Cuando un equipo trabaja con un agente de código, la calidad de lo que
sale depende directamente de lo que el agente sabe del proyecto. Sin
contexto estructurado, improvisa: no conoce ni las reglas del design
system, ni las convenciones de código, ni quién es dueño de qué. Cada
persona vuelve a dar el brief en cada sesión, cada una a su manera, y
la IA produce rápido algo que nadie puede mantener.
Pasos
El método en 6 pasos
Paso 1
Poner la memoria de sesión
Un archivo de instrucciones en la raíz del repositorio: el mapa del proyecto, las convenciones git, los patrones, las zonas sensibles. Se carga automáticamente en cada sesión, así que cada línea debe merecer su lugar: 200 líneas máximo.
Paso 2
Escribir lo que la IA no puede inferir del código
Un documento de producto: por qué existe este producto, quién lo usa, qué reglas gobiernan las decisiones, qué queda fuera del perímetro. Fuente única para todos los usos de IA del equipo. Le pertenece al PM.
Paso 3
Gobernar el design system
Un documento de diseño: qué sistema, qué jerarquía (el componente del sistema primero, el custom justificado después), qué nivel de madurez, qué desviaciones asumidas. No un dump de tokens: lo que hay que usar, y por qué. Le pertenece al diseñador.
Paso 4
Instalar el gate de calidad
Una review que corre en contexto aislado, sin el sesgo de la sesión que produjo el código: ejecuta los tests, confronta el diff con las reglas escritas, y da un veredicto. Aprobado o bloqueado, antes de cada commit.
Paso 5
Extender según el contexto
Colaboradores IA especializados por rol (review de framework, arquitectura, seguridad), la automatización del ciclo de ticket a PR, una auditoría de seguridad dedicada sobre los diffs, un observador silencioso que registra la deuda. Opcionales: reflejan la madurez de cada equipo, no un estándar impuesto.
Paso 6
Medirse, luego priorizar
El self-check evalúa cada dimensión, produce un puntaje y tres acciones prioritarias. Los criterios se cargan en cada ejecución desde su fuente viva: el marco evoluciona sin necesidad de reinstalar nada. Se mide para saber por dónde empezar, no para ponerse una nota.
Condiciones de éxito
Lo que indica que funciona
Covalidación entre producto y tech desde el inicio: un pack impuesto por una sola función no sobrevive al primer desacuerdo
Archivos cortos donde cada línea merece su lugar, en vez de una documentación exhaustiva que nadie va a cargar
Una instanciación adaptada a la madurez de cada equipo: las fundaciones primero, las extensiones cuando la necesidad existe
Un marco vivo: los criterios del self-check evolucionan sin que los equipos tengan que reinstalar nada
Contraindicaciones
Cuándo no usarlo
×
Apuntar al puntaje en lugar del uso: un 8/8 de conformidad no produce nada si el equipo no trabaja realmente con la IA
×
Instalarlo todo de una vez: las extensiones sin las fundaciones dan una tubería sofisticada sobre un contexto vacío
×
Un equipo sin design system utilizable: la IA lo revela de inmediato, y eso hay que resolverlo primero
Ejemplos de aplicación
Donde el método ha vivido
Nació en la reconstrucción de un portal de producto, donde el sistema completo se construyó y se puso a prueba durante cuatro meses de design-to-code dirigido
El repositorio de referencia alcanza el puntaje completo del marco, y el reporte de orquestación documenta lo que el sistema hizo posible
Instanciado después en varios otros equipos, cada uno evaluado y luego equipado según su madurez, de las fundaciones hacia las extensiones
La adopción se está extendiendo: el marco común permite comparar las progresiones sin imponer un ritmo único
Diagnóstico
Haz tu diagnóstico
Antes de desplegar el método, más vale saber dónde está tu squad. Responde a las seis condiciones, la puntuación se calcula en directo. El playground es el resultado cuando la puntuación lo permite, no un entregable para copiar tal cual.
Para ir más lejos
La versión corta de la historia: este pack no se diseñó como un framework, se extrajo de una obra en marcha. Durante la reconstrucción de un portal de producto en design-to-code, cada salvaguarda se puso en respuesta a un problema real, desde el falso arranque inicial (demasiado contexto inyectado de una sola vez, la IA improvisando) hasta el sistema de tres capas que se sostiene sin vigilancia manual. El relato completo de esa obra, con cifras incluidas, está en la nota Dirigir la IA, no programar en su lugar.
Lo que cambió después es el paso de “mi práctica” a “nuestro equipamiento”. La versión compartida del pack fue covalidada con producto y con tech, precisamente para que no fuera un estándar de diseñador impuesto a las otras funciones. Cada dimensión tiene un owner natural: el archivo de producto le pertenece al PM, el documento de diseño al diseñador, las convenciones a la tech. Esa copropiedad es lo que sostiene el conjunto.
Desde el verano de 2026, el pack vive su verdadera prueba: su creadora se fue, el marco y las instancias quedan. Es exactamente para eso que fue diseñado.
El marco completo está en esta página, a propósito: un método de enablement que se esconde no habilita a nadie. Lo que queda privado es la instanciación interna, los archivos reales y los puntajes de los equipos. Si quieren ver cómo se ve un pack instalado en un repositorio de verdad, pregunten: se muestra en vivo, con gusto.
Madurez
consolidated
Tags
enablement · claude-code · gouvernance · design-to-code · equipe
Última actualización
Escrito con terquedad colombiana, en el sur de Francia.