Cómo escribir reglas de Cline y comprobar que se cargan

Empieza con dos reglas que puedas comprobar

Guarda un acuerdo de tarea y una regla de comprobaciones y entrega en .clinerules/, dentro del repositorio. Activa ambas, inicia una tarea nueva e inspecciona el plan, el diff y los resultados de las pruebas. Añade condiciones de ruta cuando esta configuración básica funcione en tu cliente.

Esta guía incluye archivos completos y un procedimiento de aceptación. Comprobamos la documentación oficial y una instantánea pública del código el 23 de octubre de 2026. No ejecutamos Cline sobre un repositorio ni medimos si estas instrucciones mejoran el comportamiento del modelo.

Las reglas añaden instrucciones al contexto del modelo. No crean límites de permisos ni un entorno aislado de seguridad. Configura por separado las aprobaciones y el acceso al repositorio. La documentación de Auto Approve explica esos controles.

Elige la ubicación para tu cliente

La guía de configuración documenta .cline/rules/ y el formato anterior .clinerules/ para reglas de proyecto. También incluye AGENTS.md en la raíz y ~/.agents/AGENTS.md como archivo global. Los ejemplos usan únicamente .clinerules/. No dupliques las mismas instrucciones en ambos directorios.

El cargador actual también admite el archivo heredado .clinerules, sin extensión. Un archivo y un directorio no pueden ocupar la misma ruta. Antes de convertir un archivo existente, conserva su texto y después pásalo a un archivo Markdown dentro del nuevo directorio. Guarda las reglas directamente en ese directorio. Este cargador busca archivos .md, .markdown y .txt, sin recorrer carpetas de reglas anidadas.

Para preferencias personales, el resolutor de rutas compartido busca ~/.cline/rules, ~/Cline/Rules y la ubicación de Cline Rules en Documents. En Windows también puede buscar en Documents redirigidos mediante OneDrive. Usa la ubicación que muestra tu cliente.

La documentación de reglas indica que las reglas del espacio de trabajo tienen prioridad sobre las globales si hay un conflicto. Aun así, elimina las contradicciones. Los prefijos numéricos organizan archivos; no crean una jerarquía de permisos ni demuestran qué instrucción seguirá el modelo.

Comprueba cada cliente por separado:

• En el editor, abre Rules con el icono de la balanza y revisa el interruptor de cada archivo.
• El CLI comparte los directorios documentados, pero tiene su propia configuración y sus controles de aprobación. Revisa cline config. La guía del CLI indica actualmente que la aprobación automática global está activada por defecto. Comprueba el valor antes de la prueba.
• Cloud Agents no carga actualmente reglas, skills, servidores MCP ni conectores. Guardar una regla en Git no la activa en una sesión de nube.

Crea un acuerdo de tarea y una regla de entrega

Abre la raíz del repositorio en el editor. Si .clinerules no existe, crea el directorio. Guarda cada bloque con el nombre indicado. Los ejemplos presuponen un proyecto JavaScript o TypeScript con package.json. Adapta las rutas permitidas, el gestor de paquetes y las comprobaciones al repositorio real.

Guarda .clinerules/01-task-contract.md:

# Acuerdo de tarea

Antes de proponer cambios:
- Lee README.md y package.json. Identifica el gestor de paquetes por el lockfile.
- Inspecciona los archivos objetivo y las pruebas cercanas. No leas archivos .env ni credenciales.
- Indica el comportamiento solicitado, los archivos que cambiarás y las comprobaciones relevantes.
- Si la petición no define el alcance, propón uno antes de editar.

Durante la implementación:
- Cambia solo los archivos necesarios para la tarea acordada. Conserva los cambios ajenos del usuario.
- Explica por qué necesitas modificar una dependencia o el lockfile antes de hacerlo.
- Si un cambio necesario supera el alcance acordado, detente y explica el motivo.

Guarda .clinerules/02-checks-and-delivery.md:

