Personalizar agentes

Los agentes de programación son extremadamente inteligentes incluso sin personalización. Entienden muy bien las prácticas consolidadas de ingeniería de software y, por lo general, toman decisiones acertadas.

Sin embargo, no saben cómo le gusta a tu equipo desarrollar software, cuáles son tus herramientas preferidas ni el contexto de tu empresa. Ahí es donde entra la personalización. Puedes modificar los agentes para que sean más efectivos y generen resultados de mayor calidad.

Cherri Code ofrece dos capas de personalización que reflejan cómo incorporarías a un nuevo miembro del equipo: reglas para lo que siempre deben saber y skills para conocimientos especializados que pueden incorporar cuando sea relevante.

Reglas: contexto estático

Las reglas son archivos Markdown almacenados en .cursor/rules/ que el agente ve al inicio de cada conversación. Puedes considerarlas instrucciones que siempre se incluyen y que determinan cómo el agente trabaja con tu código.

Un buen archivo de reglas es breve, específico y remite a ejemplos en lugar de copiarlos:

# Commands- `npm run build`: Build the project- `npm run typecheck`: Run the typechecker- `npm run test`: Run tests (prefer single test files for speed)# Code style- Use ES modules (import/export), not CommonJS (require)- Destructure imports: `import { foo } from 'bar'`- See `components/Button.tsx` for canonical component structure# Workflow- Always typecheck after making a series of code changes- API routes go in `app/api/` following existing patterns

Las reglas son especialmente útiles para:

• Comandos de creación y prueba que el agente debe conocer
• Convenciones de código que el agente debe seguir
• Referencias a ejemplos canónicos de tu base de código
• Medidas de protección (archivos que no se deben modificar y patrones que se deben evitar)

Qué evitar en las reglas

• No copies guías de estilo enteras. Usa un linter. Las reglas deben complementar tus herramientas, no sustituirlas.
• No documentes todos los comandos. El agente ya conoce las herramientas habituales. Añade solo comandos específicos del proyecto.
• Empieza de forma sencilla. Las reglas se incluyen en todas las conversaciones, así que se acumulan. Añade reglas solo si detectas que el agente comete el mismo error repetidamente y mantenlas breves.

Incluye las reglas en Git para que todo el equipo se beneficie del conocimiento compartido.

Skills: contexto dinámico

Las skills amplían las capacidades de tus agentes de programación con conocimientos especializados y flujos de trabajo. A diferencia de las reglas, las skills se cargan dinámicamente. El agente decide cuándo usarlas según la tarea en cuestión.

Las skills se definen en un archivo SKILL.md y pueden incluir conocimientos del dominio, flujos de trabajo personalizados, scripts y código que el agente puede ejecutar.

---description: Implementar en staging. Usar cuando el usuario pida implementar, lanzar o hacer push a staging.---# Implementar en staging## Pasos1. Ejecutar `npm run build` y confirmar que se complete correctamente2. Ejecutar `npm run test` y confirmar que todas las pruebas pasen3. Ejecutar `npm run deploy:staging`4. Verificar la implementación comprobando https://staging.example.com/health5. Informar el estado de la implementación y la URL

La diferencia clave entre reglas y skills:

MCP: conexión a herramientas externas

MCP (Model Context Protocol) permite al agente conectarse a herramientas externas e incorporar contexto relevante. Los servidores MCP exponen este contexto y las acciones que el agente puede usar según sea necesario.

Por ejemplo, puedes conectar el agente a:

• Slack para leer mensajes y publicar actualizaciones
• Datadog para investigar registros de producción
• Sentry para consultar detalles de errores y trazas de pila
• Bases de datos para consultar datos directamente
• Figma para extraer tokens de diseño y especificaciones de componentes

Explora el Marketplace para encontrar servidores para las herramientas que usas.

Herramientas de CLI como capacidades del agente

Además de MCP, el agente puede ejecutar cualquier herramienta de CLI instalada en tu terminal. Herramientas como gh, aws, kubectl y docker funcionan sin configuración adicional. El agente puede ejecutarlas directamente.

Indica al agente qué herramientas usar mediante una regla:

- Usa `gh` para todas las operaciones de GitHub (issues, PR, comprobaciones de CI)- Usa `aws s3` para las operaciones de almacenamiento de archivos

Esto también resulta útil para depurar. En vez de cambiar al navegador para consultar el estado de CI o buscar un problema, puedes pedirle al agente: "Comprueba por qué falló la CI en esta PR con gh." Ejecuta los comandos, lee la salida y actúa en consecuencia.

Guardar flujos de trabajo reutilizables

También puedes invocar skills bajo demanda con / en la entrada del agente. Esto convierte las skills en flujos de trabajo reutilizables que puedes activar por nombre, ideales para tareas que ejecutas muchas veces al día.

Por ejemplo, una skill /pr que hace commit, hace push y abre una pull request:

---description: Crear una solicitud de extracción para los cambios actuales.---1. Revisa los cambios preparados y no preparados con `git diff`2. Escribe un mensaje de confirmación claro según los cambios realizados3. Confirma y hace push a la rama actual4. Usa `gh pr create` para abrir una solicitud de extracción con título y descripción5. Devuelve la URL del PR al finalizar

Otros flujos de trabajo que funcionan bien como skills:

• /fix-issue [number]: Obtén los detalles del problema con gh issue view, busca el código relevante, corrige el error y abre una PR
• /review: Ejecuta los linters, revisa problemas comunes y resume qué requiere atención
• /update-deps: Busca dependencias desactualizadas y actualízalas una por una; ejecuta tests después de cada actualización

Confírmalos en git para que todo tu equipo pueda ejecutarlos.

Antes y después

Así se ve la personalización en la práctica. Imagina un equipo que usa Next.js, Tailwind y Vitest:

Antes de las reglas: El agente usa jest para las pruebas (porque es más común en los datos de entrenamiento), crea componentes con módulos CSS y coloca las rutas de la API en ubicaciones aleatorias.

Después de añadir tres reglas:

- Las pruebas usan Vitest, no Jest. Consulta `src/__tests__/example.test.ts` como referencia.- Aplica estilos con clases utilitarias de Tailwind. No uses módulos CSS ni styled-components.- Las rutas de la API van en `app/api/[resource]/route.ts`, siguiendo los patrones existentes.

El agente ahora sigue las convenciones del equipo de forma predeterminada. Se acabó corregir los mismos errores en cada conversación.

Patrón habitual de fallo: reglas excesivamente complejas

Puede que te sientas tentado a crear reglas para todo. Evítalo. Demasiadas reglas consumen contexto innecesario y pueden confundir al agente.

Mantén tus reglas al mínimo y que sean de alta calidad. Deben ser un artefacto compartido que tu equipo actualice constantemente. Si solo necesitas algo de vez en cuando, inclúyelo en una skill.

Qué sigue

Has personalizado tu agente para adaptarlo a los patrones de tu equipo. En el capítulo final, lo reunirás todo en un ejemplo completo que aplica todo lo que has aprendido en este curso.