Escribir reglas

Una regla es una restricción que el asistente debe cumplir dentro de un alcance. Las reglas son el tipo de contenido más fuerte de Pathrule: llegan como requisitos y no como información de fondo, y una regla que lleva una restricción ejecutable aprobada puede detener un cambio que coincida antes de que se aplique.

Esta página explica cuándo escribir una regla, cómo elegir el alcance y la prioridad, qué significa la aplicación obligatoria y qué patrones conviene evitar.

Cuándo escribir una regla

Recurre a una regla cuando hay algo que el asistente no debe hacer, o algo que siempre debe hacer, en una parte concreta del código.

• "Nunca uses la service role key en código del navegador."
• "Todos los valores monetarios se guardan como enteros en centavos. Nunca uses floats."
• "Las migraciones deben ejecutarse antes del cambio de código correspondiente. Sin excepciones."
• "Los archivos JSX en apps/web usan solo clases de Tailwind. Nada de CSS modules ni estilos en línea."

Si la respuesta es "depende de la situación, el asistente debería pensarlo", eso es una memoria, no una regla. Las reglas son para lo que no se negocia.

Tipos de alcance

Cada regla tiene un tipo de alcance que decide a qué rutas o archivos se aplica.

• folder. Se aplica a un subárbol de directorios. Ideal para reglas específicas de un área: todo lo que vive bajo apps/api/auth, todo lo que está bajo services/billing.
• file_type. Se aplica a los archivos que coinciden con un glob como *.tsx o **/*.test.ts. Ideal para aspectos transversales ligados a un tipo de archivo y no a un directorio.
• project. Se aplica en todo el espacio de trabajo. Úsalo con moderación. Una regla de proyecto acompaña a cada prompt.

El alcance y la ruta del nodo al que está vinculada la regla deciden juntos lo que ve el asistente. Una regla folder vinculada a /apps/web cubre todo lo que está bajo apps/web.

Niveles de prioridad

La prioridad decide con cuánta insistencia aparece la regla. Dentro de un alcance coincidente, las reglas de mayor prioridad se consideran primero.

• high. Para lo que causa bugs, regresiones de seguridad o problemas de cumplimiento si no se respeta.
• medium. El valor predeterminado. Úsalo para "casi siempre, pero no es crítico".
• low. Estilística. Aparece cuando hay espacio y el tema viene al caso. Úsala para gustos y convenciones.

La prioridad alta es un presupuesto. Si la mitad de tus reglas tienen prioridad alta, ninguna la tiene. Elige las que de verdad no se pueden incumplir.

Aplicación: advisory y strict

La aplicación es un ajuste independiente de la prioridad. La prioridad determina con cuánta fuerza aparece una regla; la aplicación decide qué ocurre cuando se incumple.

• advisory. La regla es contexto. El asistente la sopesa y decide cómo aplicarla. Las reglas que escribes desde la CLI o VS Code, y las que escribe un asistente, son advisory.
• strict. Una regla pasa a ser strict cuando lleva una restricción ejecutable que una persona aprobó: la forma prohibida exacta, como un import, un identificador o una ubicación. El hook previo a la herramienta puede entonces bloquear una edición o escritura de archivo que coincida antes de que el cambio se aplique, y devuelve la regla y su solución como motivo. Un asistente puede adjuntar una restricción propuesta cuando escribe o actualiza una regla (pathrule_write_rule, pathrule_update_rule), pero una propuesta se guarda como propuesta y no bloquea nada hasta que una persona la aprueba; un asistente nunca puede aprobar las suyas. Consulta Las reglas como barreras de protección.

Reescribir una regla mantiene la aplicación honesta. Una restricción aprobada está ligada a la oración de la regla con la que se validó. Si reescribes la regla y esa oración desaparece, la restricción deja de aplicarse por sí sola, de modo que una regla nunca sigue bloqueando por un motivo que ya no expresa. Editar otras partes de la regla, o agregar un párrafo, deja activa una restricción que no se tocó.

El bloqueo depende del cliente. Pathrule CLI instala hooks de herramientas para Claude Code, Codex, Cursor y GitHub Copilot, y un bloqueo se aplica donde el hook previo a la herramienta del cliente respeta la decisión. Windsurf no tiene hooks y Remote MCP no instala ninguno, así que allí las reglas llegan solo como contexto. La entrega por sí sola no impone nada.

Estructura

Una regla tiene un nombre y un cuerpo. Mantén el cuerpo en modo imperativo y breve.

Name: No service role key in browser code

Body:
- Never import SUPABASE_SERVICE_ROLE_KEY in any file under apps/web.
- Use the anon key plus row level security.
- If you need server only access, do it from apps/api or a server action.

Desde la terminal, la misma regla es un solo comando. Sin --body, la CLI abre tu editor para escribir el cuerpo.

pathrule rule add --path /apps/web --name "No service role key in browser code" --priority high --scope folder

En VS Code usa New Rule…, y un asistente escribe reglas con pathrule_write_rule.

La forma que mejor funciona en la práctica es una restricción por regla con un cuerpo breve en viñetas. Las reglas largas en prosa se leen por encima, tanto las personas como los asistentes.

Reutilizables, no duplicadas

Una regla vive en una ruta y cubre todo lo que está debajo, así que una sola regla basta para todo un subárbol. Si la misma restricción se aplica a dos carpetas distantes, colócala en su ruta común más cercana, o usa un alcance file_type con un glob, en lugar de copiar y pegar el texto en dos reglas. Una sola regla significa una sola edición cuando cambia la restricción.

Pathrule te ayuda con esto: una regla nueva cuyo nombre coincide con una regla existente en el espacio de trabajo se rechaza de forma predeterminada, y la escritura te indica qué regla ya existe. Puedes anular ese comportamiento a propósito (allow_duplicate a través de MCP) después de revisar la regla existente. Para reubicar una regla, muévela a otra ruta (Move… en VS Code, o pathrule_update_rule con move_to_path).

Versiones y ediciones simultáneas

Las reglas llevan un token de versión, igual que las memorias. Si dos compañeros editan la misma regla al mismo tiempo, se produce un conflicto limpio en lugar de que uno sobrescriba al otro. En VS Code el conflicto ofrece las mismas opciones que para una memoria: Reload, Copy My Version & Reload o Keep Mine (Overwrite).

Cómo le llegan las reglas al asistente

• Las reglas de un alcance coincidente se priorizan según su prioridad y según cuán relevantes son para la tarea. Las más relevantes llegan con su cuerpo completo; las demás se mencionan por nombre, para que el asistente sepa que existen y pueda leer cualquiera completa con pathrule_read_rule.
• Una regla strict siempre llega completa donde se aplica, porque un nombre por sí solo no puede explicar un bloqueo.
• Las reglas también se compilan en los archivos de instrucciones que leen tus clientes (por ejemplo, CLAUDE.md para Claude Code y AGENTS.md para Codex), de modo que un cliente sin hook de prompt también parte de ellas.

Que una regla pueda bloquear un cambio, en lugar de solo informar al asistente, lo determina su modo de aplicación (advisory o strict), no su prioridad.

Antipatrones

• Prioridad alta para todo. Elige las reglas que de verdad importan. El resto debería ser medium.
• Reglas que parecen memorias. "Solemos preferir X" es una memoria. "Nunca hagas Y" es una regla.
• Reglas que se superponen. Dos reglas de prioridad alta con redacciones contradictorias son peores que una sola regla clara.
• Alcance de proyecto por defecto. La mayoría de las reglas van bajo una carpeta. Sube una regla a project solo si de verdad se aplica en todas partes.

Creación en modo local y en Cloud

Los ejemplos de add en la terminal de esta página son para un espacio de trabajo de Cloud. En modo local, crea y edita entradas en Local Console, en VS Code o a través de MCP local; los comandos de conocimiento de la CLI las listan, leen y buscan.

Qué leer a continuación

• Escribir memorias para hechos y decisiones que no son restricciones.
• Escribir skills para procedimientos reutilizables que el asistente puede invocar.
• Cómo funcionan los hooks para ver cómo el runtime decide qué reglas mostrar.