La mayoría de las automatizaciones mueren de la misma manera. Alguien construye algo ingenioso, lo ejecuta una vez en una ventana de chat, cierra la computadora para ir a cenar, y todo se desvanece. El script nunca fue el eslabón débil. La computadora lo era. Tenía que permanecer abierta, enchufada, encendida, para que el trabajo siguiera ocurriendo — y las laptops están diseñadas para hacer todo lo contrario.
Una Mac mini no tiene ese problema. Cuesta alrededor de $599 en su nivel básico, consume menos energía que una lámpara de escritorio, no hace ningún ruido que valga la pena mencionar, y tiene exactamente una descripción de trabajo: permanecer encendida. Ese único rasgo es la razón completa por la que se ha convertido en la máquina a la que la gente silenciosamente entrega sus flujos de trabajo de Claude.
Este artículo recorre tres de esos flujos de trabajo: una bandeja de entrada que se clasifica a sí misma, solicitudes de extracción que se revisan durante la noche, y un calendario que te entrega un informe en lugar de un título de reunión — todo ejecutándose en una mini colocada en algún lugar de una casa, haciendo un trabajo que nadie tiene que recordar iniciar.
¿Por qué no usar simplemente el chat de Claude para esto?
Ya puedes pegar un correo electrónico en Claude y pedirle que redacte una respuesta. Ya puedes pegar un diff y solicitar una revisión. Nada en este artículo requiere una capacidad que no exista ya en la ventana de chat.
Lo que cambia es quién presiona el botón.
En el chat, tú eres el desencadenante, cada vez. Abres la pestaña, pegas el contenido, lees la respuesta, la copias en algún lugar. En el momento en que dejas de hacer eso, el proceso se detiene. Es una herramienta que solo se mueve cuando tu mano está sobre ella.
En la mini, el desencadenante es un reloj, o un webhook, o un nuevo archivo que aterriza en una carpeta. Claude hace el trabajo, verifica su propia salida contra una regla que escribiste de antemano, y o lo envía o lo intenta de nuevo — sin que nadie abra una computadora. Esa es toda la diferencia entre "un modelo que uso" y "un sistema que funciona."
Lo que realmente hay en el escritorio
Tres capas, y ninguna de ellas es exótica:
La máquina. Una Mac mini ejecutando trabajos launchd (la versión mejor educada de cron en macOS) que disparan scripts de Python en un horario o en respuesta a un cambio de archivo. Cualquier PC pequeña siempre encendida haría el mismo trabajo — la mini solo resulta ser silenciosa, barata de operar, y lo suficientemente pequeña para desaparecer detrás de un monitor.
El almacenamiento. Simples carpetas y archivos markdown, más lo que el flujo de trabajo toque directamente — una bandeja de entrada vía IMAP, un repositorio de GitHub clonado localmente, un calendario sincronizado con un feed .ics. Nada vive detrás de la aplicación de otro. Si la mini desapareciera mañana, cada archivo que produjo aún se abriría normalmente en cualquier computadora.
El razonamiento. Claude, llamado a través de la API. Sonnet maneja cualquier cosa que requiera juicio real — decidir si una solicitud de extracción es segura para fusionar, redactar una respuesta que suene como tú. Haiku maneja lo barato y de alto volumen — clasificar, etiquetar, comprobaciones de sí/no. Dividir el trabajo de esta manera es la mayor razón por la que la factura mensual se mantiene por debajo del costo de una suscripción de café.
Ahora los flujos de trabajo reales.
Rutina uno: la bandeja de entrada que está vacía de ruido cuando la revisas
La mayoría de las bandejas de entrada no están llenas de decisiones difíciles. Están llenas de cosas que no te necesitan en absoluto — un boletín, una confirmación de calendario, un proveedor preguntando algo que has respondido cincuenta veces. La parte difícil no es responderlas. Son los veinte segundos de atención que cada una roba antes de que siquiera decidas eso.
1EJECUTAR A: cada 15 minutos, días laborables2VIGILAR: correo nuevo en la bandeja de entrada principal34PASOS:5 1. Obtener los últimos 10 mensajes en el mismo hilo para contexto6 2. Claude clasifica el nuevo mensaje:7 - rutinario (confirmaciones, boletines, respuestas automáticas)8 - necesita respuesta (una pregunta real, una solicitud)9 - necesita decisión humana (dinero, conflicto, cualquier cosa ambigua)10 3. Rutinario -> archivado automáticamente, registrado en un resumen diario11 Necesita respuesta -> Claude redacta una respuesta en mi tono, guardada en Borradores,12 nunca enviada sin que yo la abra13 Necesita humano -> se deja intacto, marcado, sin borrador intentado1415VERIFICACIÓN: la clasificación debe incluir una razón de una línea. Si Claude16 no puede producir una razón que haga referencia al contenido real17 del mensaje, el elemento cae en "necesita humano" por defecto.18DETENER: cada mensaje en el lote ha sido clasificado, o 3 reintentos19 en cualquier mensaje individual antes de que sea marcado para mí directamente
La regla que importa aquí es la alternativa. Cualquier cosa que Claude no pueda clasificar con confianza no se adivina — aterriza en tu regazo exactamente como lo habría hecho de todos modos. El flujo de trabajo no está tratando de reemplazar el juicio en el difícil 10%. Está tratando de dejar de robar tu atención en el fácil 90%.
Rutina dos: las solicitudes de extracción obtienen una primera revisión antes de que te despiertes
La revisión de código tiene un extraño modo de fallo: la revisión que más importa — la de la PR que llegó a las 11pm — es la que probablemente se hará apresuradamente medio dormido, o peor, fusionada con un "lo revisaré mañana" que nunca sucede.
1EJECUTAR A: en cada nueva solicitud de extracción, mediante un webhook de GitHub23PASOS:4 1. Obtener el diff y el issue vinculado, si existe5 2. Claude revisa contra una rúbrica fija:6 - ¿coincide con el alcance real del issue vinculado?7 - ¿algún cambio en autenticación, pagos o migraciones? (marcar, no juzgar)8 - cobertura de pruebas en las líneas cambiadas — ¿presente o ausente?9 - nombres y estructura consistentes con el resto del archivo?10 3. Comentario publicado directamente en la PR, puntuado 1-5 por elemento de la rúbrica,11 con los dos puntos más débiles señalados explícitamente1213VERIFICACIÓN: un comentario solo se publica si cita números de línea específicos.14 Una revisión sin referencias de línea se descarta y se reintenta —15 la retroalimentación vaga no vale la pena enviarla.16DETENER: comentario publicado, o después de 2 reintentos la PR se deja sola17 con una nota de que la revisión automatizada no pudo completarse
Nada aquí fusiona nada. Es un segundo par de ojos que nunca se cansa, sentado en tus PRs antes de que tu primer par de ojos real lo haga. La puntuación contra una rúbrica fija es lo que lo mantiene útil — un modelo al que se le pide "revisa este código" de forma libre tiende a alabar todo o criticar al azar. Un modelo puntuado contra cuatro preguntas fijas produce el mismo tipo de retroalimentación cada vez, que es exactamente lo que lo hace valioso de leer a las 8am.
Rutina tres: las reuniones llegan con un informe, no solo un título
Una invitación de calendario te dice cuándo y dónde. Casi nunca te dice lo que realmente necesitas recordar antes de entrar — el último hilo de correo con esa persona, el elemento pendiente de la reunión anterior, el número que alguien va a preguntar.
1EJECUTAR A: 45 minutos antes de cada evento del calendario con 2+ asistentes23PASOS:4 1. Obtener el último hilo de correo y cualquier documento compartido vinculado5 al nombre de un asistente o al título del evento6 2. Claude escribe un informe de una página:7 - qué se acordó la última vez, si algo8 - una pregunta abierta que vale la pena plantear9 - cualquier número o fecha mencionada en el último intercambio10 3. Entregado como una notificación push 30 minutos antes del evento1112VERIFICACIÓN: el informe debe hacer referencia a un mensaje o documento anterior real.13 Sin contexto previo encontrado -> la notificación dice14 "no se encontró historial," no un resumen inventado.15DETENER: enviado, o saltado por completo si los asistentes son nuevos
Esa última verificación es la que vale la pena considerar. Sería fácil para Claude escribir un informe plausible a partir de la nada cuando no puede encontrar contexto real — y un falso plausible es peor que ningún informe, porque confiarías en él. Forzar un honesto "no se encontró nada" es lo que hace que los que sí llegan valgan la pena leer.
Las dos reglas de las que todo lo anterior depende
Quita los detalles específicos y cada rutina aquí descansa en las mismas dos barreras de seguridad.
Una regla verificable, no una sensación. "Clasifica este correo" es una sensación. "Clasifica este correo, y si no puedes citar la oración que justifica la etiqueta, por defecto a la categoría segura" es una regla. La diferencia es si Claude está calificando su propio trabajo contra algo específico, o solo produciendo algo que suena terminado.
Una condición de parada real. Cada rutina arriba tiene un límite duro de reintentos y una alternativa definida para lo que sucede cuando no puede hacer el trabajo limpiamente. Sin eso, un solo correo mal formado o una PR con un diff roto felizmente quemará llamadas API en un bucle de reintentos toda la noche, y la factura aparece antes que el informe de error.
Acierta esas dos cosas y la tarea específica apenas importa — bandeja de entrada, código, calendario, o algo completamente diferente.
Pruébalo manualmente antes de construirlo
Nada de esto requiere tocar un terminal para empezar. Puedes ejecutar la misma forma en una conversación normal de Claude y ver si realmente te es útil antes de automatizar algo:
1Trabajarás en esta tarea en pasadas, verificando tu propia2salida antes de darla por terminada.34TAREA:5[lo que quieres que se maneje]67REGLA DE PASAJE:8- Haz el trabajo.9- Verifícalo contra: [la condición específica y verificable]10- Si falla la verificación, di qué está mal y rehaz solo esa parte.11- Si pasa, di "hecho" y detente.12- Nunca me hagas una pregunta aclaratoria — toma la suposición13 más razonable, indícala en una línea, y continúa.1415Comienza.
Ese es el mecanismo completo en miniatura. Sin mini, sin webhook, sin horario — solo Claude verificando su propio trabajo contra una regla en lugar de detenerse en el primer borrador que parezca plausible. Si ejecutas esto manualmente tres o cuatro veces en el mismo tipo de tarea y sigues volviendo a ello, esa es la señal de que vale la pena ponerlo en una máquina que no necesita que te acuerdes de ejecutarlo.
El orden que evita que esto se rompa a las 2am
Nadie que ejecute estos de manera confiable empieza escribiendo el trabajo cron. El orden que realmente se mantiene:
- Ejecútalo manualmente en el chat hasta que la salida sea consistentemente correcta.
- Convierte ese prompt exacto en un script — sin cambios en la lógica.
- Agrega la verificación y el límite de reintentos antes que cualquier otra cosa.
- Solo entonces conéctalo a un horario o un webhook.
Saltar directamente al paso cuatro y descubres lo que te cuesta "sin condición de parada" de la manera difícil, usualmente en una mañana llena de comentarios duplicados de PR o cien borradores idénticos sentados en tu carpeta de Enviados.
Lo que esto realmente te está dando
Nada de esto hace a Claude más inteligente. Hace la diferencia entre algo que usas y algo que funciona ya sea que estés prestando atención o no. La mini no es la parte interesante — es solo la forma más barata y silenciosa de darle a un flujo de trabajo una máquina que nunca tiene que ser reabierta.
Comienza con la versión manual en este artículo. Si te encuentras ejecutándolo más de un par de veces a mano, esa es la que vale la pena poner en una caja que se queda encendida después de que te hayas ido a la cama.
Gracias por leer este artículo
Creador: @0xclayn**
Guarda esto
