TaskGoblin quickstart — your first loop

Sign in, watch a loop you did not configure review your first pull request, then build one of your own. A few minutes, most of it spent waiting for a goblin rather than clicking through setup.

# Quickstart

This quickstart takes you from a fresh account to loops running on your repositories. Most of the few minutes it takes is spent waiting for a goblin, not on setup.

## Before you start

You need admin access to a GitLab group or a GitHub organisation whose repositories you want the goblins working on. That is all — nothing to install locally, and no keys to copy anywhere.

## Step 1 — Sign in

Go to the login page and sign in with **GitLab** or **GitHub**. That single consent does three things: it logs you in, provisions an organisation with your repositories connected, and installs that provider's **default loops**.

- On **GitHub** you install the TaskGoblin GitHub App on the organisation you want; the installation is the bot identity that posts as `taskgoblin[bot]`.
- On **GitLab** the OAuth consent enumerates your groups and connects them; the goblin posts as `@taskgoblin`.

## Step 2 — Look at the loops you already have

Open the **Loops** area of your organisation. You will find loops nobody configured:

- **Review merge requests** / **Review pull requests** — fires whenever one is opened or updated.
- **Work on assigned issues** / **Work on labelled issues** — fires when an issue is handed to the goblin.

Open one. The instruction is plain English and completely yours to change — this is the moment the product stops looking like a black box.

## Step 3 — Watch a loop fire

Open a pull request on a connected repository, or push a new commit to one that is already open. You do not have to mention anyone or press anything.

Within a minute or two a goblin clones the repository in an isolated cloud sandbox, reads the diff in context, and posts a review: a summary plus inline comments where they earn their place. If it has nothing worth saying, it says nothing — that restraint is written into the default instruction, and you can dial it up or down.

Reply `@taskgoblin fix` to any inline comment and it implements that one finding and pushes the commit.

## Step 4 — Hand off an issue

Now try the other default loop. Add the `taskgoblin` label to a GitHub issue, or assign a GitLab issue to the `@taskgoblin` bot. If your team lives in Linear or Jira, connect it from **Integrations** first — connecting either one installs its *Work on assigned issues* loop — then assign an issue there.

The goblin works on a dedicated branch named after the issue, commits, pushes, and opens a merge request linked back to it, posting progress as it goes. Review it exactly as you would a colleague's.

## Step 5 — Build a loop of your own

The defaults cover the reactive work. The compounding value is in the work nobody currently remembers to do — so create one:

1. Go to **Loops** and create a new one.
2. Pick a template. **Test-suite health** (daily) and **Dependency upgrades** (weekly) are the two most teams keep.
3. Replace the `{group/repo}` placeholder with a real repository, adjust the cadence to your timezone, and save.

Tomorrow morning there is either a merge request waiting or, if there was nothing to do, silence. Both are correct — the templates are written to do nothing rather than manufacture busywork.

## What you just did

You did not learn a new interface or write a prompt. You inherited two loops, watched one work, and built a third. Everything else in these docs is detail underneath that: [what a loop is](/en/docs/loop-engineering), [the events you can fire on](/en/docs/event-loops), [the cadences you can run](/en/docs/schedule-loops), and [what happens inside a single turn](/en/docs/how-the-agent-works).

This quickstart takes you from a fresh account to loops running on your repositories. Most of the few minutes it takes is spent waiting for a goblin, not on setup.

Before you start

You need admin access to a GitLab group or a GitHub organisation whose repositories you want the goblins working on. That is all — nothing to install locally, and no keys to copy anywhere.

Go to the login page and sign in with GitLab or GitHub. That single consent does three things: it logs you in, provisions an organisation with your repositories connected, and installs that provider's default loops.

On GitHub you install the TaskGoblin GitHub App on the organisation you want; the installation is the bot identity that posts as taskgoblin[bot].
On GitLab the OAuth consent enumerates your groups and connects them; the goblin posts as @taskgoblin.

Step 2 — Look at the loops you already have

Open the Loops area of your organisation. You will find loops nobody configured:

Review merge requests / Review pull requests — fires whenever one is opened or updated.
Work on assigned issues / Work on labelled issues — fires when an issue is handed to the goblin.

Open one. The instruction is plain English and completely yours to change — this is the moment the product stops looking like a black box.

Step 3 — Watch a loop fire

Open a pull request on a connected repository, or push a new commit to one that is already open. You do not have to mention anyone or press anything.

Reply @taskgoblin fix to any inline comment and it implements that one finding and pushes the commit.

Step 4 — Hand off an issue

Now try the other default loop. Add the taskgoblin label to a GitHub issue, or assign a GitLab issue to the @taskgoblin bot. If your team lives in Linear or Jira, connect it from Integrations first — connecting either one installs its Work on assigned issues loop — then assign an issue there.

The goblin works on a dedicated branch named after the issue, commits, pushes, and opens a merge request linked back to it, posting progress as it goes. Review it exactly as you would a colleague's.

Step 5 — Build a loop of your own

The defaults cover the reactive work. The compounding value is in the work nobody currently remembers to do — so create one:

Go to Loops and create a new one.
Pick a template. Test-suite health (daily) and Dependency upgrades (weekly) are the two most teams keep.
Replace the {group/repo} placeholder with a real repository, adjust the cadence to your timezone, and save.

Tomorrow morning there is either a merge request waiting or, if there was nothing to do, silence. Both are correct — the templates are written to do nothing rather than manufacture busywork.

What you just did

You did not learn a new interface or write a prompt. You inherited two loops, watched one work, and built a third. Everything else in these docs is detail underneath that: what a loop is, the events you can fire on, the cadences you can run, and what happens inside a single turn.