HusDev/preferences-logger

Registro de preferencias

Las personas toman docenas de pequeñas decisiones mientras trabajan con un asistente: un color, una librería, una regla de nombrado, «no hagas X», «opción B». La mayoría nunca se escriben, así que la siguiente sesión vuelve a preguntar o las deshace silenciosamente. Este skill mantiene un único archivo, PREFERENCES.md, que registra cada decisión en el momento en que se toma, de modo que se mantenga entre sesiones, herramientas y colaboradores.

Cuándo actuar

Lee PREFERENCES.md antes de hacer tu primer cambio en un proyecto que lo tenga, y de nuevo antes de proponer diseños, opciones o cualquier cosa que el archivo ya pueda haber decidido. Sigue lo que dice. No preguntes de nuevo sobre algo que ya registra a menos que el usuario lo mencione.

Escribe en él en el mismo turno que el trabajo cada vez que el usuario:

• exprese una preferencia o regla («prefiero tabs», «usa siempre la ortografía británica», «nunca hagas commit a main»);
• elija entre opciones que le ofreciste («A», «vamos con la segunda», «mezcla A y C»);
• corrija o rechace cómo se hizo algo («esto se ve mal», «no, ponlo a la derecha», «eso está mal, solo cuando…»), siempre que la corrección indique cómo debería ser;
• cambie o revierta una decisión anterior;
• pruebe algo tentativamente («probemos esto»): regístralo marcándolo como prueba.

No registres:

• instrucciones puntuales que solo aplican a la tarea actual («renombra esta variable»);
• hechos que el código o el historial ya contienen (distribución de archivos, qué librería está instalada);
• secretos, credenciales, tokens o datos personales de nadie (direcciones, números de identificación, salud). Registra la decisión, no el valor privado: «usa el nombre real del usuario en el pie de página», nunca el nombre mismo si es sensible;
• tus propias sugerencias que el usuario no ha aceptado.

Si no estás seguro de si algo es una decisión duradera, regístralo: una línea extra corta cuesta menos que una elección olvidada.

Dónde vive el archivo

PREFERENCES.md en la raíz del proyecto, a menos que las instrucciones del agente del proyecto (CLAUDE.md, AGENTS.md o similar) nombren otra ruta. Sin proyecto (una charla puntual), no crees un archivo; solo sigue lo que el usuario diga.

Si aún no hay archivo, créalo a partir de templates/PREFERENCES.md (junto a este archivo) con la primera decisión. Luego, si el proyecto tiene un CLAUDE.md o AGENTS.md, añade una línea cerca del inicio para que cada futura sesión lo lea:

Lee PREFERENCES.md primero y mantenlo actualizado: cada vez que se tome o cambie una decisión, edita su línea y añade una entrada fechada en el registro de cambios, en el mismo turno.

El formato

# <Proyecto> — decisiones

Una línea sobre qué es este archivo.

## <Tema>
- **<Nombre corto de la decisión>:** lo que se decidió, en palabras simples. Por qué, cuando el usuario dijo por qué. (Anteriormente: lo que reemplazó, y cuándo.)

## Registro de cambios
- 17 Oct 2026 — <lo que se decidió o cambió, en una línea> (sus palabras: «…»).

Reglas para mantenerlo útil:

1. Una línea por decisión, agrupada por tema. Elige temas que se ajusten al proyecto (Producto, Diseño, Stack, Flujo de trabajo, Escritura, …). Empieza con pocos y añade uno cuando una decisión no encaje en ninguno.
2. Edita en el lugar. Cuando una decisión cambie, reescribe su línea para reflejar lo que ahora es válido y conserva la elección anterior en una breve nota «Anteriormente: …». Nunca dejes dos líneas que se contradigan.
3. Añade una entrada en el registro de cambios para cada modificación, la más nueva al final, con una fecha absoluta («17 Oct 2026», nunca «hoy» o «ayer»). Convierte las fechas relativas cuando las escribas.
4. Conserva las palabras del usuario para la parte importante, citadas y breves: fijan lo que se quiso decir más adelante. No pongas palabras en su boca ni hagas que un comentario suene más fuerte de lo que fue.
5. Di por qué cuando el usuario haya dado una razón. Una razón permite que una sesión posterior maneje un caso que la regla no previó.
6. Enlaza a lo que apunta la decisión: un diseño, un issue, un mockup, un commit.
7. Marca las pruebas y lo desconocido: «(probando esto)», «(no definitivo)». Quita la marca cuando se confirme.
8. Escribe con claridad. Frases cortas, sin jerga que el usuario no haya usado. Usa el nombre de la persona o «elle» a menos que haya indicado qué pronombres usar; no adivines a partir de un nombre.

Cuando una petición entra en conflicto con el archivo

La declaración explícita más reciente prevalece. Si el usuario ahora pide algo que el archivo descarta, haz lo que pide y actualiza la línea y el registro de cambios. Si es ambiguo si tenía la intención de cambiar la regla, pregunta en una pregunta corta, citando la línea registrada.

Informa al usuario brevemente

Después de actualizar el archivo, menciónalo en una cláusula corta al final de tu respuesta («Lo registré en PREFERENCES.md»), no un resumen del archivo. Muestra el archivo completo solo cuando te lo pidan.

Ejemplo

El usuario elige entre tres diseños de barra lateral que le mostraste y responde «A, pero los botones deberían ser iconos». En el mismo turno en que lo construyes:

## Diseño
- **Barra lateral:** menú compacto; la lista de carpetas llena la altura restante y se desplaza; Configuración y el interruptor de privacidad son botones de icono en una fila inferior (se eligió A de las tres opciones, con botones de icono).

## Registro de cambios
- 17 Oct 2026 — Barra lateral: opción A, con las acciones inferiores como botones de icono (sus palabras: «A, pero los botones deberían ser iconos»).

Una semana después el usuario dice «ponle las etiquetas de nuevo a esos botones»:

- **Barra lateral:** … Configuración y el interruptor de privacidad son botones con etiquetas en una fila inferior. (Anteriormente: solo iconos, 17 Oct 2026.)

- 24 Oct 2026 — Los botones inferiores de la barra lateral recuperan sus etiquetas (sus palabras: «ponle las etiquetas de nuevo a esos botones»).