# Comprobaciones y entrega

Antes de la entrega:
- Busca los comandos de comprobación en package.json y el README del proyecto.
- Si cambia el comportamiento, añade o actualiza una prueba específica cuando exista infraestructura de pruebas.
- Ejecuta la prueba pertinente y las comprobaciones de tipos o lint configuradas para el código modificado.
- Si una comprobación necesaria no existe o no puede ejecutarse, informa de la limitación.

Durante la entrega:
- Revisa el diff final para detectar cambios ajenos y errores de espacios.
- En la entrega, enumera archivos modificados, comandos exactos y resultados, y problemas pendientes.
- No declares una comprobación superada sin haber observado su resultado satisfactorio.

Las reglas piden a Cline que busque los comandos reales. No presuponen que todos los proyectos tengan lint, typecheck o test. Un proyecto npm podría usar lo siguiente. Los dos últimos comandos requieren esos scripts y un ejecutor de pruebas que acepte una ruta de archivo. Sustitúyelos por los comandos de tu repositorio.

git status --short
npm run
git diff --check
npm run typecheck
npm test -- src/utils/parse-label.test.ts

Mantén estas obligaciones sin condiciones. Una regla de pruebas que solo se cargue para *.test.ts puede pasar por alto una tarea que modifica código sin crear pruebas.

Confirma la carga antes de confiar en el resultado

Comprueba que ambos archivos aparezcan activados en la sección del espacio de trabajo del panel Rules. Después inspecciónalos con Git. La implementación actual de la extensión guarda el estado mediante metadatos YAML disabled. Desactivar una regla puede modificar un archivo versionado. Revisa el diff antes de compartir una preferencia temporal con el equipo.

Inicia una conversación nueva en Plan con una petición acotada. Adapta estas rutas a una función y una prueba existentes:

Solo planifica. En src/utils/parse-label.ts, haz que parseLabel rechace
entradas vacías o compuestas solo por espacios, conservando las válidas.
El alcance de edición es ese archivo y src/utils/parse-label.test.ts.
Antes de editar, identifica el código existente y el comando de prueba.

Comprueba que la respuesta identifique los dos archivos, la implementación existente y las comprobaciones pertinentes. Decir "he cargado las reglas" no constituye evidencia suficiente. Compara el plan con los archivos inspeccionados. Cuando el plan sea adecuado, cambia a Act con las aprobaciones previstas y deja que intente la modificación.

Acepta el resultado solo después de revisar el diff y los resultados observados. El cambio debe rechazar las entradas indicadas, conservar el comportamiento válido y respetar el alcance. Los checkpoints de Cline usan un repositorio Git auxiliar independiente. Ayudan a restaurar trabajo local, pero no sustituyen tus commits, la revisión de ramas ni las copias de seguridad.

Añade una regla condicional y prueba ambos casos

La guía de reglas define paths como un array de patrones glob relativos al espacio de trabajo. Cualquier ruta coincidente puede activar la regla. Las pestañas del editor, las rutas del mensaje y los archivos de la tarea pueden aportar contexto. Una coincidencia no anula un interruptor desactivado.

Guarda este archivo opcional como .clinerules/20-typescript.md:

---
paths:
  - "src/**/*.ts"
  - "src/**/*.tsx"
---

# Cambios de TypeScript

Para una tarea que cambie un archivo .ts o .tsx dentro de src:
- Incluye TS-RULE-ACTIVE una vez en el plan inicial durante la aceptación de reglas.
- Inspecciona los tipos cercanos antes de introducir un nuevo tipo público.
- Conserva las firmas exportadas salvo que la tarea requiera un cambio de API.
- Explica cualquier nuevo any o comentario de supresión de TypeScript.

Verifica las condiciones de ruta en el cliente instalado. El renderizador actual del SDK selecciona las reglas activadas sin evaluar paths en esa función. Esta inspección no demuestra un comportamiento condicional idéntico en el editor, Desktop y CLI. Mantén las restricciones necesarias en archivos incondicionales hasta comprobar tu cliente.

