Rutinas de Claude Code: ejecuta tu agente de código con una programación en la nube

Cada una de las tres partes cumple una función concreta:

• Prompt. La parte más importante, porque la rutina se ejecuta sin tu aprobación en cada paso. El prompt debe llevar toda la tarea y su definición de "hecho".
• Repositorios. Claude los clona al inicio de cada ejecución y trabaja dentro de ellos.
• Conectores. Las integraciones de claude.ai en tu cuenta, como Slack o Linear, de las que la rutina puede leer y a las que puede escribir durante una ejecución. Por ejemplo, una que haga triaje de soporte podría leer un canal de Slack y crear incidencias en Linear.

Los conectores para rutinas se añaden en la plataforma claude.ai; lo mismo ocurre con los servidores MCP. Tus configuraciones locales no se heredan.

Una rutina puede activarse de tres maneras: según una programación, mediante una llamada a la API o por un evento de GitHub. Una única rutina puede combinar las tres.

Rutinas frente a /loop

Hay una diferencia entre /loop y /schedule porque resuelven problemas distintos.

Una tarea /loop vive en tu sesión actual. Solo se activa mientras Claude Code está ejecutándose e inactivo en tu equipo, y al cerrar el terminal se detiene. Es ideal para consultar un build que estás vigilando en ese momento.

Para más información sobre /loop y otros comandos importantes, te recomiendo leer nuestro tutorial Claude Code Terminal.

Una rutina se ejecuta en la nube y permanece activa de forma independiente a cualquier sesión:

También hay una tercera opción local. Las tareas programadas de escritorio se ejecutan en tu propio ordenador, para trabajos que necesitan tus archivos y herramientas locales. Solo se ejecutan cuando la máquina está activa, pero no requieren tener la app de Claude abierta.

La rutina que vamos a crear

El modelo mental ya está claro. Ahora necesitas algo sobre lo que una rutina pueda trabajar. Para este tutorial, hemos creado pr-review-demo, un pequeño proyecto en Python con una pull request abierta.

Incluye un paquete cartlib que gestiona un carrito de la compra: guarda precios en céntimos como enteros, aplica descuentos para miembros y por volumen, y suma el impuesto estatal para calcular el cargo final. El paquete en la rama principal es correcto.

La pull request abierta añade un cupón de envío gratis y contiene un bug real que hemos introducido a propósito. Es una discrepancia de unidades entre archivos, invisible mirando un único archivo y solo evidente al seguir el valor entre dos. Eso le da a la rutina un trabajo real para el resto del tutorial.

Haz un fork del repo para seguir el proceso con tu propia copia. Es desechable, y los patrones valen para cualquier repositorio al que apuntes una rutina.

Requisitos previos para seguir el tutorial

Necesitas una cuenta de claude.ai con un plan Pro, Max, Team o Enterprise y Claude Code en la web activado. Las rutinas están en claude.ai/code/routines.

El comando /schedule se autentica con tu inicio de sesión de claude.ai, no con una clave de la API de Anthropic ni con las autorizaciones de Bedrock, Vertex o Foundry. También requiere un CLI reciente, así que ejecuta claude update si tienes una versión antigua.

Hay dos requisitos previos independientes para GitHub. Primero, /web-setup concede acceso de clonación, que la rutina programada necesita. Segundo, la Claude GitHub App, que se instala por separado, habilita el trigger de GitHub que cubriremos después.

Crear rutinas de Claude Code con /schedule

Con un repo al que apuntar, crea la rutina desde la CLI. Ejecuta /schedule en cualquier sesión. Puedes pasarle una descripción directamente:

/schedule daily PR review at 9 am

Claude te guiará por los mismos campos que recoge el formulario web: nombre, prompt, repositorio, entorno, conectores y programación. Confirma la hora en tu zona local y la convierte por ti, así que las 9:00 se transforman en la expresión cron correcta sin que tengas que escribirla.

Si tu cuenta aún no tiene conexión con GitHub, Claude te pedirá ejecutar /web-setup. Ejecútalo y luego vuelve a ejecutar /schedule para retomar donde lo dejaste.

