Introduction

TaskGoblin runs engineering loops: a trigger plus an instruction, running in your existing tools. Code review, issue pickup, overnight maintenance — done without anyone remembering to ask, and delivered as merge requests you review.

Stop prompting agents. Start engineering loops.

The difference is the whole product. A prompt gets you one answer, once, and only if someone remembers to type it. A loop is a trigger plus an instruction — it fires on its own, does the work in an isolated cloud sandbox, opens a merge request you review, writes down what it learned, and is ready for the next turn.

You do not open an app or paste code into a chat window. You connect the tools your team already uses, and the work starts happening in them.

A loop is a trigger and an instruction

  • The trigger is either an event — a pull request opened, an issue assigned to the goblin — or a schedule, like every weekday at 07:00.
  • The instruction is plain English, not a DSL. "Review this merge request for correctness and security — flag real problems, not style nits." Or: "Check acme/web for safe dependency upgrades and open a merge request."

Everything TaskGoblin does is one of these. Automatic code review is an event loop on pull request opened. Assigning an issue and getting a merge request back is an event loop on issue assigned. Overnight test-suite health is a schedule loop at 06:00. There is no separate "automation feature" bolted on the side — loops are the primitive, and the behaviours that feel built-in are loops you own and can rewrite.

Loops is the page to read next if you read only one.

You start with loops already running

Sign in with GitLab or GitHub and TaskGoblin provisions your organisation, connects your repositories, and installs that provider's default loops — reviewing merge requests, picking up assigned issues. Open a pull request and it gets reviewed before you have configured anything.

Those defaults are ordinary loops on your Loops page. Read the instruction, rewrite it in your own words, pause it, delete it. Owning the behaviour is the point.

What a loop actually looks like

Loops are written in plain English, not a DSL. Here is a real one from the template gallery — a nightly guard on your test suite:

Trigger — every day at 06:00

Instruction — Clone acme/web, run the full test suite on the default branch. If something fails and the fix is small and safe, open an MR; otherwise summarise the failures. If all pass, do nothing.

Three sentences, and look at what is packed into them: where to work, what to do, when to fix versus when to escalate, and — the single most important line in any unattended instruction — permission to do nothing. That last clause is why you get a merge request on the mornings something broke, and silence on the mornings it did not.

The gallery ships nine of these to start from: dependency upgrades, docs drift, changelog entries, tech-debt sweeps, activity digests, stale-review reminders, triage nudges. All editable, all yours the moment you pick one. See Schedule loops for the full set, worked through.

Why the loops run in the cloud

Because a goblin runs in an isolated cloud sandbox rather than on someone's laptop, the work is:

  • Asynchronous — hand it off and close your machine.
  • Isolated — one boundary per organisation, and your credentials are injected around the agent, never handed to it to read.
  • Parallel — every run gets its own branch and sandbox, so ten loops firing at once is ten goblins working, not a queue.
  • Always on — 03:00 maintenance and a review of the pull request opened at midnight both happen without anyone awake.

What arrives at the end of a turn

A branch and a merge request, reviewed exactly like a colleague's — or inline review comments, or a reply in the Slack thread where you asked. Never a wall of text you have to act on yourself, and never a commit to your default branch.

Under the hood it is a real coding agent (Claude Code, Codex, or Gemini) with a checkout of your repository, reading files, running commands and tests, and working the problem the way a contributor does. Because it has its own identity in each tool — @taskgoblin on GitLab, Slack and Teams, taskgoblin[bot] on GitHub — the whole team can delegate to it and the whole team can see what it did.

Where to go next

Start here

  • Quickstart — from sign-in to your first reviewed pull request and your first schedule loop.
  • Loops — the primitive, and why it beats a prompt.

Build your loops

  • Event loops — reviews, assignments, and labels; the defaults you already have and how to change them.
  • Schedule loops — recurring work, and templates to start from.
  • Connect your integrations — GitLab, GitHub, Linear, Jira, Slack, and Microsoft Teams.
  • Ad-hoc runs — asking directly, when the work really is a one-off.

Understand the machinery

Billing