# Las reglas de la casa

La segunda capa. Los datos dicen qué existe; las reglas dicen cómo se trabaja
con ellos. Es el archivo que el agente lee antes que cualquier otra cosa, en
cada conversación, sin que tú se lo pidas.

Guárdalo con el nombre que use tu herramienta: algunas leen `AGENTS.md`, otras
`CLAUDE.md`, otras lo toman como instrucciones del proyecto. El contenido es el
mismo.

## Un archivo raíz corto, apéndices por dominio

El archivo de reglas crece solo. Empiezas con diez líneas sobre dónde guardar
las cosas y a los tres meses tienes las reglas de escritura comercial, las de
código, las de la máquina donde corre todo y las de tu tono, todas juntas en un
documento que se lee entero para responder cualquier pregunta. Se paga en
costo, en atención repartida y en reglas que el agente deja de cumplir porque
compiten con otras cincuenta.

La forma que aguanta es partirlo en dos niveles:

**El archivo raíz** tiene lo que aplica siempre, sin importar el pedido: cómo
se comporta, qué no inventa, cómo escribe, qué necesita confirmación. Corto, a
propósito.

**Los apéndices** tienen lo que aplica a un dominio. Uno para trabajo
comercial, uno para trabajo técnico, uno para el tono con el que te responde,
uno para la máquina y los servicios, uno para cuando reparte trabajo entre
varios agentes. Cada uno vive en su archivo y se carga solo cuando el pedido lo
toca.

Arriba de todo, la instrucción que hace que el mecanismo funcione:

```markdown
## Primer paso de cada turno

- Clasifica el pedido antes de actuar.
- Lee todos los apéndices que apliquen antes de responder, editar o ejecutar.
  Un pedido que cruza dos dominios carga los dos.
- Las reglas cargadas siguen activas todo el turno.
- Si el pedido cambia a mitad de conversación, vuelve a clasificar y carga lo
  que falte.
```

Y después la tabla de a qué apéndice manda cada tipo de pedido, escrita con las
palabras que tú realmente usas. Si pides "arma la propuesta", la tabla tiene
que reaccionar a esa frase, no a "generación de documentos comerciales".

## Qué va en el raíz

Lo que no depende del dominio. Cinco bloques cubren casi todo:

**Comportamiento.** Hacer exactamente lo pedido y no agregar limpieza, archivos
ni trabajo de más. No inventar abstracciones. Si el pedido es un consejo, no
empezar a ejecutar. Y una que ahorra semanas: cuando el usuario corrige algo,
esa corrección vale para el resto de la sesión, no para ese mensaje.

**Verdad y evidencia.** Nunca inventar cifras, fuentes, archivos, resultados ni
estado de un sistema. No presentar una inferencia como un hecho. No declarar
una causa raíz antes de una comprobación que la pudiera desmentir. Cuando no se
verificó, decirlo y nombrar qué falta.

**Comunicación.** Directo y compacto. Decir cada cosa una vez. Nombrar las
contradicciones y lo que falta en vez de rellenar. No repetir la pregunta antes
de responderla. La respuesta larga es para la tarea larga.

**Fuente de verdad.** Cuál manda cuando dos documentos dicen cosas distintas:
el pedido, las reglas, el contrato de datos, lo que el sistema hace de verdad.
Y qué se hace cuando se contradicen, que es detenerse y decirlo, no elegir la
lectura conveniente.

**Verificación.** No declarar algo listo, arreglado o publicado sin haber
comprobado esa afirmación exacta. Usar la comprobación más chica que pueda
desmentirla.

## Cómo se escribe una regla que se cumple

Una regla útil tiene un gatillo, una acción y un límite. "Sé cuidadoso con los
datos del cliente" no tiene ninguno de los tres y no cambia nada. Compara:

> Antes de una acción difícil de revertir (enviar, publicar, borrar, firmar),
> propone y espera confirmación explícita en ese momento. Un plan aprobado
> antes no es autorización.

Esa se cumple porque dice cuándo aplica, qué hacer y dónde termina la
autorización previa. Tres más que rinden desde el primer día:

> Si un dato falta o dice pendiente, se pregunta. No se completa con un valor
> parecido de otro cliente ni con una estimación.

> Haz una pregunta a la vez y espera la respuesta. No juntes cuatro preguntas
> al final de un texto largo.

> Después de dos intentos fallidos con el mismo enfoque, detente. Reporta qué
> falló, qué probaste y dos alternativas. No apliques un rodeo sin aprobación.

La tercera es la que más tiempo salva. Un agente sin ese límite prueba
variaciones cosméticas del mismo error durante veinte minutos.

## Qué no va acá

Conocimiento del negocio. Los precios, los argumentos y el histórico del
cliente viven en los archivos de datos, y ahí se buscan cuando hacen falta. Las
reglas describen la forma de operar, que cambia mucho más lento.

La prueba es simple: si una frase deja de ser cierta cuando cambias de cliente,
no es una regla de la casa, es un dato.

## Cómo se mantiene

No se escribe de una sentada. Se escribe cuando el agente hace algo que no
querías: la primera vez lo corriges, la segunda vez escribes la regla. Antes de
la segunda, no sabes si era un caso aislado.

Vale también al revés. Cuando algo sale bien porque diste una instrucción
puntual, esa instrucción es candidata a regla permanente. Se prueba unos días y
se sube al archivo.

La plantilla completa, lista para copiar y adaptar, está en
[`instrucciones.md`](instrucciones.md).