Remote Frog

Últimamente he estado moviendo algunas automatizaciones desde mi portátil a agentes que siguen trabajando aunque yo lo cierre. Una de las más útiles ha sido sacar nuestra revisión diaria de issues de Linear de una tarea local en Codex y pasarla a un bot que está siempre activo.

Para esto he usado Grok Bot: Los bot de Cursor corren en un ordenador en la nube, con navegador, archivos y terminal. Puede iniciar sesión en tus herramientas, seguir trabajando cuando tu portátil está apagado y detenerse cuando necesita tu aprobación. En la práctica, esto lo vuelve muy muy interesante para tareas pequeñas pero persistentes: revisiones rutinarias, seguimiento entre herramientas, recordatorios con contexto o flujos que viven entre Slack, Linear y el navegador.

¿Qué es Grok Bot y dónde encaja?

Puedes usarlo desde x.ai/bot o desde la app de Cursor Bot. Usa tu cuenta de Cursor y requiere un plan de pago de Cursor o una suscripción SuperGrok vinculada. Sus funciones más útiles, al menos según las veo yo para este tipo de automatizaciones, son :

• Puedes tener varios bots con trabajos y memoria separados.
• Tiene conectores superfaciles para herramientas como Linear y Slack.
• Skills y rutinas programadas. Pero también las puedes disparar desde Slack con un mensaje.
• Un ordenador compartido en la nube.
• Notificaciones móviles.
• Team Bots que pueden publicar en Slack como su propia app.

No es “otro agente más”, sino una pieza bastante concreta: sirve bien cuando quieres un rol persistente entre varias apps, no solo una sesión puntual.

Comparado con herramientas parecidas

🤖 Resumen rápido

Herramienta	Mejor en	Más floja en
Grok Bot	Trabajos persistentes entre apps (Linear, Slack, navegador), rutinas y varios compañeros	Un único cambio de código que debería terminar en pull request
Cursor Cloud Agents	Una tarea de repo: editar, probar, abrir una pull request y terminar	Un rol duradero entre Slack y Linear
ChatGPT Agent	Una tarea puntual de navegador dentro de ChatGPT	Bots con nombre, memoria compartida y rutinas persistentes
Claude Cowork	Trabajo de oficina y navegador en una sesión	Una plantilla de bots, seguimiento en hilos de Slack y rutinas programadas

También hay límites prácticos. Todos los bots de tu cuenta comparten un mismo ordenador y sus inicios de sesión. Y si un flujo desatendido necesita una aprobación, la tarjeta de aprobación caduca más o menos a los 10 minutos. Pero… si la aprobación puede llegar más tarde, entonces está la alternativa de responder en Slack o en el chat del bot, que de todos modos tiene sentido muchas veces.

El caso práctico: pasar una revisión programada en mi laptop de issues de Linear a un bot siempre activo

Mi caso de uso es bastante sencillo: ¿Alguna vez has creado issues de Linear -o la herramienta que uses- a toda pastilla de modo que no cumplen los minimos requerimientos de legibilidad o de completitud? Pues a mi me pasa constantemente. Ahora estoy moviendo nuestra revisión diaria de issues de Linear fuera de una tarea local en Codex. Ahora la lleva Linear Issues Bot, un asistente que corre en su propio ordenador en la nube, así que la revisión ocurre incluso cuando mi mbp está apagado.

Qué hace

• Cada día laborable a las 6:00 (hora de Madrid), revisa los nuevos issues asignados al equipo AEDT (Analytics Engineering & Data Tooling), incluida la cola de triage.
• Excluye issues de otros equipos, incluso si están asignados a miembros de AEDT o viven en proyectos compartidos.
• Evalúa cada issue según los principios de How We Work: Writing Issues (with AI): verbo de acción, contexto, impacto, éxito, claridad y concisión…
• Mantiene un archivo reviewed-issues.md para no revisar dos veces el mismo issue. No depende de labels de Linear.
• Si propone cambios en el título, conserva exactamente el prefijo del proyecto, como [GH-TT] o ExPlat:.

