Remote Frog

I have been experimenting with some ideas to make AI processes to increase my team’s leverage and help the team handle growing demand. Namely

• A bot that reads HDV alerts, gathers context, and creates a pre-analyzed Linear issue; a second run can create a PR.
• A second scheduled task that reviews commits merged into one of our repos and creates Linear Issues and actionable remediation work for concrete regressions.
• And a third scheduled task called LeaNEAR that reviews issues against writting Linear issues with AI principles and proposes clearer descriptions and context while keeping human approval in the loop.

They work pretty well so the next step was moving these automations from my laptop -they all run over Codex scheduled tasks- to agents that keep working after I close the lid. I was just waiting for the right moment and one of my team mates brought Grok Bot to my attention. And I felt it was the right tool for LeaNEAR for this first pilot because it has the simplest workflow, it just suggests changes to the way in which Linear issues are written and apply them after human validation.

What’s Grok Bot?

It’s a bot that runs on a cloud computer, with a browser, files, and terminal and shares this computer with other bots you can create. It can sign into your tools, keep working when your laptop is off, and stop when it needs your approval ==> that makes it interesting for small but persistent tasks: routine reviews, cross-tool follow-up, reminders with context, or workflows that live between Slack, Linear, and the browser.

You can use it from x.ai/bot or from the Cursor Bot app. It uses your Cursor account and requires a paid Cursor plan or a linked SuperGrok subscription.

Compared with similar tools

🤖 quick summary :

Tool	Better at	Weaker at
Grok Bot	Standing jobs across apps (Linear, Slack, browser), routines, and several teammates	A single coding change that should end as a pull request
Cursor Cloud Agents	One repo task: edit, test, open a pull request, then stop	A long-lived role across Slack and Linear
ChatGPT Agent	A one-off browser task inside ChatGPT	Named bots, shared memory, and routines that keep running
Claude Cowork	Office and browser work in one session	A roster of bots, Slack-thread follow-up, and scheduled routines

The practical use case: moving our Linear review to an always-on bot

My use case is pretty simple: Have you ever created a Linear Issue (or an issue in no matter which other tool) that is not legible or complete enough? It happens to the best of us. And I happens to me all the time. Well, I have a daily Linear issue review for this that worked on a local Codex scheduled task and I’ve moved it to a Grok Bot, an assistant that runs on its own cloud computer, so the review happens even when my laptop is off.

There is very little setup, you need to connect Linear (I used an API key to be able to check the list of followers and avoiding adding myself as a follower of any Linear Issue that this bot makes changes to) and also to Slack, and invite @Cursor to the channel.

I also updated a md file with the correction rules and another one to be updated with the list of Issues that have already been reviewed.

What it does?

The behaviour is in the Details tab

• Every weekday at 6:00 Madrid time, it reviews new issues assigned to the AEDT team (Analytics Engineering & Data Tooling), including the triage queue.
• It excludes issues from other teams, even when they are assigned to AEDT members or sit in shared projects.
• It checks each issue against the principles in “How We Work: Writing Issues with AI”: verb-led action, context, impact, success, clarity, and concision.
• It keeps a reviewed-issues.md file so the same issue is never reviewed twice. => This is in the Library
• Title suggestions always preserve the project prefix exactly as written, such as [PROJ NAME] or Project Name:.

How DOES IT work?

• The review step is read-only against Linear and it posts a message like “🤖 LeaNEAR Issue Reviews” in my team’s Slack channel. Then places the numbered proposals threaded to avoid adding to much noise to the main conversation.
• Each proposal includes the issue link and the exact before-and-after text.
• Any channel member can approve items by number or with approve all.
• A separate apply step that is sparked when the thread has an answer makes only the approved edits, adds an audit comment to each changed issue, and confirms in the thread what changed. If you check details tab on top, this is the second action.
• The bot is only allowrd to post in that Slack channel.

Running it on demand

To trigger a run outside the schedule, I can post @linear-review run in #people-analytics. Extra instructions can be added too, for example: run, re-reviewing already-reviewed issues from project X.

Why I like this pattern

As soon as a task needs light memory, a schedule, one app as input and another as output, plus a bit of human supervision, a persistent bot starts making more sense than a loose prompt or a local session. And I found these bots to be super simple to setup !

Of course, it is not the right tool for everything. If we need a well-scoped coding change that should end in a pull request (like the others I mentioned above), I would use something else. But for routine reviews with context and human approval, this format is working really well for me.

BONUS: THe RULES I USE FOR LINEAR ISSUEs FINE TUNING

These are the rules I use. Happy to get your comments/messages if you find how to fine tune them 🙂

### 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.