Escribir un prompt que funcione sin ti

El prompt determina si la rutina tendrá éxito o no.

En una sesión normal hay una conversación, así que puedes corregir a Claude sobre la marcha. Una rutina no tiene a nadie que la corrija. Empieza en frío, llega hasta el final y no puede pedir aclaraciones. El prompt debe nombrar la tarea, el repositorio y cómo luce una ejecución terminada.

Compara estos dos. El primero deja demasiado sin decir:

Review the open PR.

No nombra un repo ni criterios de revisión, no indica dónde dejar comentarios y no define el "hecho". Una ejecución en frío no puede cubrir esos huecos. El segundo prompt lo resuelve todo:

Review the open pull request in pr-review-demo. The cartlib package works entirely in integer cents. Read the checkout flow and the values it pulls from config.py, and check that every amount stays in cents end to end. If any value is mixed in using the wrong unit, leave an inline comment on that line explaining the error and its effect on the customer's total. Then, post a summary comment stating whether the PR is safe to merge.

Ese prompt nombra el repo y establece el invariante que debe cumplir el código: todos los importes en céntimos. Señala los dos archivos relevantes y define el resultado como un comentario en línea más un veredicto de merge. Así la ejecución tiene un objetivo claro que puede alcanzar sola. Pégalo cuando /schedule pregunte qué debe hacer el agente.

Todos tus conectores se incluyen por defecto, así que una rutina recién creada ya puede acceder a todo lo que conecta tu cuenta. De momento está bien; más adelante recortaremos el alcance.

Al terminar, Claude guarda la rutina y confirma que está activa, con su repositorio, programación, modelo y próxima ejecución.

La rutina también aparece en la lista en claude.ai/code/routines. Abre su página de detalle para ver todo en un solo lugar: estado, repositorio, programación, conectores, el prompt completo y un botón Ejecutar ahora.

Haz clic en Ejecutar ahora para lanzarla al momento, en lugar de esperar a las 9:00.

Cómo leer la ejecución

La ejecución parte de un clon nuevo de tu repositorio, obtenido desde la rama por defecto. Todo lo que hayas hecho commit está ahí. Lo que solo tengas configurado en tu máquina no, así que la rutina ve el repo como lo verían tus compañeros.

Al terminar, la lista de ejecuciones muestra un estado en verde. Ese verde significa que la sesión se ejecutó y salió sin errores de infraestructura. Pero no implica que la tarea de tu prompt haya salido bien. Detrás del check verde pueden esconderse tres tipos de fallo que solo se ven en la transcripción:

• Una petición de red que el entorno bloqueó.
• Un conector que la rutina esperaba pero al que no pudo acceder.
• Un fallo a nivel de tarea, donde la ejecución terminó bien pero hizo lo incorrecto.

Así que abre la ejecución para confirmarla. Haz clic en cualquier ejecución para leerla como una sesión completa, donde puedes ver qué hizo Claude, revisar el diff, abrir una pull request o continuar la conversación.

En el repo de demo, la transcripción muestra el hallazgo. Claude lee checkout.py y detecta que el cupón tiene 5 en lugar de 500. Explica que eso aplica 5 $ como 5 céntimos, cobrando de más al cliente 4,95 $ por pedido, y propone la corrección en una línea. Luego publica la revisión en la PR a través del conector de GitHub.

Gestionar rutinas de Claude Code desde la CLI

Una vez creada, gestionas la rutina con el mismo comando. Ejecuta /schedule list para verlas todas, /schedule update para modificar una y /schedule run para lanzarla de inmediato.

Los preajustes de programación son cada hora, a diario, entre semana y semanal. Para un intervalo personalizado, como cada 2 horas o el primer día de mes, elige primero el preajuste más cercano. Luego ejecuta /schedule update para establecer directamente una expresión cron. El intervalo mínimo es de 1 hora; cualquier valor más rápido se rechaza.

Las rutinas también computan contra tu cupo diario de ejecuciones y, durante el research preview, los eventos de GitHub tienen límites por hora. Los eventos que exceden el límite se descartan, no se encolan. Las cifras actuales varían según el plan y aparecen en claude.ai/code/routines.