Tanto los principios como el md file con los reviewed-issues están accesibles en la pestaña Biblioteca (mira la captura de pantalla). Y las descripción de las dos acciones del bot, en la pestaña Detalles (Las dos acciones están explicadas a continuación).

Cómo funciona la aprobación

• La fase de revisión solo lee de Linear.
• Publica un mensaje llamado 🤖 LeaNEAR Issue Reviews en el canal de Slack del equipo y deja las propuestas numeradas en el hilo.
• Cada propuesta incluye el enlace al issue y el texto exacto de antes y después.
• Cualquier persona del canal puede aprobar por número o con un approve all.
• Una segunda fase aplica solo los cambios aprobados, añade un comentario de auditoría a cada issue editado y confirma en el hilo qué ha cambiado.
• Si una respuesta es ambigua, no cambia nada y pide aclaración.
• Comentar no deja a nadie suscrito a un issue por accidente.
• El bot solo publica en en Slack channel que le he dicho.

¿Y Lanzarlo bajo demanda?

Esto me encanta. Si quiero ejecutarlo fuera del horario programado, basta con publicar @linear-review run en el canal de Slack del equipo. También se pueden añadir instrucciones extra, por ejemplo: run, re-reviewing already-reviewed issues from project X.

Lo que me gusta

Más allá de esta automatización concreta, aquí hay un patrón que me parece útil: no usar un agente solo para “hacer una tarea”, sino para asumir una pequeña responsabilidad estable en el tiempo. En cuanto una tarea necesita memoria ligera, horarios, una app de entrada y otra de salida, y algo de supervisión humana, un bot persistente simple como estos de Grok empieza a tener más sentido que un prompt suelto o una sesión local.

No sirve para todo, claro. Si lo que quieres es un cambio de código bien acotado que termine en pull request, pues no. Pero para revisiones rutinarias con contexto y aprobación humana, este formato funciona bastante bien.

BONUS: Las reglas que uso para el afinado de los linear issues

Estas son las reglas que uso yo: encantado de recibir comentarios o mensajes si alguien me ayuda a mejorarlas 🙂

### Core principles

- **Start with a verb when appropriate:** “Add password reset” instead of “Password reset missing.”
- **Provide context:** Include screenshots, videos, reproduction steps, relevant links, and related work.
- **Explain the impact:** Describe who is affected and the consequences. For example: “Blocks checkout for mobile users.”
- **Define success:** Clearly state what “done” looks like.
- **Write clearly:** Avoid jargon, explain acronyms, and assume no prior knowledge.
- **Be concise:** Aim for maximum clarity with the fewest words; start with a short TL;DR.
- **Drive action:** Every issue should justify the attention it requires and help move work forward.
- **Maintain a healthy signal-to-noise ratio:** Not everything needs to become an issue.

### Structure and scope

- **Projects** represent strategic work and meaningful outcomes.
- **Issues** represent smaller, tactical pieces of work.
- Use **sub-issues** to break down complex efforts (design explorations; multi-component features; research phases separate from implementation).
- Keep the hierarchy clear: project → parent issue → sub-issues.

### Statuses

Use Linear’s standard workflow (Triage, Backlog, Todo, In Progress, In Review, Done / Cancelled / Duplicate); avoid custom statuses unless genuinely necessary.

### Labels

- Use labels to organize work, not to overload issues; not for status or priority; essential categories only; avoid 10+ labels; use label groups.

### Using AI

AI is a tool for speed and formatting, **not a replacement for clear thinking or human judgment**. The author should validate the context, impact, scope, and success criteria.

### Important nuances from the discussion

- Starting with a verb is guidance, not a rigid rule.
- For bugs, avoid assuming the solution too early. “Fix X” may impose an answer before the problem is fully understood.
- Titles may benefit from including the product area or relevant context, e.g. “WordPress.com Login screen: add password reset.”
- Add an **Acceptance Criteria** section with concrete checks when the result needs to be verifiable.
- Adapt these practices to the situation and use your own judgment.