craft, el plugin de Claude Code que guarda tu diseño entre sesiones
Un plugin open source para Claude Code convierte cada decisión de diseño aceptada en un registro en disco que la siguiente sesión lee antes de generar nada. No entrena al modelo: le deja recibos.
Un desarrollador ha publicado craft, un plugin para Claude Code que guarda en disco las decisiones de diseño de un proyecto para que la sesión siguiente no arranque de cero. La premisa es explícita: no hay ningún modelo entrenado con los gustos de nadie, hay un fichero que sobrevive a la conversación. El código está en el repositorio.
El problema que ataca lo reconoce cualquiera que trabaje con un agente de código: cada sesión empieza sin memoria y obliga a volver a decidir lo mismo. craft lo ataca escribiendo registros. Cuando el usuario acepta un ajuste, el valor cae en un fichero llamado tokens.yaml, y el siguiente mockup lo carga antes de proponer una sola opción. Quien lo mantiene cuenta que aceptó un cambio en una tarjeta de portada con una única frase de aprobación y de ahí salieron once registros enlazados entre sí; el marco y la insignia de esa tarjeta acabaron en el sistema de diseño porque le gustaban, no porque hubiera redactado una guía de estilo previa. Dice usarlo ya en 39 proyectos.
Requisitos e instalación
Hace falta Claude Code 2.1 o superior. Está probado en macOS y Linux; en Windows el autor recomienda tirar de WSL. La instalación se hace desde la propia sesión: se añade el marketplace del proyecto y se instala el plugin, y después se recarga para que aparezca. La verificación es ejecutar /craft y comprobar que sale el prompt de entrada; si no aparece, toca revisar en /plugin que el marketplace figure con el plugin instalado.
A partir de ahí el flujo es el de siempre: pedirle a Claude que ajuste, por ejemplo, las animaciones del hero de la portada, elegir una opción y aplicarla, momento en el que el plugin registra el cambio por su cuenta, o generar un mockup nuevo con /craft:mockup. Todo lo aceptado va engordando el repositorio de gusto de ese usuario.
El enfoque es el contrario a afinar un modelo o a confiar en la memoria de la herramienta: saca el estado de la conversación y lo pone en el sistema de ficheros del proyecto, donde se puede leer, versionar y revisar. Para un equipo eso cambia la pregunta de dónde vive el criterio de diseño, aunque también plantea cómo se fusionan los tokens.yaml de varias personas cuando cada una acepta ajustes distintos. Los números y el flujo son del autor; no hay demo pública ni validación de terceros, y el proyecto es joven. Lo que sí se puede comprobar hoy es si el plugin resuelve el arranque en frío en un repo propio.