Cursor Agent Configuration

Alcance de trabajo

Esta guía cubre configuración documental de Cursor Agent en el editor, consultada el 2026-11-10. No presupone igualdad con Cursor CLI, Cloud Agents u otro cliente que utilice el mismo modelo. Mantiene las definiciones en agent-skills, agent-profiles, subagents-and-delegation y agent-sandboxing. No instala perfiles ni cambia permisos del Atlas.

El ejemplo es revisar documentos, devolver hallazgos y reservar la edición para otro encargo. La pregunta práctica es qué artefacto expresa ese procedimiento y cuál restringe sus efectos.

Skill: procedimiento reutilizable

Una ubicación de proyecto documentada es .cursor/skills/review-documents/SKILL.md:

---
name: review-documents
description: Revisa documentos asignados y devuelve contradicciones con evidencia.
disable-model-invocation: true
---
 
Lee el alcance recibido y las fuentes necesarias.
Busca contradicciones; devuelve ubicación, explicación y evidencia.
No edites ni publiques; informa los límites de la revisión.

La guía de skills de Cursor documenta activación mediante /, disable-model-invocation y paths para seleccionar archivos pertinentes. Esa selección de contexto no es una frontera de acceso. Su tabla consultada no establece allowed-tools ni readonly como controles de skill; no asumir que copiar esos campos desde otro producto los aplica.

Como criterio de diseño, guardar en la skill el procedimiento que merece reutilizarse. Las reglas generales del repositorio y los permisos de ejecución responden otras preguntas. Una skill que pide «solo lectura» todavía necesita ejecutarse con restricciones compatibles.

Subagente: readonly: true

La referencia de subagentes sí documenta una opción específica para restringir escrituras. Un perfil ilustrativo .cursor/agents/document-reader.md es:

---
name: document-reader
description: Revisa documentos asignados y devuelve hallazgos sin modificarlos.
model: inherit
readonly: true
---
 
Revisa los archivos asignados y amplía la lectura solo ante una duda concreta.
Devuelve evidencia y ubicaciones; conserva las incertidumbres.
No publiques ni asumas responsabilidad por cambios ajenos al encargo.

Según esa referencia, readonly: true restringe ediciones de archivos y comandos shell que cambian estado. Es una opción del subagente, distinta del texto de una skill. model: inherit reutiliza la selección del padre. La tabla consultada tampoco ofrece una lista tools equivalente a la de claude-code-configuration; no presentarla como YAML portable.

Si el trabajo autorizado requiere edición, la configuración admite readonly: false, que es su valor por defecto. Esto elimina esa restricción particular; no aprueba automáticamente publicación, credenciales ni toda operación externa. Mantener el scope del encargo y verificar permisos efectivos.

Búsqueda: herramienta integrada o comando

Para el encargo ilustrativo, indicar qué evidencia se busca suele ser más útil que imponer un comando sin necesidad. Grep en una referencia de herramientas y rg ejecutado mediante terminal no son el mismo mecanismo. Dar acceso a terminal añade efectos posibles que deben evaluarse.

Si una política laboral exige una lista cerrada de herramientas, comprobar qué superficie y versión de Cursor permiten imponerla. La ausencia de un campo en el schema consultado no justifica inventarlo; una instrucción «usar solo búsqueda» tampoco demuestra enforcement. Registrar esa limitación es preferible a etiquetar un perfil como seguro sin evidencia.

Aprobaciones y sandbox de comandos

Los Run Modes distinguen Auto-review, Allowlist y Run Everything. Allowlist regula ejecución sin aprobación; no debe confundirse con una lista exclusiva de capacidades de la skill. El modo de revisión y el sandbox tampoco son equivalentes.

La misma fuente separa permissions.json, que orienta Auto-review, de sandbox.json, que configura recursos alcanzables por comandos sandboxed. El sandbox habitual permite escribir en el workspace: no reemplaza el perfil readonly. Comprobar plataforma, configuración efectiva y condiciones de ejecución antes de confiar en una frontera.

Verificación y mantenimiento

En un laboratorio, seleccionar el perfil y comprobar que realmente interviene el subagente esperado. Usar archivos sintéticos: una lectura pertinente debe producir evidencia, una edición incompatible debe rechazarse y el diff debe conservarse vacío. Verificar por separado servicios externos que puedan tener efectos fuera del filesystem local.

Para un encargo posterior de edición, confirmar qué cambió y con qué autorización; no reaprovechar automáticamente un resumen antiguo como prueba de permisos. Registrar cliente, versión y resultado permite detectar diferencias después de actualizar. Los ejemplos de esta guía se revisaron sintácticamente, sin ejecutar Cursor ni certificar su enforcement. agent-building-blocks y ai-technology-catalog ofrecen la navegación hacia conceptos y otros productos.

El caso coding-agent-dotnet-api-change recorre una revisión con subagente de solo lectura, un encargo de edición y un hook de verificación para el mismo contrato.