Most AI coding tools are built around a prompt. You describe what you want, an agent answers, and the exchange is over. That works right up to the moment the valuable thing stops being one good answer and starts being the same work happening reliably, every time, without anyone remembering to ask.
TaskGoblin is built around a loop instead.
A loop is a trigger and an instruction
That is the entire primitive.
- A trigger decides when the goblins wake up. It is either an event — a pull request was opened, an issue was assigned to the goblin — or a schedule: every weekday at 07:00.
- An instruction is plain English describing what to do when they do. "Review this merge request for correctness and security — flag real problems, not style nits a linter would catch." Or: "Check
acme/webfor safe dependency upgrades, run the tests, and open a merge request."
Put the two together and you no longer have a request, you have a standing capability. Nobody has to be at a keyboard, and nobody has to remember.
Everything is a loop
This is not a feature sitting beside the product — it is the product. The behaviours you would assume are hardcoded platform magic are all ordinary loops:
| What it looks like from the outside | The loop underneath |
|---|---|
| Every pull request gets reviewed | An event loop on pull request opened |
| Assign an issue to the goblin, get a merge request back | An event loop on issue assigned |
| Dependencies stay current without a ticket | A schedule loop every Monday at 08:00 |
| The docs never drift from the code | A schedule loop every Wednesday |
| A digest of what moved lands in Slack each morning | A schedule loop at 09:00 |
When you connect GitLab or GitHub, TaskGoblin installs a starter set of these for you — which is why code review begins working before you have configured anything at all. They are not special. Open them, read the instruction, rewrite it in your own words, pause it, or delete it.
One turn of a loop
Every turn runs the same way, whether the trigger was a webhook or a clock, and whether it is the first turn or the five-hundredth:
- Fire. The trigger matches. TaskGoblin opens — or reuses — a thread for that piece of work.
- Context. The goblin reads the issue, the thread, the diff, your organisation's conventions, and the notes previous goblins left, before it touches anything.
- Work. It runs inside an isolated cloud sandbox holding a checkout of your repository: reading files, editing them, running commands and tests.
- Deliver. It opens a merge request, posts inline review comments, or replies in the thread — wherever that work belongs.
- Hand off. It writes down what it learned and what is still open, so the next turn starts from there instead of from zero.
Step 5 is what separates a loop from a cron job. Each turn is informed by the ones before it, so a loop that runs every week for a year is not the same loop a hundred times — it is one that has been paying attention.
Why a loop beats a prompt
- It runs without you. The work is already done by the time you look, rather than waiting on someone noticing it needs doing.
- It is reviewable. Every turn ends as a branch and a merge request, reviewed exactly like a colleague's. Nothing merges on its own.
- It compounds. Correct a goblin once and the correction is written down for every goblin after it.
- It has an off switch. A loop is a row you own. Pause it and the behaviour stops immediately.
Where loops live
Manage them from the Loops area of your organisation (/{organisation}/loops). Every loop has its own page: the instruction, the trigger, an Active toggle, and the history of its recent runs, so you can see what it actually did rather than trusting that it fired.
Goblins can also create loops themselves mid-run. A goblin that notices you asking for the same thing every Friday can propose the loop that removes the asking.
Where to go next
- Event loops — loops that fire on a pull request, an assigned issue, or a label, and the defaults you already have.
- Schedule loops — loops that fire on a cadence, and the templates to start from.
- Ad-hoc runs — the direct asks that are not loops, and how to tell when one wants to become one.
- How a run works — what happens inside a single turn.