La CLI solo crea rutinas programadas. Para añadir un trigger de GitHub o de API, edita la rutina en la aplicación web.

Activar rutinas de Claude Code desde GitHub y HTTP

La programación lanza tu rutina según el reloj. Otros dos triggers permiten que GitHub o tus propios sistemas inicien la misma rutina. Una rutina de revisión de PR puede ejecutarse cada noche, reaccionar a cada PR nuevo y arrancar desde un script de despliegue, todo a la vez.

Añades ambos editando la rutina en claude.ai/code/routines.

Reacciona a pull requests con un trigger de GitHub

El trigger de GitHub requiere tener instalada la Claude GitHub App en el repositorio al que quieras suscribirte. Si falta la App, el asistente de configuración del trigger te pedirá instalarla. Ten en cuenta que /web-setup solo concede acceso de clonación. No instala la App ni entrega webhooks, así que ejecutarlo no cubre este paso.

Una vez instalada la App, añade el trigger y elige un evento. Los eventos se agrupan en dos categorías, pull requests y releases, y seleccionas una acción concreta dentro de cada una. La interfaz muestra las más comunes como preajustes (PR abierta, PR fusionada, Publicación de release) y una opción Personalizada para el resto.

Después, acótalo con filtros. Para pull requests, puedes filtrar por autor, título, cuerpo, rama base, rama de origen, etiquetas, si es borrador y si está fusionada. Todas las condiciones deben cumplirse para que la rutina se active.

El operador matches regex prueba todo el campo, no un substring. Para coincidir con cualquier título que contenga hotfix, escribe .*hotfix.*. Un simple hotfix solo coincide con un título exactamente igual, y nada más.

El trigger de GitHub configurado para activarse con una nueva pull request, filtrado por la rama main y un autor concreto.

Para el repo de demo, establece el evento en apertura de pull request y deja los filtros abiertos. Ahora cada PR nueva lanza la revisión que escribiste antes, sin nadie en el terminal. Sigue la unidad del cupón a través de los archivos, deja un comentario en línea en el bug y publica un veredicto de merge. 

Cada evento coincidente inicia su propia sesión, así que dos PR seguidas generan dos ejecuciones independientes.

Activa una rutina por HTTP

El trigger de API permite que tus propias herramientas lancen una rutina. Elige API en el selector de triggers y haz clic en Generar token. El token se muestra una sola vez y no puede recuperarse después, así que guárdalo de inmediato en el almacén de secretos de tu herramienta de alertas.

Luego haz POST al endpoint de activación de la rutina con el token y un cuerpo text:

curl -X POST https://api.anthropic.com/v1/claude_code/routines/$ROUTINE_ID/fire \
  -H "Authorization: Bearer $ROUTINE_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
  -H "Content-Type: application/json" \
  -d '{"text": "Sentry alert SEN-4521 fired in prod. Stack trace attached."}'

El valor de text se pasa como cadena literal y no se analiza, así que escribe prosa en claro en lugar de JSON. La entrada estructurada llega como texto sin procesar y la rutina la lee tal cual. 

La cabecera anthropic-beta es obligatoria y la API es experimental, así que consulta la referencia de la API antes de integrarla en CI. A partir de ahí, una herramienta de monitorización puede llamar a este endpoint ante una alerta y hacer que la rutina abra por sí sola una PR de corrección en borrador.

Acotar a qué puede acceder una rutina de Claude Code

Una rutina se ejecuta sola, así que antes de apuntarla a un repo real limita qué puede alcanzar. La documentación lo enmarca en cuatro controles:

• Quién es la identidad con la que actúa, a través de tu identidad de GitHub y conectores.
• A qué ramas puede hacer push.
• Qué conectores puede usar.
• A qué hosts puede acceder por red desde el entorno.

Ajusta cada uno al mínimo que la rutina realmente necesite.

Identidad de la rutina

La identidad va primero porque es lo que nota un compañero en un repo compartido. Todo lo que haga una rutina con tu identidad de GitHub o tus conectores aparece como si fueras tú. 

