TaskGoblin connects to two kinds of tools, and the distinction shapes how you sign up:
- A git provider — GitLab or GitHub — supplies your repositories and provisions your organisation. Exactly one per organisation, chosen when you sign in.
- Capability providers — Linear, Jira, Slack, Microsoft Teams, and Sentry — add surfaces where loops can fire and goblins can report back. You connect these into an organisation you already have.
Manage them all from Integrations in your organisation menu (/{organisation}/integrations).
Connecting a provider installs its default loops. That is the practical consequence worth holding on to: an integration is not just a credential, it is a set of standing behaviours arriving with it. See Event loops for what each one installs.
Git providers (GitLab or GitHub)
Signing in is connecting your git provider — one OAuth consent both authenticates you and provisions your organisation and repositories. That is why there is no separate "connect your repo" step.
GitLab
Connecting GitLab enumerates the groups you belong to and provisions a TaskGoblin organisation for each one, plus a personal organisation. The goblin posts as @taskgoblin on merge requests and issues. If the token ever needs refreshing, the Integrations page offers a one-click Reconnect.
Installs: Review merge requests, Work on assigned issues.
GitHub
GitHub is a GitHub App, not a classic OAuth app. You install the TaskGoblin app on the organisation you want, and each installation becomes one TaskGoblin organisation. The app mints short-lived installation tokens on demand and the goblin posts as taskgoblin[bot]. Because permissions refresh through the installation itself, GitHub organisations never need a manual reconnect.
Installs: Review pull requests, Work on labelled issues.
A git-provisioned organisation is locked to the provider that created it — that provider's card offers Reconnect rather than Disconnect.
Capability providers
Linear
A one-click OAuth consent into your active organisation. Once connected, goblins can pick up issues assigned to the TaskGoblin agent, read the issue and its comments for context, and post status, activity, and the merge-request link back onto the issue.
Installs: Work on assigned issues.
Jira
An Atlassian OAuth consent, connecting your Jira site into the active organisation. Goblins pick up issues assigned to the TaskGoblin account and answer mentions on issue comments, replying as a comment on the issue and moving it through your workflow when you ask.
A Jira issue rarely names a repository, so the goblin works the destination out from the request, your organisation memory, and your connected repositories — and asks rather than guessing when it genuinely cannot tell. Telling it once is enough; it writes the answer down.
Installs: Work on assigned issues.
Slack
Connecting Slack lets anyone mention the goblin in a thread and get a reply where the conversation is happening. The bot token does not expire, so there is nothing to refresh. Slack is also where schedule loops deliver digests and reminders when the instruction names a channel.
Installs no loops of its own — it is a surface, not a trigger.
Microsoft Teams
Mention the goblin in a Teams channel, a group chat, or a direct message and it replies in place, editing its own message as the work progresses. Connecting verifies your Microsoft tenant; there is no bot token for you to manage.
Installs no loops of its own.
Monitoring
Sentry
Connecting Sentry lets a goblin be woken by a production error. When an alert fires, it reads the issue and its latest event, follows the stack frames marked as your own code into the relevant repository, works out the likely cause and the release that introduced it, and writes that up as a note on the Sentry issue. It can re-prioritise the issue too, and open a merge request when the fix is small and unambiguous.
You decide which errors are worth waking a goblin for. TaskGoblin only ever sees alerts from rules that name it, so nothing arrives until you add it as an action on an alert rule in Sentry. Build that rule on the "A new issue is created" condition rather than "an event is seen", and give it an action interval, so a busy error does not fire on every event. The Triage alerts loop is the second switch: pause it to stop every alert run without touching Sentry, or reword it to change what a triage run does.
One limit is TaskGoblin's own, whatever the rule does: the same error runs at most once a day. An issue that keeps alerting inside that day is acknowledged and skipped.
An error that alerts more than once comes back to the same goblin thread, so the second write-up can pick up where the first left off rather than starting cold: it checks what changed and posts a short note on whether the earlier cause still stands.
Installs: Triage alerts.
Filing issues, not just answering them
On every tracker you have connected — Linear, Jira, GitLab, GitHub — a goblin can open an issue, not just read and comment on one. So a review that spots a bug outside the merge request can file it, a Slack conversation's action items can land in Linear, and a Sentry alert can leave a ticket behind. You can ask for the issue on any connected tracker, not only the one the goblin was working in.
How the goblin authenticates as itself
You never paste a personal access token into TaskGoblin, and the goblin never sees your credentials.
Each provider has its own bot identity — @taskgoblin on GitLab, Slack, and Teams, taskgoblin[bot] on GitHub. Inside the sandbox, git credentials are provisioned per organisation at run time (a GitLab OAuth token, or a freshly minted GitHub installation token) and injected into the environment around the agent rather than handed to it as something to read.
That boundary is deliberate and it is also why the goblin comments through its own integrations rather than through the git token it was given: feedback posted with your token would appear under your name. Everything a goblin says, it says as itself.
Disconnecting
Disconnect a provider from the Integrations page and goblins lose that access immediately — the loops that depended on it stop firing, and nothing further is read or posted there. Reconnecting restores the same connection.
Where to go next
- Event loops — what each provider's default loops do, and how to change them.
- Ad-hoc runs — mentioning the goblin directly on any connected surface.
- Quickstart — the whole path from sign-in to your first loop.