El sistema ya está montado. Ahora úsalo.
Saber qué es un CLAUDE.md o una skill no es suficiente. Lo que marca la diferencia es integrar el agente en el ritmo real del equipo — no como una herramienta que se abre a veces, sino como parte del flujo de cada tarea.
Los tres momentos del día
Tres puntos de contacto diarios con el agente. Ni más ni menos.
Al empezar
~5 minutos“Resume el estado del sprint y dime en qué debería enfocarme hoy.”
El agente lee el CLAUDE.md, el decisions-log y el sprint actual. Te da un resumen de 3 líneas.
“¿Qué cambió en el design system desde la última vez que revisamos tokens?”
Lee tokens.md y el historial de cambios. Útil antes de una sesión de diseño.
Durante el trabajo
Integrado en cada tarea“Audita este componente contra nuestro design system y dame los hallazgos en tabla.”
Usa la skill component-audit. Lee components.md y tokens.md. Output estructurado en 90 segundos.
“Genera la spec de entrega del flujo de pago para el equipo de desarrollo.”
Usa la skill handoff-spec. Produce el documento completo siguiendo el formato acordado.
“¿Esta decisión de diseño contradice algo que hayamos decidido antes?”
Lee decisions-log.md. Si hay conflicto, lo señala con contexto y alternativas.
Al cerrar
~5 minutos“Registra esta decisión en el decisions-log con el contexto de hoy.”
Actualiza decisions-log.md con formato consistente. El sistema crece con el proyecto.
“¿Hay algo en el CLAUDE.md que debería actualizar tras lo de hoy?”
El agente revisa si algo del trabajo del día cambia las reglas o el contexto permanente.
El ciclo de una tarea
Cada tarea sigue un flujo de 5 pasos. El resultado depende del paso 2 — no del prompt.
01 — Prompt
El diseñador escribeEl diseñador escribe la tarea. Describe qué quiere, no cómo hacerlo ni el contexto del proyecto.
02 — Contexto
El agente cargaEl agente carga lo que necesita: CLAUDE.md, docs de referencia y la skill que encaja con la tarea.
03 — Output
Formato de la skillEl agente genera el output en el formato definido en la skill. Estructurado, predecible, reproducible.
04 — Revisión
El diseñador decideEl diseñador revisa y decide: ¿el output es correcto? Si sí, tarea cerrada. Si no, se corrige el contexto.
05 — Decisión
El bucle se cierraSi el output es correcto → Tarea cerrada
Si no → Corrige el contexto, no el output
CLAUDE.md, docs/ o skill — luego vuelve al paso 02.
Insight clave
Cuando el output no es bueno, el problema casi siempre está en el paso 2 — el contexto. Mejora el CLAUDE.md o la skill, no el prompt.
Mantener el sistema vivo
El sistema es tan bueno como el último día que alguien lo actualizó. Tres momentos para mantenerlo al día.
Actualiza el CLAUDE.md cuando...
- Cambia el stack o las herramientas del proyecto
- El equipo toma una decisión que afecta a todos
- Empieza un sprint nuevo con foco diferente
- El agente improvisa algo que debería estar definido
Crea un documento nuevo cuando...
- Hay información extensa que el agente consulta a menudo
- Añades nuevos arquetipos de usuario
- El design system crece con nuevos patrones o tokens
- Acumulas decisiones que necesitan trazabilidad
Crea una skill nueva cuando...
- Repites el mismo tipo de tarea más de 3 veces
- El output varía entre diseñadores para la misma tarea
- Un proceso tiene pasos fijos que siempre se olvidan
- Quieres que un junior produzca outputs de senior
Señales de que algo no funciona
Cuatro señales de alarma que indican que el sistema necesita atención.
El agente improvisa
Inventa nombres de tokens, supone arquetipos, propone componentes que no existen en el sistema.
Causa probable: falta de contexto en CLAUDE.md o docs desactualizados.
Outputs inconsistentes
Dos diseñadores piden lo mismo y reciben formatos distintos. No hay forma de comparar resultados.
Causa probable: no existe skill para esa tarea o la skill no define el formato de salida.
El equipo deja de usarlo
Los diseñadores vuelven a ChatGPT o a hacer las cosas manualmente. El agente “no ayuda”.
Causa probable: el CLAUDE.md está desactualizado o las skills no reflejan el trabajo real.
Los prompts son cada vez más largos
El diseñador tiene que explicar el proyecto entero en cada prompt para que el agente entienda el contexto.
Causa probable: ese contexto debería estar en CLAUDE.md o en un documento de referencia.
La regla de oro
Si tienes que explicar el proyecto cada vez que abres Claude Code, el sistema no está funcionando.
Un buen setup significa que el agente ya sabe quién eres, qué estás construyendo, qué restricciones tiene el proyecto y cómo quieres los resultados. El prompt del diseñador debería describir la tarea, no el contexto.
Si el contexto cambia cada semana y el CLAUDE.md no — ahí está el problema. El sistema es tan bueno como el último día que alguien lo actualizó.
El CLAUDE.md refleja el estado actual del proyecto
Los docs de referencia se actualizan cuando cambia algo
Las skills cubren las tareas repetidas del equipo
El equipo no necesita prompts largos para tareas habituales