Los commits y pull requests llevan tu usuario de GitHub, y los mensajes de Slack y tickets de Linear usan tus cuentas vinculadas. Tus compañeros verán tu nombre en esos commits y PR, así que pon nombres de ramas y títulos que indiquen que los creó una rutina.

Ramas a las que la rutina puede hacer push

Las ramas vienen después. Una ejecución es una sesión completa en la nube sin avisos de permisos, así que nunca se detiene a preguntar antes de editar un archivo o abrir una PR. 

El guardarraíl es la rama a la que puede escribir. Por defecto, Claude solo hace push a ramas con prefijo claude/, lo que le mantiene alejadas ramas protegidas o de larga vida como main. 

Un ajuste por repositorio, Permitir pushes sin restricciones, elimina esa limitación. Actívalo de forma deliberada y solo en el repo que lo necesite.

Conectores que la rutina puede usar

Los conectores son el riesgo mayor de los cuatro. Todos tus conectores de claude.ai se incluyen por defecto, y Claude puede usar cualquier herramienta de un conector incluido, incluidos los writes, sin pedir permiso durante la ejecución. 

Por eso, reduce la lista a lo que necesite la rutina. Una rutina de revisión de PR necesita GitHub y poco más. Un conector perdido de email o calendario es un acceso que la rutina no usará, y una inyección de prompt escondida en una PR podría darle la vuelta a ese acceso.

Acceso a red

El acceso a red es el último control. El entorno por defecto usa acceso de red de confianza, que llega a una lista permitida integrada de registros de paquetes, APIs de proveedores cloud, registros de contenedores y dominios de desarrollo comunes, y bloquea el resto. 

Una solicitud bloqueada falla con 403 y x-deny-reason: host_not_allowed. Amplía ese acceso solo cuando la rutina deba llegar a tus propios servicios. En caso contrario, el fallo será silencioso: aparecerá en la transcripción en lugar de como un error evidente.

Ideas de rutinas de Claude Code para construir después

Ya sabes crear, activar y acotar una rutina. Estos ejemplos de la documentación oficial emparejan un trabajo con el trigger que mejor le va:

• Revisión de código a medida. Trigger de GitHub al abrir una PR. Aplica la checklist de tu equipo, deja comentarios en línea sobre seguridad, rendimiento y estilo, y añade un resumen. Es la demo, generalizada a tus estándares reales.
• Mantenimiento del backlog. Trigger por programación, cada noche entre semana. Lee las incidencias abiertas desde la última ejecución, aplica etiquetas, asigna responsables según el área de código y publica un resumen en Slack.
• Verificación de despliegue. Trigger de API desde tu pipeline de CD tras cada despliegue a producción. Ejecuta smoke checks contra la nueva build, escanea logs de errores buscando regresiones y publica un go/no-go en el canal de releases.
• Desfase de documentación. Trigger por programación, semanal. Analiza las PR fusionadas desde la última ejecución, detecta docs que referencian APIs cambiadas y abre PRs de actualización en el repositorio de documentación.

Las rutinas encajan en trabajos desatendidos, repetibles y con un resultado claro. Si puedes escribir los criterios de éxito en el prompt, como hiciste para la revisión de PR, la tarea es candidata. El trabajo que necesita criterio humano en tiempo real no lo es.

Conclusión

Las rutinas cambian cómo inviertes el tiempo en el trabajo recurrente. En lugar de ejecutar cada tarea en el terminal, la escribes una vez y revisas lo que ya se ha ejecutado. La revisión de PR que creaste se activa con el portátil cerrado y lees el veredicto cuando te viene bien.

Para seguir avanzando con Claude Code, estos tutoriales combinan bien con este:

• Buenas prácticas de Claude Code para sacar más partido a cada sesión.
• Escribir un archivo CLAUDE.md para dar a tus rutinas y sesiones un contexto compartido.
• Desarrollo guiado por especificación para tareas que merece la pena definir antes de automatizarlas.
• Auto mode y canales para ejecutar Claude Code con menos supervisión.