Cómo usamos Claude Code en SCRAM todos los días: el repo como memoria, skills propios y reglas que no se negocian

¿Para qué usamos Claude Code en SCRAM?

Para operar un sistema, no para escribir funciones sueltas. La plataforma que corre scram2k.com, el ERP, el CRM, la logística y el asistente Nemi tiene, al 8 de septiembre de 2026, 127 modelos de datos, 655 endpoints en 93 controladores, 31 crons y 66 pantallas en el portal de administración. La contamos con comandos, no de memoria; el inventario está en el repositorio con el comando al lado de cada cifra. Con un equipo chico, la única forma de sostener eso es que el agente que programa tenga la misma memoria que nosotros y las mismas reglas.

Este artículo es la receta tal como está montada hoy, incluyendo lo que salió mal. Si buscas "diez prompts para Claude Code", no es aquí.

¿Dónde vive la memoria del agente?

En el repositorio y en archivos de memoria por proyecto, nunca en la conversación. Tres capas:

Capa	Qué guarda	Quién la escribe	Ejemplo real
CLAUDE.md del repo	Stack, convenciones, cómo se despliega, voz de marca del chatbot	Personas	"No usar transition: all"; "verificar deploy con .deployed-sha, nunca con gh run list"
Memoria por proyecto (un archivo por hecho)	Decisiones cerradas, trampas verificadas, cifras con fecha	El agente, al cerrar cada sesión	"El servicio api del compose no lee env_file: la variable va también en el compose del repo"
Grafo del código (graphify)	Quién llama a qué, dónde se define una ruta	Hook post-commit	Reconstruye en segundo plano después de cada commit

La regla de oro de la memoria: se guarda lo que no se puede derivar del código. Que existe un servicio de cotizaciones lo dice el código. Que ese servicio manda el PDF al cliente cuando cambias el estado a "enviada", y que por eso el bot pide segunda confirmación antes de convertir a pedido, eso lo dice la memoria, porque lo descubrimos leyendo dos líneas de un servicio y nos costó una tarde.

¿Qué skills escribimos y por qué desde el código?

Un skill es un procedimiento que el agente sigue cuando la tarea encaja. Tenemos más de 60 instalados, la mayoría genéricos. Los tres que más valor dan son los que escribimos nosotros a partir de código que ya funcionaba en producción:

• Nueva herramienta de agente (/nueva-herramienta-agente): crea una herramienta de datos para el registro de Nemi con su candado por nivel de rol, reglas de negocio verificadas contra los datos y pruebas. Nació después de que una consulta de ventas agrupara por el campo equivocado y diera una cifra 3.7 veces mayor para una persona; la regla "agrupar por ownerId, nunca por sellerName" vive ahí.
• Crear MCP de un sistema propio: siete principios y 24 trampas, extraídos del servidor MCP de SCRAM. Lo usamos para no repetir cuatro despliegues fallidos cuando toque exponer otro sistema.
• Documentar proyecto: levantó en un día el paquete formal de la plataforma: 39 diagramas, 88 requerimientos funcionales, 95 reglas de negocio con ruta de archivo, una matriz de 238 casos de prueba y 16 videotutoriales con narración. Los 39 diagramas se validaron levantando un navegador por diagrama, porque la herramienta oficial de línea de comandos se rompía al instalarse.

El patrón es el mismo en los tres: primero se resuelve el problema a mano, con errores; después se destila en un skill con lo que sí funcionó y lo que no. Un skill escrito antes de tener el código funcionando es teoría.

Las tres reglas que aprendimos en producción

1. Lo que se puede decidir en código no se le pregunta al modelo. La función de "corregir el conocimiento" del asistente falló dos veces seguidas en producción con el prompt correcto desplegado y verificado dentro del contenedor. Detectar la intención con una expresión regular antes de llamar al modelo la resolvió al primer intento. Desde entonces, la confirmación de cualquier escritura es un flujo de dos turnos en código, con la propuesta guardada en Redis diez minutos, y no una frase del prompt que dice "pide confirmación".
2. Verificar contando filas, no leyendo la respuesta del bot. Cuando Nemi creó su primera tarea en el CRM, la prueba fue 153 filas antes, 153 al proponer, 154 al confirmar, 154 al reconfirmar, y ninguna sin sesión. Un "listo, ya lo creé" del modelo no es evidencia de nada.
3. Pedir el error del cliente antes de teorizar. El servidor de autorización del MCP falló con cero tráfico en el servidor. Perseguimos dos hipótesis falsas antes de mirar la consola del navegador, donde una política de seguridad del formulario de login lo explicaba en un renglón. Cero tráfico no es "credencial equivocada"; es "la petición nunca llegó".

¿Cómo controlamos el costo con Fable 5.1 como modelo por defecto?

Desde la versión 2.1.257 de Claude Code (1 de septiembre de 2026), Fable 5.1 es el modelo por defecto, a $10 de entrada y $50 de salida por millón de tokens. Nosotros no lo dejamos suelto. Tres ajustes que hicimos la primera semana de septiembre:

• modelPicker con una lista curada: Opus 5 para el trabajo diario, Fable 5.1 para refactorizaciones grandes y para las sesiones de diagnóstico en producción.
• Un hook PreModelSwitch que pide confirmación antes de subir a Fable. Cuesta un clic y evita que una sesión larga se vaya a la tarifa alta por inercia.
• /skill-doctor una vez: 14 skills sin uso en el trimestre consumían cerca de 9,000 tokens de contexto por sesión solo por estar listados. Fuera.

Lo que no medimos todavía, y lo decimos: no tenemos la cifra de cuánto bajó la factura mensual con estos ajustes. Tenemos el gasto por sesión, que sí bajó en el primer turno, y publicaremos el mes completo cuando cierre septiembre.

Un ejemplo de punta a punta: la mascota

Nemi, el mapache que atiende en scram2k.com, no es una animación comprada: es un SVG dibujado y animado en código, con resortes, una máquina de estados y una línea de tiempo por gesto, hecho con Claude Code en el widget del chat. La cabeza se vectorizó por contorno desde una ilustración de referencia con un script en Python de 130 líneas que escribió el agente; el cuerpo heredó la construcción del jaguar anterior. Cada versión se revisó con capturas antes de publicarse, y hubo siete rechazadas antes de la que está en producción. La lección no es de dibujo: el agente propone, la persona aprueba viendo el resultado, y nada se publica sin esa vista. Es la misma regla que aplicamos al CRM.

Qué haríamos distinto

Empezar antes con la memoria por proyecto. Los primeros meses las lecciones vivían en las conversaciones y se perdían al cerrarlas; cada sesión nueva volvía a tropezar con el mismo compose que no lee variables. Y escribir los skills después del tercer uso, no del primero: dos de los que hicimos temprano quedaron obsoletos en semanas porque describían una solución que aún estaba cambiando.

Si operas un sistema con un equipo chico y un agente de código, la pregunta correcta no es "qué modelo uso". Es "qué recuerda el agente cuando cierro la ventana". Todo lo demás se deriva de ahí.