1. Inicia una tarea nueva en el editor y menciona un archivo real que coincida, fuera de un bloque de código pegado. Busca la notificación de reglas condicionales documentada y el marcador temporal TS-RULE-ACTIVE.
2. Inicia otra tarea nueva sobre un Markdown fuera de src. Cierra antes las pestañas TypeScript coincidentes. Comprueba que la regla no se active.
3. Desactiva la regla opcional y repite la tarea coincidente. Comprueba que siga inactiva. Después restaura el estado que necesitas.
4. Elimina la instrucción del marcador tras la aceptación y conserva las convenciones de código útiles.

El marcador comprueba la transmisión de instrucciones, no la calidad del código. Evalúa el cumplimiento mediante el diff y las comprobaciones reales. El modelo puede ignorar o interpretar mal una regla cargada.

Diagnostica reglas ausentes o inesperadas

Comprueba estas causas en orden antes de ampliar tu colección:

1. Confirma el cliente y la raíz del espacio de trabajo. Una sesión de nube no carga estos archivos. Abrir una subcarpeta como espacio de trabajo puede cambiar las reglas raíz descubiertas.
2. Confirma la ruta exacta y el interruptor. Usa un Markdown no vacío directamente dentro de .clinerules/ o .cline/rules/. Busca disabled: true y copias contradictorias en reglas globales o AGENTS.md.
3. Revisa delimitadores e indentación YAML. Usa el array de cadenas entre comillas del ejemplo. La documentación describe YAML inválido como fail-open, pero el parser actual del SDK lanza un error. Corrige la sintaxis sin depender de ninguno de esos comportamientos.
4. Revisa el contexto y el glob. src/*.ts no cubre subdirectorios. Inicia una tarea nueva, menciona una ruta relativa exacta y cierra pestañas coincidentes ajenas. El comportamiento documentado de paths: [] es no coincidir con nada. No uses un array vacío para una regla permanente.
5. Separa carga y cumplimiento. Si la regla visible se carga pero el parche la incumple, acorta las instrucciones, elimina conflictos y repite la tarea de aceptación. Registra la versión del cliente antes de atribuir un fallo a Cline en general.

Conserva un registro por prueba:

Registro	Qué guardar
Entorno	Cliente y versión, commit del repositorio, proveedor y modelo exacto
Estado de reglas	Archivos, commit o diff de reglas, interruptores, ruta coincidente
Evidencia de carga	Panel Rules, notificación condicional si existe, resultado del marcador
Evidencia de tarea	Mensaje, alcance propuesto, diff final, cambios ajenos
Aceptación	Comandos exactos y resultados, correcciones manuales, fallos restantes

Mantén las reglas como archivos revisados del proyecto

Versiona las reglas compartidas junto con el código que describen. Asigna un revisor a sus cambios e incluye la pequeña tarea de aceptación en la descripción. Si cambia un script, directorio o convención, actualiza la regla en el mismo pull request. Guarda las preferencias personales en el ámbito global y excluye credenciales de todas las reglas compartidas.

Una colección "awesome .clinerules" puede aportar ideas, pero revisa cada instrucción antes de importarla. Elimina referencias a archivos inexistentes, comandos no compatibles, peticiones amplias de aprobación automática e instrucciones contradictorias. Un conjunto pequeño de instrucciones comprobadas facilita la revisión.

Si migras reglas antiguas de Roo, su aviso oficial indica que la extensión, Cloud y Router cerraron el 15 de mayo de 2026. Reescribe la intención para Cline y repite la aceptación. Renombrar un antiguo archivo de reglas de Roo no transfiere restricciones de modo, permisos ni servicios alojados. La guía de migración de Roo a Cline explica la transición. Consulta Kilo Code frente a Cline para elegir entre clientes mantenidos.